Linux Firewalls - Michael Rash [82]
Responding to Attacks with psad
Now that we have our tempered our discussion with an acknowledgment of the trade-offs present in a system that is configured to automatically respond to attacks, let us turn to the active response features offered by psad. The main method psad employs to respond to an attack is the dynamic reconfiguration of the local filtering policy so that it blocks all access from an attacker's source IP address for a configurable amount of time.
A NOTE ON TCPWRAPPERS
psad also supports the reconfiguration of the /etc/hosts.deny file to instruct tcpwrappers to deny access from an attacker's source IP address, but this mechanism is inferior to using iptables for several reasons. First, tcpwrappers can only block access to daemons that are configured to use tcpwrappers; in contrast, a general blocking rule in iptables means that an attacker cannot even talk through the IP stack on the targeted system. Second, tcpwrappers is only effective for protecting daemons that are running on the local system, whereas psad may detect a scan or other malicious traffic in the FORWARD chain. Lastly, an attacker is able to interact with many more functions on the target system when a daemon is protected by tcpwrappers; fewer functions are available for interaction with iptables, and any one of these functions (both within the kernel and within userspace) has a nonzero probability of containing a security vulnerability. The remainder of the chapter will concentrate on the usage of iptables for active response in psad.
The ability to dynamically reconfigure the local iptables policy implies that the response takes place at the network layer; for example, an attacker's IP address is blocked from talking up through the IP stack. If an attacker has an established TCP session with any server in the local network when a blocking rule is instantiated, then (because there is no TCP reset generated along with the blocking rule) all TCP packets will be dropped, and the endpoint TCP stacks will attempt to retransmit data until they timeout.[45]
Features
The following active response features are supported by psad:
Configurable minimum danger level an attacker must reach before an iptables blocking rule is added
The ability to make blocking rules either permanent or temporary, based on a configurable time-out
The use of separate iptables chains for all blocking rules so as to not interfere with any existing iptables policy on the local system
The preservation of blocking rules across restarts of psad or even system reboots (this feature is configurable, but the default setting flushes any existing blocking rules at psad start time)
The inclusion of status output for all currently blocked IP addresses, along with the remaining number of seconds before the associated iptables rules are removed
The ability to have an external process instruct psad to add or remove a blocking rule against a specific IP address by using the --fw-block-ip and --fw-rm-block-ip command-line arguments, respectively
The ability to differentiate between port scans and attacks that trigger a signature match, and the addition of a blocking rule in iptables that can be tied to either one
Email notifications when an IP address is added or deleted from the psad blocking chains
Configuration Variables
The most important variable that controls whether or not psad enters into active response mode is ENABLE_AUTO_IDS, which can be set to either Y or N within the /etc/psad/psad.conf file. When this feature is enabled, several other variables (discussed below) control various operational aspects of psad as it endeavors to automatically block attackers.
The AUTO_IDS_DANGER_LEVEL variable sets a threshold from 1 to 5 for the minimum danger level that an IP address must reach before a blocking rule is instantiated. By tuning the port scan thresholds, individual signature danger levels (see /etc/psad/signatures), and automatic danger level assignments (see /etc/psad/auto_dl), psad can