Re: Comments on OS detection 2nd generation

[Fyodor <fyodor () insecure org>]

On Fri, May 26, 2006 at 07:14:38PM +0200, GomoR wrote:
> I read your paper on OS fingerprinting 2nd generation. To be frank, I do not
> see major changes in probe packets (but it may be because of my lack of deep
> knowledge upon the 1st generation). 

It does look similar, especially at first glance.  We tried to retain
as much compatability with the old system as we could, and only made
changes that we could empirically demonstrate were of value.

> MSS in-between, the initial Window size in the reply will be changed.
> That is the main reason for SinFP to use a heuristic1 algorithm, that is
> to accept minor changes on MSS/Window size, and still not miss the 
> detection. 

Yeah.  Nmap has a heuristic mode via --osscan-guess or --fuzzy (they
do the same thing), but it is somewhat simplistic.  As noted in the
paper, I hope to devise better algorithms for finding the "closest
match" between a target FP and the reference FP.

> 2. SackOK 
>
> That is a difference with the first generation. I guess you found this
> option by looking at SinFP ;) 

Nah, SinFP was released last year, I think.  I talked about adding
SACK in my Slashdot interview 3 years ago:

http://interviews.slashdot.org/article.pl?sid=03/05/30/1148235

Clearly it is you who found this option by reading my old interviews :).

The new system has been in development for a long time because it
involves replacing the huge OS DB I've spent the last 8 years
creating.  So I want to do it right :)

> I also decided to take a look at adding the same functionnality with IP ID.
> And there is also some differences from an OS to another. For example,
> Compaq Tru64 returns the same IP ID as the request when one send a SYN|ACK
> to an open port. In fact, Compaq Tru64 copies TCP seq/ack and IP ID from
> the request, and use it to reply. This is the only system to do this that
> I've seen. 

That is bizarre.  How many systems have you tested?  I might be
willing to add this if it was useful, but I'm reticent because a
number of systems rewrite the IP IDs that you send in raw IP packets.
I think Solaris may have done this, and Windows back when it even
offered raw IP packets.

> So, I think you could add IP ID comparison to the 2nd generation OSFP like
> you did with TCP seq and ack. 

If you or anyone can find data showing this to be useful, I'm
certainly interested.  If it is _only_ a quirk in Compaq Tru64, that
is of limited value since those devices aren't exactly all that
common.  And like I mentioned, there are some risks.  I'm concerned
that some NATs may rewrite the IPID (that would actually be reasonable
given IPID's purpose).

> 4. ICMP/UDP probes 
>
> I do not like these probes just because when a target has an open TCP port,
> we are not totally assured that a firewall in-between is not crafting
> responses for these tests.

True.  But sadly, you aren't certain of that with TCP responses
either.  People spoof RST packets back all of the time.
Scanme.Nmap.Org does it for port 113, for example, and I've seen many
other cases in the wild.

> So, you may end up with a fingerprint generated
> in part from the true target, and in part from a false target, leading to
> a bad detection. 

That is certainly a major concern.  I'm hoping that better heuristics
will at least help.

> 5. Absence of response (Responsiveness test) 
>
> I think this is also a difference with the first generation, and I totally
> agree with this change. 

We actually do have this in the current version.

> In the http://www.insecure.org/nmap/osdetect/osdetect-other-methods.html
> page, I did not see a note on SinFP (passive mode OS detection). Maybe
> you did not tried it, but I thing it is as good as p0f, with more
> signatures, since SinFP passive signatures are the active signatures. 

OK, I didn't realize it did passive OS detection.  I just added SinFP
to that section.

Cheers,
Fyodor


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