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 subnet looks like:

From a signature perspective, this header is roughly equivalent to the following iptables command:

[iptablesfw]# iptables -A FORWARD -p tcp -d --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., or in standard dotted-quad notation (e.g.,

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

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:


The actual definition of the $HTTP_SERVERS variable might be the list [,] 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 supported by analogous functionality in iptables and fwsnort.


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 subnet, you would use -d

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 Chapters 2 and 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 writer5), 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.

Was this article helpful?

0 0

Post a comment