Re: nmap and a new idea

[Dual Mobius <dualmobius () comcast net>]

Fyodor wrote:
> ... I do plan to overhaul the OS
> detection system this year, adding many more techniques.  I have been
> keeping a list for the last year or two of tests that I would like to
> add.  I will also solicit ideas from you guys on the nmap-dev list
> (though new ideas are welcome anytime - please send them to the list
> for discussion).
> ...
> Cheers,
> Fyodor

This may already be on the list of features/tests to add, but since I don't 
recall seeing it on the list...

Nmap's OS detection is great, but as more firewalls, NATing devices, scrubbers, 
etc are added to networks, I've been seeing a higher ratio of incorrect or 
unsuccessful OS detection results when using nmap.  The devices mentioned change 
just enough of the response to really confuse the signature system nmap uses. 
For example, I've seen KNOWN Windows, Linux, and *BSD boxen mis-identified as 
things ranging from printers to ancient *NIX systems that are all but dead.

For these reasons, I've been relying more and more on xprobe2 for OS 
identification http://www.sys-security.com/html/projects/X.html
Xprobe2 uses a simple "fuzzy logic" system where the scores for tests are summed 
and then the results are sorted in descending order.

The paper "XProbe2 - A 'Fuzzy' Approach to Remote Active Operating System 
Fingerprinting" in the above link has an excellent description of the tool's 
method for OS identification.

So when some intermediate device interferes (and would throw nmap off), the 
correct answer is still often at the top in xprobe2 (with a little lower guess 
probability value).

However, in situations where nmap will have an exact match for the OS, xprobe 
will have a long list of similar OS's from the same family that are all tied.

For example, the scanned system is known to be Linux 2.6.3 and did not have a 
firewall in place at the time of this scan:
--------------------
# nmap -O localhost
...
Running: Linux 2.4.X|2.5.X
OS details: Linux 2.5.25 - 2.5.70 or Gentoo 1.2 Linux 2.4.19 rc1-rc7)

--------------------
# xprobe2 localhost
...
[+] Primary guess:
[+] Host 127.0.0.1 Running OS: "Linux Kernel 2.0.30" (Guess probability: 56%)
[+] Other guesses:
[+] Host 127.0.0.1 Running OS: "Linux Kernel 2.0.34" (Guess probability: 56%)
[+] Host 127.0.0.1 Running OS: "Linux Kernel 2.0.36" (Guess probability: 56%)
[+] Host 127.0.0.1 Running OS: "Linux Kernel 2.4.21" (Guess probability: 56%)
[+] Host 127.0.0.1 Running OS: "Linux Kernel 2.4.20" (Guess probability: 56%)
[+] Host 127.0.0.1 Running OS: "Linux Kernel 2.4.19" (Guess probability: 56%)
[+] Host 127.0.0.1 Running OS: "Linux Kernel 2.2.3" (Guess probability: 53%)
[+] Host 127.0.0.1 Running OS: "Linux Kernel 2.2.7" (Guess probability: 53%)
[+] Host 127.0.0.1 Running OS: "Linux Kernel 2.2.6" (Guess probability: 53%)
[+] Host 127.0.0.1 Running OS: "Linux Kernel 2.2.5" (Guess probability: 53%)
--------------------

I don't have any problem using multiple tools, but for a while I've been 
thinking about if there is a good way to team up these methods to gain extra 
information/insight (without generating quite as much network traffic in the 
process).

Something like a sequence of tests where the test results are fed to both a 
signature engine and a "fuzzy logic" engine.  If there is an exact signature 
match, use that (but compare or list some of the fuzzy logic results too as a 
sanity check).  If the signature match fails, then use the fuzzy logic results.

An approach like this may even be useful in seeing past some of the patches to 
Linux and the BSDs that make them appear as another OS when scanned.  Most of 
these patches change the network stack just enough to trick the nmap signatures 
(in fact they are often coded against the nmap signatures).  At least for a 
while, having the fuzzy logic results available *might* see through this -- at 
least until they start coding to that as well.

So what do others on the list think?  Just tossing out an idea here.


---------------------------------------------------------------------
For help using this (nmap-dev) mailing list, send a blank email to 
nmap-dev-help () insecure org . List archive: http://seclists.org