• Choose a category
• All
• Classic-Fiction

Tying fwsnort Detection to psad Operations

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.

WEB-PHP Setup.php access Attack

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.X

Internal 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.X Port 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.

Detecting the Attack with fwsnort

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