Re: studies/papers/etc. on getting best results w. nmap?

["^..^" <zenfish () gmail com>]

Thanks for the responses, and I promise not to beat the dead horse….

> I don't think that you can rank the various states as more or less
> closed in general. A TCP port that is "filtered" may be so because there
> is no server behind, and it is additionally protected by a firewall--you
> might consider this "more closed" than "closed". But it also may be that
> there is a server listening on that port, with only a firewall to
> prevent connections--this is "less closed" than "closed" because the
> service will become open if there is ever a firewall SNAFU.
>
> Likewise, a UDP port being "open|filtered" may be because there is no
> application listening--"more closed" than "closed"--or because there is
> an application actively listening but Nmap doesn't yet have a UDP
> payload that provokes a response from it--"less closed" than "closed".
> is an app


Great points, and I didn't even think of the failover model.

My thought in a nutshell was that it could be that you might have knowledge of the existing network that might aid in 
analysis.  For instance you could look for suspected firewall(s)/network dev(s) in the intervening network and find 
whether they're stateful or stateless, along with vendor identities and expected behavior.

I assumed that digital fingerprints of even obscure or tiny differences in implementations and types of blocking rules 
along with various vendors would show up, however minutely, that might aid in the end analysis: for instance a priori 
of OS detection I would never have thought that minute differences in IP implementations would reveal so much about a 
computer, but in hindsight of course it's obvious ;)   And that nmap efforts would catalogue 3.5k and counting?  Of 
course you couldn't be perfect, but OS detection isn't either.

Perhaps it's just when analyzing data and two things aren't the same that it galls me to think I have to ignore the 
difference ;)

Anyway, thanks again -

dan

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