Home page logo
/

nmap-dev logo Nmap Development mailing list archives

Re: nmap and a new idea
From: Dual Mobius <dualmobius () comcast net>
Date: Mon, 08 Mar 2004 00:36:44 -0700

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



  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]
AlienVault