Linux Firewalls - Michael Rash [100]
For example, to test for the Loose Source Route option, the arguments -m ipv4options --lsrr would be given to iptables. To detect the Strict Source Route option, we would use -m ipv4options --ssrr. To detect the Record Route option, which can be used to assist in the mapping of networks, we would use -m ipv4options --rr (see the complete iptables command example below). The ipv4options match requires that CONFIG_IP_NF_MATCH_IPV4OPTIONS is enabled in the kernel configuration file.
[iptablesfw]# iptables -A INPUT -p ip -m ipv4options --rr -j LOG --log-prefix "RECORD
ROUTE IP OPTION "
dsize
The dsize Snort option places a requirement on the size of packet payload data. It accepts a positive integer together with an optional < or > operator to denote the number of bytes that must exist within the application portion of a packet in order for a rule to match. For example, to require that a packet contain at least 500 bytes of payload data, we could use dsize: >500; within a Snort rule. The dsize option also supports both a lower and upper bound on the range with the <> operator, like so: dsize: 400<>500;. Unfortunately, there is no direct iptables mechanism for specifying payload length by itself.
However, the iptables length match allows a decent approximation by allowing the length of the packet, including the combined lengths of the network header, transport header, and the application payload. Given the facts that IP headers are almost always 20 bytes long (IP options are not usually included), properly constructed UDP headers and ICMP Echo Request and Reply headers are always 8 bytes long, and (on average) a good approximation for the length of a TCP header is about 30 bytes (20 bytes for static fields and about 10 bytes for options), we have a good heuristic for mapping the Snort dsize option into an iptables ruleset.[56]
For example, if a Snort rule against TCP contains the option dsize: 200, then for the iptables length match we would specify a length of 20 + 30 + 200 = 250 bytes. The iptables interface to the length match is -m length --length bytes, and in a manner similar to Snort, the iptables length match also supports byte ranges: -m length --length low:high. The length match requires CONFIG_IP_NF _MATCH_LENGTH to be enabled in the kernel configuration file. However, even if the length match is unavailable, the IP header length is included within iptables log messages, and so an external application such as psad can apply the same logic to logged packets in order to make judgments about packet length. Of course, in a log analysis scenario, packet length cannot be used as a filter criterion.
Note
The average header length for the IP and TCP headers is configurable in fwsnort via the AVG_IP_HEADER_LEN and AVG_TCP_HEADER_LEN keywords in /etc/fwsnort/fwsnort.conf.
The following example iptables command constructs a rule that logs any ICMP packet that contains 1028 − 20 − 8 = 1000 bytes of application layer data (assuming no IP options are set—a safe assumption in most situations):
[iptablesfw]# iptables -A INPUT -p icmp -m length --length 1028 -j LOG --log-prefix
"LARGE ICMP MESSAGE "
ip_proto
The ip_proto Snort option allows Snort rules to be restricted to any of the possible 256 values in the protocol field within the IP header; these values are defined within the /etc/protocols file. This does not necessarily imply that Snort has special decoding capability for arbitrary Internet protocols such as, say, IP 119 (SRP, SpectraLink Radio Protocol) or IP 132 (SCTP, Stream Control Transmission Protocol); it simply means that Snort can apply application payload