IDing remote hosts, without them knowing
Passive Fingerprinting

Lance Spitzner
Last Modified: 27 April, 2000

One of the challenges of network security is learning about the bad guys.  To understand your threats and better protect against them, you have to Know Your Enemy.  Passive Fingerprinting is a method to learn more about the enemy, without them knowing it.  Specifically, you can determine the operating system and other characteristics of the remote host using nothing more then sniffer traces.  Though not 100% accurate, you can get surprisingly good results.

Fingerprinting
Traditionally, Operating System fingerprinting has been done using active tools, such as queso or nmap.  These tools operate on the principle that every operating system's IP stack has its own idiosyncrasies.  Specifically, each operating system responds differently to a variety of malformed packets.  All one has to do is build a database on how different operating systems respond to different packets.  Then, to determine the operating system of a remote host, send it a variety of malformed packets, determine how it responds, then compare these responses to a database.  Fyodor's nmap is tool of choice when using this methodology.  He has also written a detailed paper on this.

Passive fingerprinting follows the same concept, but is implemented differently.  Passive fingerprinting is based on sniffer traces from the remote system.  Instead of actively querying the remote system, all you need to do is capture packets sent from the remote system.  Based on the sniffer traces of these packets, you can determine the operating system of the remote host.  Just like in active fingerprinting, passive fingerprinting is based on the principle that every operating system's IP stack has its own idiosyncrasies.  By analyzing sniffer traces and identifying these differences,  you may be able determine the operating system of the remote host.
 

The Differences
There are four areas that we will look at to determine the operating system (however there are other signatures that can be used). These four differences are:

By analyzing these factors of a packet, you may be able to determine the remote operating system.  This system is not 100% accurate, and works better for some operating systems then others.  However, it is a great place to start.  Before we go any further, an example would be the easiest thing to do.  Below is the sniffer trace of a system sending a packet.  This system launched a mountd exploit against me, so I want to learn more about it.  I do not want to finger or nmap the box, that could give me away.  Rather, I want to study the information passively.   This signature was captured using snort, my sniffer of choice.

04/20-21:41:48.129662 129.142.224.3:659 -> 172.16.1.107:604
TCP TTL:45 TOS:0x0 ID:56257
***F**A* Seq: 0x9DD90553   Ack: 0xE3C65D7   Win: 0x7D78

Based on our 4 criteria, we identify the following:

We then compare this information to a database of signatures.  Based on the database, it appears this packet was sent from a Linux box, potentially Red Hat 6.0 kernel 2.2.5.  Based on initial testing, I have found the TTL to be one of the better tools to determine source operating system.  From our sniffer trace above, you can see it is set at 45.  This most likely means it went through 19 hops to get to us, meaning the original TTL was set at 64.  This is confirmed after doing a traceroute to the remote host. If you are concerend about the remote host detecting your traceroute, you can set your traceroute time-to-live (default 30 hops), to be one or two hops less then the remote host (-m option). For example, in this case we would do a traceroute to the remote host, but using only 18 hops (traceroute -m 18). This gives you the path information (including their upstream provider) without actually touching the remote host.

I have found the Window Size to be another effective tool, specifically what size is used and how often the size changes.  Here we see it set at 0x7D78, a default Window Size commonly used by Linux.  Linux, FreeBSD, and Solaris also tend to maintain the same Window Size throughout a session. Cisco routers (at least my 2514) and Windows/NT Window Sizes are constantly changing. Also, I have found that Window Size is more accurate if measured after the initial three-way handshake (due to TCP slow start). For more information on Window Size, see Stevens, "TCP/IP Illustrated, Volume 1" Chapter 20.

Most systems use the DF bit set, so this is of limited value.  After further testing, I feel that TOS is also of limited value. This seems to be more session based then operating system. In other words, its not so much the operating system that determines the TOS, but the protocol used. TOS defintely requires some more testing.  So, based on the information above, specifcally TTL and Window size, you can compare the results to the database of signatures and with a degree of confidence determine the OS (in our case, Linux kernel 2.2.x).

There are several other areas that can be tracked, such as initial sequence numbers or initial IP Identification numbers. For example, Cisco routers tend to start IP Identification numbers at 0, instead of randomly assigning them. These and other signatures can be combined with the four listed above to help identify remote operating systems. As a bit of additional information, we can also determine the remote user was root when sending the packets (or running an suid program). The source port is below 1024.

One thing to consider is Passive Fingerprinting can be defeated.  It is relatively simple for a remote host to adjust the TTL, Window Size, DF, or TOS setting on packets.  For example, to change the default TTL value:
Solaris: ndd -set /dev/ip ip_def_ttl 'number'
Linux: echo 'number' > /proc/sys/net/ipv4/ip_default_ttl
NT: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters

However, by combining a variety of different signatures, such as TTL, Window Size, and the IP Identification number, you can make an approximation of the remote system.

Passive fingerprinting can be used for several other purposes. It can be used by the bad guys as 'stealthy' fingerprinting.  For example, to determine the Operating System of a 'potential victim', such as a webserver, one only needs to request a webpage from the server, then analyze the sniffer traces.  This bypasses the need for using an active tool that can be detected by various IDS systems.  Also, Passive fingerprinting may be used to identify remote proxy firewalls. Since proxy firewalls rebuild connection for clients, it may be possible to ID the proxy firewalls based on the signatures we have discussed.

Building the Database
The database was built by testing a variety of systems with the Telnet, FTP, HTTP, and SSH protocol. More testing needs to be conducted using various other protocols, sessions, and systems. Also, another signature that may be valuable are ICMP payloads. If you have any signatures to add to the database, please send them to lance@spitzner.net.

Conclusion
Passive fingerprinting gives you the ability to learn about the enemy, without them knowing it.  Though no single piece of information can positively identify a operating system, by combining several signatures, you can make an approximation of the remote system.

Thanks to the following people for their help and ideas:
Marty Roesch
Edward Skoudis
Dragos Ruiu

Author's bio
Lance Spitzner enjoys learning by blowing up his Unix systems at home. Before this, he was an Officer in the Rapid Deployment Force, where he blew up things of a different nature. You can reach him at lance@spitzner.net .
 
 

Whitepapers / Publications