Customizing PortSentry

Step Away from the Ports

The main config file portsentry.conf might be described as lengthy, but once you’ve glanced over it, you’ll see that many options don’t apply to all supported modes, so it’s relatively light work.

For now, I’ll focus on the Advanced Stealth Mode because it looks for sequential port scans and other prestidigitation that attackers employ to their advantage on today’s Internet.

Figure 2: Don’t mess with the ephemeral port settings; you have been warned.

Inside the main config file, the first part that you’re interested in is shown in Figure 2. The comments give a crystal clear word of warning from the author. The next section just below is most important. I’ve left some real-world settings in place as a good example that should stop NetBIOS and DHCP broadcasts and the like from triggering the banning mechanisms. Shortly, I’ll cover how to prevent banning your entire LAN by accident but still protect your server against attacks.

Figure 3: How to ignore certain ports whilst using the Advanced modes.

To Ignore or Not to Ignore

The next parameters to check ensure that attacking IP addresses are banned and not just reported:


Next, you need to look at which mechanism will trigger when you want to ban an IP address. The default on Linux is to fill up your local hosts table with what are effectively black-hole routes to a non-existent IP address on your local area network (so a route already exists in the hosts table and you’re sending your attack traffic elsewhere – to annoy someone else, presumably):

# Generic Linux 
KILL_ROUTE="/sbin/route add -host $TARGET$ gw"

I’ll cover the actual KILL_RUN_CMD a later. This method, however, is a little antiquated and not very efficient, so you’d be wiser to use iptables instead, or something similar, to drop the offending IP:

# iptables support for Linux
KILL_ROUTE="/sbin/iptables -I INPUT -s $TARGET$ -j DROP"

The last section of interest is the main config file. It lets you run an external command and is listed as such. If you plan to customize PortSentry’s responses to attacks, make sure you understand this section and the order of events.

# The KILL_RUN_CMD_FIRST value should be set to "1" to force the command
# to run *before* the blocking occurs and should be set to "0" to make the 
# command run *after* the blocking has occurred.

Related content

  • Port Knocking
    To ensure that the data on your computers remains accessible only by you and those with whom you want to share, we look at the advantages of combining TCP Wrappers and port knocking.
  • Secure Your Server with TCP Wrappers

    TCP Wrappers are versatile, sophisticated, and surprisingly easy to use, and they can secure your servers from attack with run-time ACL reconfiguration.

  • Secure containers with a hypervisor DMZ
    Container technology security is not well defined. We look at several approaches to closing this security gap with hypervisors and buffer zones.
  • Pen Testing with netcat

    Once you have successfully exploited a target machine, you might be faced with a dilemma common among penetration testers: Do I have shell access or terminal access? These are not the same, and careful knowledge must be used when interacting with a shell compared with a terminal.

  • Creating Virtual SSDs

    An economical and high-performing hybrid NVMe SSD is exported to host servers that use it as a locally attached NVMe device.

comments powered by Disqus
Subscribe to our ADMIN Newsletters
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs

Support Our Work

ADMIN content is made possible with support from readers like you. Please consider contributing when you've found an article to be beneficial.