Network traffic from a computer can be analyzed to detect what operating system it is running. This is to a large extent due to differences in how the TCP/IP stack is implemented in various operating systems. We will in this blog post explain the different methods that can be used to identify what operating a computer is running by analyzing the packets it generates on the network.
The popular port scanner Nmap can identify the operating system (OS) of a remote computer by sending six packets with specially crafted option combinations in the TCP layer (for example window scale, NOP and EOL options). Nmap then watches how the scanned host responds to these odd packets. Fyodor (author of Nmap) gives a good overview of these techniques in issue 54 of phrack magazine from way back in 1998.
Passive OS identification
Active measures, like those employed by Nmap, are unfortunately not available when doing passive analysis of live traffic or when analyzing previously captured network traffic. Passive analysis requires much more subtle variations in the network traffic to be observed, in order to identify a computer's OS. A simple but effective passive method is to inspect the initial Time To Live (TTL) in the IP header and the TCP window size (the size of the receive window) of the first packet in a TCP session, i.e. the SYN or SYN+ACK packet.
Below are some typical initial TTL values and window sizes of common operating systems:
|Operating System (OS)||IP|
|Linux (kernel 2.4 and 2.6)||64||5840|
|Google's customized Linux||64||5720|
|Windows 7, Vista and Server 2008||128||8192|
|Cisco Router (IOS 12.4)||255||4128|
One reason for why the TTL and window size values varies between different OS's is because the RFC's for TCP and IP do not require implementations to use any particular default value for these fields. There is, however, a recommendation in RFC 1700 saying:
The current recommended default time to live (TTL) for the Internet Protocol (IP) is 64This recommendation is obviously not followed in many IP implementations.
The initial TTL value is often a bit tricky to analyze since the TTL value of a sniffed packet will vary depending on where you sniff it from. The sending host will set the TTL value to the OS's default TTL value, but this value will then be decremented by one for every router the packet passes on its way to the destination IP address. An observed IP packet with a TTL value of 57 can therefore be expected to be a packet with an initial TTL of 64 that has done 7 router hops before it was sniffed.
The TTL and window size table above can be used in order to do manual OS fingerprinting of network traffic. Here is an example showing how to display relevant fields of the first few packets from the publicly available pcap file for the 2009-M57-Patents scenario with tshark:
$ tshark -r day12-1.dmp -R "tcp.flags.syn eq 1" -T fields -e ip.src -e ip.ttl -e tcp.window_size -c 16 | sort -u
192.168.1.105 128 8192
192.168.1.106 128 65535
126.96.36.199 54 5720
188.8.131.52 45 5840
184.108.40.206 45 5840
220.127.116.11 45 5840
18.104.22.168 45 5840
22.214.171.124 45 5840
126.96.36.199 45 5840
188.8.131.52 45 5840
The first column here is the IP address (ip.src), the second is the TTL (ip.ttl) and the third the TCP window size (tcp.window_size). Note that the TTL value is only at the initial value for the hosts on the local network (192.168.1.0/24), while the packets from the other hosts seem to have performed 10 or 19 router hops. We can, just by matching the TTL and window sizes of these hosts with the table above, easily determine that 192.168.1.106 is running Windows XP (TTL=128, window_size=65535) and 192.168.1.105 is running some more modern flavor of Windows (TTL=128, window_size=8192). The google machine (with IP 184.108.40.206) can also easily be singled out due to its characteristic window size of 5720. The other machines (87.106.x.x) all seem to be running Linux.
Do you feel manual OS classification would take too much time? There are, luckily, multiple tools like ettercap, p0f, Satori and NetworkMiner which all automate the OS identification task. Just feed these tools with some live network traffic or a pcap file and they'll fingerprint the OS's for you.
An alternative to fingerprinting the TCP/IP stack implementation of an OS is to look at its DHCP implementation. Eric Kollmann (the creator of Satori) has written a great paper on DHCP fingerprinting titled Chatter on the Wire: A look at DHCP traffic. Eric's DHCP fingerprinting database is used in his tool Satori as well as in NetworkMiner.
There is also a project titled Fingerbank, which maintains another DHCP fingerprinting database.
Even more info about the operating system of a host can be extracted by inspecting the application layer data in traffic, such as server banners in HTTP, SSH and FTP as well as HTTP client User-Agent strings. All these layer 7 banner types are displayed in NetworkMiner's Hosts tab under the “Host Details” node.
A User-Agent string showing “Windows NT 5.1” (like in the screen shot above) means that the client is running Windows XP. Microsoft provides an article titled Understanding User-Agent Strings, which provides this mapping between User-Agent strings and operating system:
|Windows NT 6.1||Windows 7|
|Windows NT 6.0||Windows Vista|
|Windows NT 5.2||Windows Server 2003; Windows XP x64 Edition|
|Windows NT 5.1||Windows XP|
Posted by Erik Hjelmvik on Saturday, 05 November 2011 14:45:00 (UTC/GMT)