Linux Firewalls - Michael Rash [92]
Note
Because fwsnort just builds a shell script to execute iptables commands, it is easily deployed on many systems with something like Zenoss (http://www.zenoss.org), which can execute commands via SSH over many remote systems in one fell swoop. This makes it easy to leverage fwsnort across all Linux systems in your infrastructure.
* * *
[48] 1 The first versions of fwsnort were based originally on the shell script snort2iptables written by William Stearns (see http://www.stearns.org/snort2iptables).
[49] 2 Both the Snort-2.3.3 ruleset and the Bleeding Snort ruleset (see http://www.bleedingsnort.com) are freely distributed with the fwsnort sources, and are not subject to the licensing terms of the VRT signatures distributed by Sourcefire.
[50] 3 I emphasize IPS here because, in the case of IDS, Snort can use the shared memory page method of grabbing packet data from the kernel (which requires CONFIG_PACKET_MMAP support in the kernel), and this has less of an impact on performance than getting packet data over a netlink socket, as Snort does in IPS mode.
Signature Translation Examples
Before jumping into theoretical aspects of translating Snort rules into iptables rules with fwsnort, we'll look at a few Snort rules that have already been translated.
Nmap command attempt Signature
The Nmap command attempt signature in the Snort file web-attacks.rules detects attempts to execute the Nmap scanner via a webserver.
This signature is useful for detecting attempts of an attacker to use a webserver to scan other systems that may be more easily accessed by the webserver—local firewall rules may be more forgiving to webserver communications than to the attacker's IP address (especially if the webserver is directly connected to an internal network). An attacker would typically abuse a CGI application that does not properly filter user input in order to perpetrate such a scan attempt.
The signature is triggered whenever the string "nmap%20" is transferred across an established TCP connection (as shown in bold below):
alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg:"WEB-ATTACKS nmap
command attempt"; flow:to_server,established; content:"nmap%20"; nocase; classtype:
web-application-attack; sid:1361; rev:5;)
The Nmap execution signature is elegant; it detects a suspicious activity in a generic way. Snort does not have to interpret whether a CGI application is vulnerable to the Nmap attempt—the attempt itself is suspicious.
Recasting this signature into an iptables policy with fwsnort results in the rule shown below. We'll discuss the specifics of the iptables command in depth in Chapter 10, but for now, note that this is an iptables LOG rule that uses the iptables string match to mimic what the Snort rule is looking for in network traffic. The iptables comment match is also used to tag the rule in the kernel with the original Snort msg field:
$IPTABLES -A FWSNORT_FORWARD_ESTAB -p tcp --dport 80 -m string --string "nmap%20"
--algo bm -m comment --comment "sid:1361; msg: WEB-ATTACKS nmap command attempt;
classtype: web-application-attack; rev: 5; FWS:1.0;" -j LOG --log-ip-options --log-
tcp-options --log-prefix "[20] SID1361 ESTAB "
Another way to write a signature to detect inappropriate Nmap executions via a webserver is to look for Nmap output that is returned from a webserver to a web client. This is more effective for detecting successful Nmap executions instead of detecting mere attempts to abuse a CGI application because a (non-malicious) server does not have the freedom to obfuscate the data it returns to try and evade intrusion detection systems—attackers do have this freedom and