Re: Comments on OS detection 2nd generation

[GomoR <nmap-hackers () gomor org>]

On Sat, May 27, 2006 at 01:41:12AM -0700, Fyodor wrote:
[..]
> 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.

Ok. 

[..]
> 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.
[..] 

Ok. 

[..]
> 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 :).

Haha ;) I did not know that. My approach was simplisitic, I took a
packet generated by a normal Linux stack to use as a probe, and SackOK
was included in this packet. So, it is purely by chance that I used
this option ;) 

[..]
> 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.

I tested against 95 systems. 

If the IP ID were to be rewritten, SinFP's heuristic1 algorithm would
catch this change, and still identify the target stack. So, for me, this
is not really a problem, and can be added even if it does not add major
value. I can imagine changes in the IP ID generating behaviour from
one system version to another, who knows. The information is there, no
need to change the probes, so, why not using it. 

[..]
> 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).

Yes, I only seen against Tru64 5.1A. Maybe this behaviour has
changed from previous Tru64 versions, I can't say. 

[..]
> True.  But sadly, you aren't certain of that with TCP responses
> either.  People spoof RST packets back all of the time.

Yes, I did not mention that, and it is for that reason that SinFP
only targets one open TCP port, by using one closed port, we can't be
sure that the response comes from the target system. 

> Scanme.Nmap.Org does it for port 113, for example, and I've seen many
> other cases in the wild.

And it does not astonish me ;) 

> > 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.

Ok. 

> > 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.

Ok, I did not know that. 

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

Yeah, thank you ;) 

-- 
 ^  ___  ___             http://www.GomoR.org/          <-+
 | / __ |__/          Systems & Security Engineer         |
 | \__/ |  \     ---[ zsh$ alias psed='perl -pe ' ]---    |
 +-->  Net::Packet <=> http://search.cpan.org/~gomor/  <--+


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