Linux Firewalls - Michael Rash [95]
Source and destination IP addresses or networks can be specified to iptables with the -s IP and -d IP arguments, respectively, and both CIDR and dotted-quad network notations are also supported. Source and destination port numbers can be given with the --sport port and --dport port options, and as with Snort, port ranges are specified with the colon (:) character. The protocol can be given with -p protocol.
For example, to build an iptables rule that applies to TCP traffic, you would use the -p tcp argument to the iptables command. To restrict the rule to destination port 53, you would use --dport 53. To apply the rule to the destination of any IP address in the 192.168.10.0/24 subnet, you would use -d 192.168.10.0/24.
Snort Actions and Alerting
Snort provides several excellent options for generating alerts and logging packet data; fortunately, iptables (together with additional userland code to interpret iptables log messages) can emulate a significant fraction of these capabilities. As mentioned in Chapter 2 and Chapter 3, log messages generated by the iptables LOG target contain nearly all of the interesting fields in the network and transport layer headers. In Chapter 4 we saw that iptables can search application layer data for suspicious activity with the string match extension. With fwsnort, we combine these abilities to emulate the following Snort actions:
alert
This is the main Snort rule action, and within fwsnort it is equated with the usage of the iptables LOG target to log Snort signature msg fields within the log prefix and packet header information in the remainder of the log message. Within iptables, we don't have the ability to log application layer data (unless the ULOG target is used along with the ulogd PCAP writer[52]), but at least the attacks are logged via the msg field.
log
Within fwsnort, this action is equated with the iptables ULOG target, where the ulogd PCAP writer is used for more comprehensive packet logging.
pass
This action is sometimes used in Snort rulesets to ignore packets, and is equated with the usage of the iptables ACCEPT target by fwsnort. The ACCEPT target allows matching traffic to pass without any modifications or further action taken by iptables.
The activate and dynamic actions are not yet supported by fwsnort, but this is not because of a limitation in iptables; it would significantly complicate both the iptables policy and the script required to build it, because a separate chain would have to be constructed for each dynamic rule.
Translating Snort Rule Options: iptables Packet Logging
Snort's complex packet processing is mostly driven by rule options (with exceptions for work performed by preprocessors that have code dedicated to solving specific problems such as TCP stream reassembly or port scan detection).
Snort depends on these options to define what constitutes an attack or other activity worthy of sending an alert to the administrator, and the number of available options has expanded to meet the demands of an ever-changing exploit landscape.
We'll first discuss iptables logging versus filtering capabilities, and how some of the most important Snort rules options can be represented within iptables. Then we'll discuss those Snort rule options for which there is no good iptables equivalent (such as the pcre and asn1 options). These options describe packet-matching requirements in the Snort rules language that cannot be expressed within iptables; the lack of such functionality is the reason fwsnort cannot achieve a 100 percent conversion rate.
The iptables LOG target allows us to generate detailed logs of packet header information when packets trigger a logging rule (Chapter 2 through Chapter 4 gave examples of iptables logging messages). Although iptables can match and filter packets based upon most of the important fields in its logs (such as source and destination IP addresses, Internet protocol, and transport layer port numbers), some fields within the network and transport layer headers