LNCS 2820 - Ambiguity Resolution via Passive OS Fingerprinting
LNCS 2820 - Ambiguity Resolution via Passive OS Fingerprinting
LNCS 2820 - Ambiguity Resolution via Passive OS Fingerprinting
You also want an ePaper? Increase the reach of your titles
YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.
<strong>Ambiguity</strong> <strong>Resolution</strong> <strong>via</strong> <strong>Passive</strong> <strong>OS</strong> <strong>Fingerprinting</strong> 199<br />
Table 1. Enumeration of the possible combinations of TCP options, padded appropriately<br />
with nop options .<br />
# Possible combinations of TCP options<br />
1 mss 1460<br />
2 timestamp nop nop<br />
3 sackok nop nop<br />
4 wscale 0 nop<br />
5 wscale 0 nop sackok nop nop<br />
6 wscale 0 nop mss 1460<br />
7 wscale 0 nop timestamp nop nop<br />
8 sackok nop nop mss 1460<br />
9 sackok nop nop timestamp nop nop<br />
10 mss 1460 timestamp nop nop<br />
11 timestamp nop nop sackok nop nop wscale 0 nop<br />
12 mss 1460 sackok nop nop wscale 0 nop<br />
13 mss 1460 timestamp nop nop wscale 0 nop<br />
14 mss 1460 timestamp nop nop sackok nop nop<br />
15 mss 1460 timestamp nop nop sackok nop nop wscale 0 nop<br />
TCP SYN segments are sent with the 2 4 different possible combinations of TCP<br />
options, as shown in Table 1<br />
We can encode options ordering to simplify a later lookup to an int comparison.<br />
A bit-field can be used to identify the options present in the client’s<br />
SYN segment. Since we use the most prevalent options, (timestamp, mss, wscale,<br />
sackok), we only need bits bits, and can encode them as shown in Table<br />
2.<br />
These tests allow us to build 16 sub-tables for SYNACK lookups. When<br />
a lookup is requested for a SYNACK, we take the encoded value of the TCP<br />
options present in the SYN segment, as shown in Table 2, for which the SYNACK<br />
corresponds, and hash into one of the 16 sub-tables to match the SYNACK TCP<br />
and IP values.<br />
The TCP Timestamp. Another ambiguous bit of behavior was discovered<br />
during testing. This has to do with network stack implementations of the TCP<br />
Timestamp option.<br />
RFC 1323 specifies the requirement for using TCP timestamps as a method to<br />
calculate “reliable round-trip time estimates”[18] between two connected hosts.<br />
Specifically, section 3.2 states:<br />
“The Timestamp Echo Reply field (TSecr) is only valid if the ACK bit is set<br />
in the TCP header; if it is valid, it echos a timestamp value that was sent by<br />
the remote TCP in the TSval field of a Timestamps option. When TSecr is not<br />
valid, its value must be zero.”<br />
However, some operating systems do not set the TSecr field to the TSval<br />
given in the sent TCP SYN segment of a SYNACK reply, where the sent SYN
Change language