Linux Firewalls - Michael Rash [121]
Restricting psad Responses to Attacks Detected by fwsnort
Based on information included in Tying fwsnort Detection to psad Operations on page 194, we already know that psad can send alerts for log messages generated by fwsnort. It follows that psad can set up iptables blocking rules in response to fwsnort log messages simply by setting ENABLE_AUTO_IDS to Y in the /etc/psad/psad.conf file.
If an attack detected by fwsnort raises the danger level assigned to the attacker by psad higher than the value set by the AUTO_IDS_DANGER_LEVEL variable, then psad will instantiate carte blanche DROP rules against the attacker's IP address. However, psad danger levels are not only assigned because fwsnort logs an attack; dedicated port scans and probes for backdoors are also assigned a danger level.
As discussed in Chapter 8, enabling psad responses for scans and probes (which are easily spoofed) is risky business. Ideally, we would like psad to respond exclusively to those attacks that must involve application layer data over an established TCP connection, and not take any action against other types of attacks.
The AUTO_BLOCK_REGEX variable contains a regular expression that forces psad to perform blocking operations against IP addresses only when the corresponding iptables log messages match the expression. By default, the value assigned to the AUTO_BLOCK_REGEX variable is the string ESTAB, which matches fwsnort log messages triggered within one of the custom chains designed to match only packets that are part of established TCP connections. To enable this functionality, the ENABLE_AUTO_BLOCK_REGEX variable must also be set to Y in the psad configuration file.
Note
If you intend to allow psad to firewall-off attackers, you should run fwsnort and enable the AUTO_BLOCK_REGEX feature. Responding to port scans or other trivially spoofable traffic is too easily abused.
Combining fwsnort and psad Responses
We'll now revisit the WEB-PHP Setup.php access attack example, except this time we use active response mechanisms from both psad and fwsnort. First, we configure fwsnort to drop the malicious packet on the floor before it can reach the webserver:
[iptablesfw]# fwsnort --snort-sid 2281 --ipt-drop
[+] Parsing Snort rules files...
[+] Found sid: 2281 in web-php.rules
Successful translation
[+] Logfile: /var/log/fwsnort.log
[+] Iptables script: /etc/fwsnort/fwsnort.sh
[iptablesfw]# /etc/fwsnort/fwsnort.sh
[+] Adding web-php rules
Rules added: 4
If you look through the /etc/fwsnort/fwsnort.sh script now, you will see two rules like so:
$IPTABLES -A FWSNORT_FORWARD_ESTAB -p tcp --dport 80 -m string --string
"/Setup.php" --algo bm -m comment --comment "msg: WEB-PHP Setup.php access;
classtype: web-application-activity; reference: bugtraq,9057; rev: 2;
FWS:1.0;" -j LOG --log-ip-options --log-tcp-options --log-prefix "[1] DRP
SID2281 ESTAB "
$IPTABLES -A FWSNORT_FORWARD_ESTAB -p tcp --dport 80 -m string --string
"/Setup.php" --algo bm -j DROP
The first rule is identical to the original example presented in WEB-PHP Setup.php access Attack on page 194, except that the log prefix contains the string DRP, which makes it clear that the next rule drops the packet. With fwsnort up and running, we configure psad to block the attacker for one hour by setting the following variables in the psad.conf file like so:
ENABLE_AUTO_IDS Y;
AUTO_IDS_DANGER_LEVEL 4;
AUTO_BLOCK_TIMEOUT 3600;
ENABLE_AUTO_IDS_REGEX Y;
AUTO_BLOCK_REGEX