Fingerprinting Methods Avoided by Nmap
Nmap supports many more OS detection techniques than any other
program, and we are always interested in hearing about new ideas.
Please send them to the Nmap development list (nmap-dev@insecure.org).
However there are some methods that just aren't a good fit. This
section details some of the most interesting ones. While they aren't
supported by Nmap, some are useful in combination with Nmap to verify
findings or learn further details.
Passive fingerprinting uses most of the same techniques as the
active fingerprinting performed by Nmap. The difference is that a
passive system simply sniffs the network, opportunistically
classifying hosts as it observes their traffic. This is more
difficult than active fingerprinting, since you have to accept
whatever communication happens rather than designing your own custom
probes. It is a valuable technique, but doesn't belong in a
fundamentally active tool such as Nmap. Fortunately, Michal Zalewski
has written the excellent p0f passive OS
fingerprinting tool. He also devised a couple of the current Nmap OS
fingerprinting tests. Another option is SinFP by GomoR, which supports both active and passive fingerprinting.
TCP/IP fingerprinting works well for distinguishing different
operating systems, but detecting different versions of the same
operating system can be troublesome. The company must change their
stack in some way we can differentiate. Fortunately, many OS vendors
regularly update their systems to comply with the latest standards.
But what about those who don't? Most of them at least get around to
fixing exploitable stack bugs eventually. And those fixes are easy to
detect remotely. First send the exploit payload, be it a land attack,
teardrop, ping of death, SYN flood, or Winnuke. Send one attack at a
time, then immediately try to contact the system again. If it is
suddenly non-responsive, you have narrowed down the OS to versions
which didn't ship with the fix.
![[Warning]](warning.png) | Warning |
---|
If you use denial of service (DoS) exploits as part of your OS
detection suite, remember to perform those tests last. |
TCP implementations have significant leeway in exactly how long
they wait before retransmitting packets. The proof-of-concept tools
Ring and Cron-OS are available to exploit this. They send a SYN
packet to an open port, then ignore the SYN/ACK they receive rather
than acknowledging it with an ACK (to complete the connection) or a
RST (to kill it). The target host will resend the SYN/ACK several
more times, and these tools track every subsecond of the wait. While
some information can indeed be gleaned from this technique, there are
several reasons that I haven't incorporated the patch into
Nmap:
It usually requires modifying the source host firewall
rules to prevent your system from replying with a RST packet to the
SYN/ACK it receives. That is hard to do in a portable way. And
even if it was easy, many users don't appreciate
applications mucking with their firewall rules.
It can be very slow. The retransmissions can go on for
several minutes. That is a long time to wait for a test that doesn't
give all that much information in the first place.
It can be inaccurate because packet drops and latency
(which you have to expect in real-world environments) can lead to
bogus results.
I have enumerated these reasons here because they also apply to
some other proposed OS detection methods. I would love to add new
tests, but they must be quick and require few packets. Messing with
host firewall is unacceptable. I try to avoid making full TCP
connections for stack fingerprinting, though that is done for OS
detection as part of the version scanning system.
IP fragmentation is a complex system and implementations are
riddled with bugs and inconsistencies. Possible tests could examine
how overlapping fragments are assembled or time the defragmentation
timeouts. These tests are avoided for Nmap because many firewalls and
other inline devices defragment traffic at gateways. Thus Nmap may
end up fingerprinting the firewall rather than the true destination
host. In addition, fragments are difficult to send on some operating
systems. Linux 2.6 kernels have a tendency to queue the fragments you
are trying to send and assemble them itself before
transmission.