So far we have covered operational and theoretical aspects of both fwsnort and psad individually, but we have yet to put the two programs together. Although psad provides detection, alerting, and auto-response capabilities, the effectiveness of its detection engine is fundamentally limited by the characteristics of the iptables logging format. Better attack detection is offered by fwsnort, including detection for application layer attacks. And because iptables is always inline to network traffic,[64] fwsnort can (optionally) prevent malicious packets from reaching their intended targets.
However, because an iptables policy derived from fwsnort runs entirely within the Linux kernel, it cannot perform various alerting functions that are typically possible with a userland application. We need a mechanism for tying the signature detection prowess of fwsnort together with psad's ability to issue whois queries, reverse DNS lookups, send email alerts, associate danger levels with malicious IP addresses, and communicate attack information to DShield.
In this chapter we'll discuss ways to maximize the effectiveness of both psad and fwsnort by using them to reinforce each other. The chapter culminates with a discussion of how to develop a signature to detect Metasploit updates and how to use both fwsnort and psad to interfere with such activity.
As discussed in Chapter 10, when it detects an attack, fwsnort generates an iptables log message. This message contains a log prefix that informs the user about the specific Snort rule ID that triggered the log message, the rule number within the fwsnort chain, and whether the corresponding packet is part of an established TCP session.
Let's look at how fwsnort and psad would deal with an attack against the MediaWiki software.
Snort rule ID 2281 is designed to detect an attempt to exploit an input validation weakness in the MediaWiki software (the software originally designed to power Wikipedia; see http://www.wikipedia.org). This vulnerability is described by Bugtraq ID 9057, and is labeled as the WEB-PHP Setup.php access attack by Snort rule ID 2281. A successful exploit of the vulnerability could lead to unauthorized remote execution of code on the targeted system upon receipt of specially constructed URI parameters within an HTTP request.[65] We'll simulate an attack designed to exploit the WEB-PHP Setup.php access vulnerability against the internal webserver (hostname webserver in Figure 1-2). We assume that the default iptables policy (created by the iptables.sh script) is deployed on the iptablesfw system, and the simulated attack is launched from the ext_scanner system (IP address 144.202.X.X).
First, we verify that we can make a web connection from the ext_scanner system to the webserver through the iptables firewall using the text-based web browser lynx. (The webserver has been configured to display the string Internal webserver; happy browsing upon receiving a valid web request for the index.html page.)
[ext_scanner]$ lynx http://71.157.X.XInternal webserver; happy browsing
With web connectivity demonstrated through the iptables firewall, we'll simulate the attack before deploying fwsnort or psad so that we know what to expect in return. First, here is Snort rule ID 2281, which is designed to detect attempts to exploit the vulnerability labeled by Bugtraq ID 9057:
alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg:"WEB-PHP Setup.php access"; flow:to_server,established; uricontent:"/Setup.php"; nocase; reference:bugtraq,9057; classtype:web-application-activity; sid:2281; rev:2;)
With the exception of the string /Setup.php, the above rule does not care about the specifics of the URI parameters requested from the webserver (which may vary depending on what the attacker is trying to accomplish). The signature is strictly looking for the string /Setup.php in the URI portion of a web request, and this data must be seen in an established TCP connection, as required by the flow keyword. This makes simulating an exploit for the vulnerability quite easy:
[ext_scanner]$ lynx http://71.157.X.X/Setup.php 404 Not Found The requested URL /Setup.php was not found on this server. Apache/2.0.54 (Fedora) Server at 71.157.X.XPort 80
This tells us that our internal webserver is not vulnerable, and because it is not running MediaWiki, we predictably get a 404 Not Found error indicating that the requested page is not available. Remember we are simulating the attack—we just need to create network traffic that looks like what the Snort signature is trying to find.
Now we run fwsnort without the --ipt-drop or --ipt-reject arguments (for now) to detect the WEB-PHP Setup.php access attack with iptables:
[iptablesfw]# fwsnort --snort-sid 2281
[+] 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: 2
If you look through the /etc/fwsnort/fwsnort.sh script, you will see an iptables command that uses the string match extension and the custom FWSNORT_FORWARD_ESTAB chain to detect the /Setup.php string within established TCP connections. This command appears below, and does the heavy lifting for detecting the attack:
$IPTABLES -A FWSNORT_FORWARD_ESTAB -p tcp --dport 80 -m string --string
"/Setup.php" --algo bm -m comment --comment "sid:2281; 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] SID2281
ESTAB "
The text in bold is the iptables log prefix. This string is included within iptables log messages triggered when iptables detects the string /Setup.php over a web session. For example, if we execute the same lynx http://71.157.X.X/Setup.php command from the ext_scanner system against the webserver, we get this iptables log message:
Jul 19 23:49:18 iptablesfw kernel:[1] SID2281 ESTABIN=eth0 OUT=eth1 SRC=144.202.X.XDST=192.168.10.3 LEN=276 TOS=0x00 PREC=0x00 TTL=63 ID=8317 DF PROTO=TCP SPT=47299 DPT=80 WINDOW=92 RES=0x00 ACK PSH URGP=0 OPT (0101080A0CA8DB00E9FBEB4A)
The attack has been detected by fwsnort, but it has only generated a log message from iptables; it has not performed any whois lookups or sent email alerts, because these are beyond the scope of its functionality.
However, because fwsnort generates an iptables log message, psad can analyze it and apply its alerting and reporting machinery to the event. But first, psad needs to properly handle fwsnort log messages. After all, these messages are generated via the inspection of application layer data, but the data itself is not included in the log messages.
The key to interpreting the log messages is the SNORT_SID_STR variable in the /etc/psad/psad.conf file. This variable describes the portion of the log prefix that psad must see in order to infer that the log message is generated by fwsnort. By default, SNORT_SID_STR is set as follows:
SNORT_SID_STR SID;
Any iptables log message that contains a logging prefix with the SID substring is a message generated by fwsnort, and these are nearly always for application layer attacks.
We now make sure psad is running (execute /etc/init.d/psad start) and then simulate the attack again. This time, psad captures the iptables log message, parses it, and generates the email alert shown below. (We've removed whois information that normally accompanies a psad alert, for brevity.)
Danger level: [3] (out of 5) Scanned TCP ports: [80: 1 packets] ❶ TCP flags: [ACK PSH: 1 packets] iptables chain: FWSNORT_FORWARD_ESTAB (prefix ❷"[1] SID2281 ESTAB"), 1 packets fwsnort rule: 1 Source: 144.202.X.XDNS: [No reverse dns info available] OS guess: Linux:2.6:17:Linux 2.6.17 and newer (?) Destination: 192.168.10.3 DNS: web_server Overall scan start: Thu Jul 19 23:48:18 2007 Total email alerts: 2 Complete TCP range: [80] Syslog hostname: iptablesfw Global stats: chain: interface: TCP: UDP: ICMP: FORWARD eth0 2 0 0 ❸ [+] TCP scan signatures: "WEB-PHP Setup.php access" dst port: 80 flags: ACK PSH content: "/Setup.php" ❹ sid: 2281 chain: FWSNORT_FORWARD_ESTAB packets: 1 classtype: web-application-activity reference: (bugtraq) http://www.securityfocus.com/bid/9057
The psad email alert shown above appears fairly normal and includes all of the standard information, such as timestamps, packet counts, TCP flags and ports, and so on. However, several pieces of information in this alert deserve special attention.
All TCP flags that are present in TCP packets that generate iptables log messages are reported by psad. In the case of the WEB-PHP Setup.php access attack, the particular TCP packet that triggers the fwsnort policy to trigger a log message is part of an established TCP session, and so the ACK and PSH flags are reported as being set at ❶. The prefix [1] SID2281 ESTAB (❷) also clearly indicates that the packet is logged by an fwsnort chain that is making use of state matching to track established TCP connections, so the attacker cannot force fwsnort to generate the log message just by spoofing a TCP ACK packet that contains the /Setup.php string from an arbitrary source address.
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.
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.