Linux Firewalls - Michael Rash [94]
00 05 80 02 00 01 80 03 00 03 80 04 00 02 80 0B 00 01 00 0C 00 04 00 01|Q|80 00 00 00
10|" --algo bm -j REJECT --reject-with icmp-port-unreachable
* * *
[51] 4 A clever attacker may find a different way to extract the Nmap scan output from a webserver such as having the webserver email it out instead of returning it over a web session, but this is not always possible.
The fwsnort Interpretation of Snort Rules
Now that you've seen some examples of translated Snort rules, it's time to dive into the translation specifics. Not every Snort rule can be translated, because of limitations in facilities provided by iptables versus those provided by Snort, as we'll see.
Network-based attacks exhibit huge variability. Not only are new vulnerabilities announced in all sorts of software at a dizzying pace, but both TCP/IP and application-specific APIs make it possible to deliver attacks using those vulnerabilities in non-obvious ways. Packet fragmentation, TCP session splicing, various application encodings, and the like (as discussed in Chapter 2 through Chapter 4) can make attacks more difficult to detect by passive monitoring systems that merely watch traffic as it happily flows by on the wire.
Translating the Snort Rule Header
Snort rules are split into two major sections: the rule header and the rule options. The rule header strictly defines match criteria at the network and transport layers; no application layer matching criteria can be placed within the Snort rule header.
Snort Rule Header
For example, a Snort rule header that instructs Snort to match all TCP traffic from any source address to port 53 on any IP address within the 192.168.10.0/24 subnet looks like:
alert tcp any any -> 192.168.10.0/24 53
From a signature perspective, this header is roughly equivalent to the following iptables command:
[iptablesfw]# iptables -A FORWARD -p tcp -d 192.168.10.0/24 --dport 53 -j LOG
First, Snort supports IP, ARP, UDP, ICMP, and TCP within the rule header directly (with behind-the-scenes support for additional protocols). Next, the address portion of the Snort rule header allows Snort rules to apply to specific networks or individual IP addresses. Networks can be specified in CIDR notation (e.g., 192.168.10.0/24) or in standard dotted-quad notation (e.g., 192.168.10.0/255.255.255).
Lastly, transport layer source and destination port numbers are defined. A range of ports can be specified with the colon (:) character (e.g., 21:23 would apply to ports 21 through 23), and port numbers can also be negated with the exclamation point (!) character (e.g., !80 would apply to all ports except port 80).
SNORT HEADER WILDCARDS AND VARIABLE RESOLUTION
Any of the match criteria in the Snort rule header (with the exception of the protocol) can be set to the wildcard value any so that Snort will not restrict its inspection to a particular IP address or port number. Snort also supports the definition of a variable whose associated value (such as a list of IP addresses or port numbers) is specified in the snort.conf configuration file.
For example, many web-based rules in Snort contain the header:
alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS
The actual definition of the $HTTP_SERVERS variable might be the list [192.168.10.5,192.168.10.6] in the snort.conf file.
Rule Actions and iptables Emulation
Rule actions can be either alert, log, pass, activate, or dynamic, though Snort rules generally default to alert. The alert action is the most important—it tells Snort to generate an event and then log the packet that caused the alert. The remaining actions provide additional functionality, such as passing the packet without taking any action (pass), logging the packet (log), or setting up certain rules so that they remain dormant until a particular rule is matched, at which point they become active and log the traffic (activate and dynamic).
So far, everything but the activate and dynamic actions in the Snort rule header is