Re: OS fingerprint extraction quality when scanning a large number of machines

[Michael Head <mrhead () us ibm com>]

Brandon wrote on 12/17/2008 12:37:18 PM:

> On Wed, 17 Dec 2008 12:23:55 -0500 or thereabouts Michael Head wrote:
> Mike,
>
> Among other things, OS fingerprinting is sensitive to intra-packet
> timings and when Nmap is doing "too much" the measured times can have a
> lot of jitter to them.  This can result in slightly degraded
> fingerprints.  David worked on changing the weights of the fingerprint
> matching to help improve matches in a number of cases.

Right. I would expect some shiftiness in the results if a lot of network
activity is underway.

> The fingerprints you've included above though don't exhibit the small
> jitter of scanning lots of hosts.  The first fingerprint got absolutely
> no response back from the host.  This generally happens on firewalled
> or non-existent hosts.  The second fingerprint is a perfectly valid,
> quality fingerprint.

Right. There are other targets which exhibit similar characteristics, where
a scan of the entire subnet returns a fingerprint with no responses, and an
individuated scan returns a fingerprint with enough probe responses to
determine that the target is >90% likely to be running some version of
Windows.

> You should *not* see such a wide variation in fingerprints, even
> scanning lots of hosts. Can you reproduce this?  Do you get a lot of
> no-fingerprints when you scan lots of hosts that do respond
> individually?

Yes. It's fully repeatable and consistent. Further, I see it on several
networks here.

On one sample network containing 49 live hosts, I get unconclusive results
for around 25 hosts, and it does appear to be the same 25 hosts each time.
When I run the detection sequentially, I get 49 matches (though not all are
100%).

> If you provide the command you are using to scan large host groups
> we /might/ be able to spot the problem.

No problem, pulled out of the output.xml file:
nmap -oX output.xml -O -v -sV -sS --version-all -p 1-65535
10.10.20.0/24

> Brandon

Thanks for the speedy turnaround,

mike

_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://SecLists.Org