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: 4000500;. 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.8
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.
8 There are some technicalities here. For example, the average header length of TCP ACK packets is substantially less than the header length of a TCP SYN packet because connection initialization parameters such as the Maximum Segment Size (MSS) are not re-advertised within an established TCP connection. TCP ACKs sometimes only contain the timestamp option and perhaps a couple of NOPs.
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 "
Was this article helpful?