Linux Firewalls - Michael Rash [101]
Like many other Snort options, ip_proto allows negation and ranges via the !, <, and > operators. In addition, Snort supports multiple ip_proto options within the same rule (e.g., ip_proto: !1; ip_proto: !2;). Protocol negation is also supported by iptables with the ! operator, but protocol ranges and multiple protocols within a single rule are not supported. For reference, a complete listing of all currently assigned IP numbers can be obtained from http://www.iana.org/assignments/protocol-numbers.
An example command designed to have iptables log all General Routing Encapsulation (GRE) packets, which are transmitted over IP 47, appears below:
[iptablesfw]# iptables -A INPUT -p 47 -j LOG --log-prefix "GRE PACKET "
flow
The flow Snort option is one of the more important features of the Snort rules language and is used in conjunction with the stream preprocessor.[57] The flow option enables a Snort rule to apply state and direction criteria against a reassembled TCP stream.
For example, to require that a particular rule only apply to data that originates from the client side of a TCP connection, and then only after the three-way TCP handshake has completed (i.e., the connection is in the "established" state), we could use the option flow: from_client,established. The stream preprocessor is only applicable to TCP traffic (although stream5 has time-out-based support for UDP and ICMP as well).
Before the stream preprocessor and its flow keyword interface in Snort rules, it was possible to spoof malicious-looking TCP packets from arbitrary source IP addresses and cause Snort to generate alerts even though there was no legitimate TCP session. Snort's ability to check the flags portion of the TCP header to see if the acknowledgment bit was set was easily circumvented by simply manually setting the ACK bit in the spoofed packets. The tools Stick and Snot were among the first programs to create these "stateless" attacks against Snort. A similar Perl implementation snortspoof.pl, available from the fwsnort project, uses the hping utility (see http://www.hping.org) to spoof Snort content fields across the wire (see Appendix A). An attacker could use these tools to make it appear as though a completely unrelated IP address is sending a highly dedicated attack across the network. Such an attack serves to divert the administrator's attention from any seemingly innocuous and puny attack originating from the attacker's real IP address.
By tracking TCP connections and their corresponding states, the stream preprocessor provides an effective mechanism for thwarting such stateless attacks. For a TCP connection to reach the established state, the standard three-way TCP handshake must be completed, and this in turn implies packets must be sent in both directions. A spoofed TCP ACK packet can never qualify as part of a legitimate TCP connection unless the spoofed packet happens to have the same source and destination ports, and plausible sequence and acknowledgment numbers, of an existing connection between the target and the spoofed IP address. This is exceedingly unlikely unless the attacker is already in a position to be able to monitor TCP connections coming into or out of your network, and people with that level of access are most likely not going to be interested in spoofing packets into an established session anyway; they will go after more fruitful targets, such as the direct compromise of additional systems.[58] Currently, nearly 90 percent of all Snort rules utilize the flow option to apply application checks against TCP connections that are in the established state.
Through the use of connection-tracking facilities, iptables is a stateful firewall and as such provides a connection-tracking mechanism for not only TCP connections