Unsupported Snort Rule Options

So far we have made the case that iptables is well suited to emulate a decent percentage of the Snort rules language entirely within the kernel. However, there are many options in Snort for which there is no good iptables equivalent, and we'll conclude this chapter with a discussion of these options.

NOTE Some options discussed below, such asack, fragbits, and somebyte_test andbyte_jump functionality, can be emulated with the iptables u32 extension (mentioned earlier in this chapter). In addition, options that have previously been discussed, such as id, seq, icmp_id, and icmp_seq can also be emulated with the u32 extension; they allow full matching and filtering support instead of iptables being able to just log these header fields. Once the u32 extension is ported to the 2.6 kernel, it will be supported in an upcoming release of fwsnort.

Unsupported options include the following:

asn1 The asn1 keyword allows Snort to link signatures to decoded Abstract Syntax Notation One (ASN.1) data (commonly used in SMB protocols). There is no good way to emulate the complex processing associated with this Snort keyword in iptables.

byte_jump The byte_jump option allows packet data itself to determine how many bytes of data Snort will skip over before applying the next pattern match or byte_test. This means that offsets do not have to be known a priori, and therefore the protocol itself can dictate where the subsequent test is performed. This is especially useful for protocols that use fields that vary in length (such as DNS). Just as for the byte_test keyword above, using the u32 match is the best way to emulate the byte_jump test with iptables, but we'll have to wait until the u32 match is available in the 2.6 kernel.

byte_test This option gives Snort the ability to apply numeric tests to particular offsets within packet data. Although the pcre option can be used to emulate some of the functionality provided by byte_test (for example, the regular expression ".{20}5\d{3}" will match any four-digit number greater than 4,999 beginning at the twenty-first byte), this should normally be avoided, because byte_test will generally outperform pcre for such operations. The u32 match can also be used to emulate this to some degree, but it is not yet available for the 2.6 kernel.

flowbits This option is used by Snort to communicate state information between rules. For example, an initial Snort rule might detect whether the login stage of a cleartext protocol has completed, and if so, set a tag LoggedIn via the flowbits option. Then a completely different Snort rule could also use the flowbits option to test whether the LoggedIn tag has been set before performing an additional signature test on the packet data. This type of operation can be emulated to a limited extent by combining the CONNMARK target in iptables with the string match extension, but this is not yet supported by fwsnort. The L7-filter packet classifier project could also be used to emulate this to some degree (see http://l7-filter.sourceforge.net).

fragbits This option allows Snort to perform tests against the fragmentation bits in the IP header. Although iptables can apply match criteria to determine whether a packet has been fragmented (via the -f argument), this capability is not nearly as powerful as the Snort implementation. In addition, if connection tracking is enabled in the Linux kernel, packets are automatically defragmented before iptables sees them. This is a requirement for connection tracking to work, because only complete packets can be classified as either belonging to a connection or not. This is an advantage in the sense that networks protected by such kernels automatically stop most IDS evasion attempts that rely on fragmented packets.

isdataat This option instructs Snort to test simply whether data exists at a particular offset. The offset may be specified in absolute terms (e.g., 30) or may be derived from a previous pattern match (e.g., 30,relative).

pcre This stands for Perl Compatible Regular Expression and allows Snort to apply complex regular expressions (that may include back references and other intensive operations) to packet data. Putting this functionality directly into the Linux kernel is risky from a stability standpoint; it makes more sense to perform these sorts of operations in a userland application.

rpc This allows Snort to decode the application, procedure, and program version contained within Remote Procedure Call (RPC) traffic. The iptables rpc extension allows procedure call numbers to be matched within an iptables policy, but this module is only available for pre-2.6 kernels and is not yet supported by fwsnort.

Was this article helpful?

0 0

Post a comment