« Previous 1 2 3 Next »
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.
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.
To Ignore or Not to Ignore
The next parameters to check ensure that attacking IP addresses are banned and not just reported:
BLOCK_UDP="1" BLOCK_TCP="1"
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 123.45.67.89"
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. # KILL_RUN_CMD_FIRST = "0" # # KILL_RUN_CMD="commands_to_run"
« Previous 1 2 3 Next »