Linux Firewalls - Michael Rash [120]
Reporting Application Layer Content
The most interesting section of the psad alert for the WEB-PHP Setup.php access attack begins at ❸ above. This section indicates that psad noticed the string [1] SID2281 ESTAB and has mapped it to the appropriate Snort rule. Because psad maintains an in-memory notion of all Snort rule class types, message fields, and content strings, it deduces that the offending packet corresponds to the WEB-PHP Setup.php access rule in the web-application-activity class and must have contained the string /Setup.php.
Note
By itself, iptables has no mechanism via the LOG target for reporting the actual content of a packet, and as noted in Chapter 10, it is not generally feasible to simply put content strings within the log prefix due to the 29-character limit on prefix string length. It is also not a good idea to include binary packet data within syslog messages.
Snort Rule ID, Message, and Reference Information
Finally, at ❹ psad reports on the Snort rule ID (2281 in this case), the class type the rule belongs to (web-application-activity), and the message field (WEB-PHP Setup.php access). Also included is a Bugtraq link, which can provide valuable information to you as an administrator trying to investigate the nature of the attack and determine what a successful exploit might have meant for the security stance of your network. This reference information is included within the original Snort rule and cached for reporting by psad, as you can see in the psad email alert.
* * *
[64] 1 This assumes that the system running iptables is not receiving packet data from a span port on a switch or via a similar mechanism. This is normally a good assumption because iptables is designed to enforce a security policy against live packet data that is destined for real systems; enforcing policy against passively collected packets is of little use.
[65] 2 See http://www.securityfocus.com/bid/9057/ discuss for more information on this vulnerability.
Revisiting Active Response
In Chapter 8 and Chapter 10, we explored the implications of removing the shackles that normally restrict psad and fwsnort to purely passive detection operations and configuring them instead to actively respond to attacks. In this section we'll continue the discussion of active response, but we now approach the subject with an eye toward using the response abilities of psad and fwsnort simultaneously.
psad vs. fwsnort
Although psad can instantiate persistent time-out-based iptables blocking rules against an attacker when an attack is detected, it cannot itself tear connections down or stop the initial packet that matches an application layer signature from being forwarded. In the case of fwsnort, on the other hand, the DROP and/or REJECT targets can be used to thwart individual malicious packets and sessions, but fwsnort cannot construct a new iptables rule that blocks an attacker for an extended period of time.
Given the strengths of each tool, it would be advantageous if the two response styles could be combined. After all, fwsnort might be great at detecting and stopping a specific attack contained within a particular TCP session, but without psad to manage a persistent blocking rule, the attacker is free to try another exploit against the same target. The act of detecting the first exploit attempt may be regarded as fairly lucky; a subsequent exploit attempt may not necessarily be detected at all, so a persistent blocking rule can be important. This is especially true if the attacker possesses an additional exploit for a vulnerability that is unrelated to the first attack and for which there is no signature. In addition, if an attacker uses the Tor anonymizing network (http://tor.eff.org) to launch attacks against TCP services, then blocking individual IP addresses is useless, because each attack will appear to come from a different exit router (which is randomly chosen by Tor for each TCP session).
Note
Although mentioned in Chapter 9, let me state it again here for emphasis: A crafty