Linux Firewalls - Michael Rash [75]
The second field, 64, refers to the TTL value in the IP header; in this case a TTL of 64. Because TTL values are decremented as packets traverse the Internet, this field refers to the initial TTL value, and p0f allows the actual TTL value in the packet to be significantly less.
The third field, 1, refers to the Don't Fragment (DF) bit in the IP header. Because the signature has the value 1 in this field, it is looking for the DF bit to be set.
The fourth field, 60, is the overall packet size. In this example, the signature requires the size to be 60 bytes.
The fifth field, S,T,N,W1, describes the options portion of the TCP header. In this example, the signature is looking for any MSS, followed by the Selective Acknowledgment (S), Timestamp (T), NOP (N), and Window Scaling Factor (W1) options.
Note
A comprehensive treatment of passive OS fingerprinting (and other passively collected information) can be found in Michal Zalewski's Silence on the Wire (No Starch Press, 2005).
Emulating p0f with psad
In order to run its fingerprinting algorithm over packet headers, p0f uses libpcap to sniff packets directly off the wire. By contrast, psad contains code that implements OS fingerprinting based around p0f signatures but only requires iptables log messages as the data input. This is possible because every header value examined by p0f (TCP window size, TTL value, TCP options, and so on) is also available in iptables log messages as long as the --log-tcp-options argument is used to build the LOG rule. Here's an example LOG message in which the options portion of the TCP header is shown in bold:
Jul 14 22:03:42 iptablesfw kernel: DROP IN=eth1 OUT= MAC=00:13:46:3a:41:4b: 00:a0:cc:
28:42:5a:08:00 SRC=192.168.10.3 DST=192.168.10.1 LEN=60 TOS=0x10 PREC=0x00 TTL=64 ID=
37356 DF PROTO=TCP SPT=54423 DPT=23 WINDOW=5840 RES=0x00 SYN URGP=0 OPT (020405B
4040
2080A0B00CE790000000001030302)
Decoding TCP Options from iptables Logs
The only tricky part to implementing p0f OS fingerprinting with log messages like the one shown above is that the long OPT hex dump has to be decoded in order to match up against a p0f signature. The OPT string represents a hex dump of the TCP options portion of the TCP header, and by examining this string one byte at a time and matching it against the set of possible options values in the TCP header (http://www.iana.org/assignments/tcp-parameters), the options used in a SYN packet become clear. Except for the End of Option List and No Operation (NOP) options which are each only one byte wide, every option is designated by a type, is followed by the length, and ends with the value. This is called Type-Length-Value (TLV) encoding.
For example, the beginning of the hex string above, 020405B4, decodes as 02 = Maximum Segment Size, 04 = Length (including the type byte), 05B4 = 1460 (decimal value). Continuing this analysis similarly for the entire hex dump yields the following:
Maximum Segment Size is 1460
NOP
Selective Acknowledgment is OK
Timestamp is 188338970
Window Scaling Factor is 2
This set of options matches the p0f fingerprint S4:64:1:60:M*,S,T,N,W2: Linux:2.5::Linux 2.5 (sometimes 2.4), which is indeed correct, because I generated the connection attempt to TCP port 23 from a machine running the 2.6.11 kernel, and the 2.5 series was the development series for the 2.6 kernel.
By matching the TCP options in SYN packets against p0f signatures, psad can often identify the specific remote operating system that is poking at your iptables firewall. This functionality is only made possible, however, through the use of the --log-tcp-options argument, so I highly recommend that you use this option when adding your default LOG rule to your iptables policy.
DShield Reporting
The DShield distributed intrusion detection system (http://www.dshield.org) is an important instrument for the collection and reporting of security event data. It serves as a centralized depot for data provided by various software from both the open source and commercial worlds,