Re: New Nmap vs SinFP benchmark

[doug () hcsw org]

Hi Arturo, Hans, and nmap-dev!

On Thu, Dec 28, 2006 at 12:19:39AM -0300 or thereabouts, Arturo 'Buanzo' Busleiman wrote:

> Well, when using Nmap against an IP address that proves difficult to OS-detect (like in your NAT box
> example), you should, instead of submitting the fingerprint or whatever, do an nmap Qscan: It's a
> new nmap scan that you can use with -sQ. It will let you discover how many boxes are behind the NAT
> box, and group them. Then, you can use nmap again to only scan the ports that belong to a certain
> group only, and discover each OS separately.

Muchos gracias for the Qscan plug, Arturo. :)

In my opinion, your technique is solid. Qscan *can* be helpful in finding
out when certain ports are forwarded by a NAT system. I have used it
for exactly this purpose myself (especially see example #3 in the QSCAN
documentation file).

Arturo, you are also absolutley correct that you can "focus" an Nmap OS
scan on a certain port in the same way you can with SinFP:
-O chooses an open port and a closed port found through a preceding Nmap
TCP port scan so obviously you can choose the primary port you want OS detection
to probe by using the -p switch. I am confident that by playing around with
the -p switch supplied to Nmap during these scans you could reach exactly the
same conclusions as you do with SinFP in the final example of the posted benchmark.

Hans also notices this:

On Wed, Dec 27, 2006 at 03:12:16PM -1100 or thereabouts, Hans Nilsson wrote:
> He could have tried to use Nmap against the individual ports in the last
> test, like he did with SinFP.

But of course this is all beside the point and I'd like to thank the
author of the benchmark for a relativley objective comparison between
the 2 systems. It seems as though Nmap could do a better job documenting
the flexibility of the OS detection system and highlighting the effects of
NAT forwarding on OS detection.

About Qscan availability: yes, until right now the links that Jason found
(thanks, btw) were the official Qscan doc/patch links. I've just updated
the patch to Nmap 4.20 and posted it on my Nmap website:

http://hcsw.org/nmap/

Remember please that Qscan is an experimental feature and probably has
not been adequatley tested (nor all of its results adequatley interpreted)
enough to warrant inclusion in mainstream Nmap. In addition, the current
patch lacks a lot of features we all expect in mainstream Nmap code.
Lack of manpage/docbook documentation and -oX XML output stand as the most
glaring deficiencies.

Perhaps eventually I will maintain a branch in the new Nmap SVN repository
with Qscan and select other experimental patches.


On Thu, Dec 28, 2006 at 01:14:16PM -1100 or thereabouts, Hans Nilsson wrote:
> That looks quite interesting. However I just tried it against a box I
> know have a firewall running on one port and it didn't detect it. It
> should also look at the IPID and perhaps the window size. The IPID is
> often a dead giveaway.

The Qscan itself only measures one network attribute and I suppose it
is somewhat misleading of me to describe it as "firewall discovery" since it
detects a network attribute whose presence or lack thereof may or may not be
an indication of a firewall (sorry). In my humble defense, I believe the
ambiguity of the term "firewall" is also partially at fault here.

Hans, I'm not sure if the firewall you're testing forwards select packets
(and not others) to a separate machine (introducing detectable packet delay
discrepancies in the process). This is the only type of "firewall discovery"
Qscan was designed to do.

Even so, Qscan is most effective on a LAN or small, stable network.
The general internet has so many variables and unknowns that interpreting
the Qscan results is problematic - though I have several future ideas
on how to improve Qscan performance over the general internet. (And, indeed,
I also have ideas on many similar scan types. Consider sending 2 packets
in rapid succession and measuring how often the responses come back
"out of order" and their relative delay. I think you should be able to
infer the presence of packet filters from this as well. But I digress.)

Qscan's specialisation can be seen as a strength (interpretation of results
is signifigantly easier) or a weakness (it ignores an heap of potentially
useful data).

All of that being said, I remind you that Qscan is an experimental feature
and certainly not ready for production use. Qscan

**probably does not warrant discussion outside the nmap-dev list**.

I wasn't even certain as to post it here or not. An influential factor was
the rate at which new Nmap scan types have been appearing recently.
Intellectually reserving -sQ seems somewhat prudent. :)

Of course I appreciate all Qscan comments/bugfixes/etc!

Best wishes,

Doug Hoyte


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