Linux Firewalls - Michael Rash [104]
01:10:24.479216 IP 192.168.10.1.80 > 192.168.10.2.32655: S 2434738187:2434738187(0)
ack 2179395559 win 5792 01:10:24.481620 IP 192.168.10.2.32655 > 192.168.10.1.80: . ack 1 win 5840 01:10:24.481843 IP 192.168.10.1.80 > 192.168.10.2.32655: P 1:2(1) ack 1 win 5792 01:10:24.488910 IP 192.168.10.2.32655 > 192.168.10.1.80: P 1:13(12) ack 1 win 5840 < nop,nop,timestamp 47589527 10356968> ❶01:10:24.488941 IP 192.168.10.1.80 > 192.168.10.2.32655: R 2434738188:2434738188(0) win 0 01:10:24.490785 IP 192.168.10.2.32655 > 192.168.10.1.80: . ack 2 win 5840 01:10:24.490820 IP 192.168.10.1.80 > 192.168.10.2.32655: P 2:3(1) ack 1 win 5792 01:10:24.496571 IP 192.168.10.2.32655 > 192.168.10.1.80: . ack 3 win 5840 01:10:24.683462 IP 192.168.10.2.32655 > 192.168.10.1.80: P 1:13(12) ack 3 win 5840 < nop,nop,timestamp 47589578 10356971> ❷01:10:24.683506 IP 192.168.10.1.80 > 192.168.10.2.32655: R 2434738190:2434738190(0) win 0 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 as ack, fragbits, and some byte_test and byte_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