Re: New Nmap vs SinFP benchmark

["Hans Nilsson" <hasse_gg () ftml net>]

I just did a quick test:

$ sudo hping2 -S -p 113 -c 5 www.gavle.se
HPING www.gavle.se (eth0 83.137.9.33): S set, 40 headers + 0 data bytes
len=46 ip=83.137.9.33 ttl=116 id=4975 sport=113 flags=RA seq=0 win=0
rtt=35.0 ms
len=46 ip=83.137.9.33 ttl=116 id=4981 sport=113 flags=RA seq=1 win=0
rtt=35.0 ms
len=46 ip=83.137.9.33 ttl=116 id=4988 sport=113 flags=RA seq=2 win=0
rtt=35.1 ms
len=46 ip=83.137.9.33 ttl=116 id=4993 sport=113 flags=RA seq=3 win=0
rtt=35.0 ms
len=46 ip=83.137.9.33 ttl=116 id=5000 sport=113 flags=RA seq=4 win=0
rtt=34.9 ms

$ sudo hping2 -S -p 80 -c 5 www.gavle.se
HPING www.gavle.se (eth0 83.137.9.33): S set, 40 headers + 0 data bytes
len=46 ip=83.137.9.33 ttl=115 id=8492 sport=80 flags=SA seq=0 win=64240
rtt=36.0 ms
len=46 ip=83.137.9.33 ttl=115 id=8586 sport=80 flags=SA seq=1 win=64240
rtt=35.7 ms
len=46 ip=83.137.9.33 ttl=115 id=8651 sport=80 flags=SA seq=2 win=64240
rtt=35.9 ms
len=46 ip=83.137.9.33 ttl=115 id=8793 sport=80 flags=SA seq=3 win=64240
rtt=36.0 ms
len=46 ip=83.137.9.33 ttl=115 id=8819 sport=80 flags=SA seq=4 win=64240
rtt=35.9 ms

$ sudo ./nmap -sQ -n -P0 www.gavle.se -p 80,113
Starting Nmap 4.20ALPHA4 ( http://www.insecure.org/nmap/ ) at 2006-12-29
06:04 CET
Qscan parameters: round trips: 10, avg delay = 200ms, confidence = 0.95
         Target:Port  Fam  uRTT  +/- Stddev  Loss%
    83.137.9.33:80    A    44.8  +/-  28.5     0
    83.137.9.33:113   A    35.0  +/-   0.1     0
All 0 scanned ports on 83.137.9.33 are
Nmap finished: 1 IP address (1 host up) scanned in 8.605 seconds

(If the formatting's screwed up look here: http://pastebin.com/846941)

And as you can see, the window size, IPID and TTL gives away the fact
that some sort of filtering/forwarding is going on.
And the rtt also differs about 1 s. But Qscan still think they're in the
same group. I just thought it would be cool if Qscan could maybe look at
the IPID and window size also. That could help in determining the
grouping further. But that method might not be what you had in mind for
Qscan when you created it. Feel free to tell me if I'm missing
something.

EDIT: Just before posting I tried it some more, and now it actually
tells me that they belong to different groups. Even though the first
time I tried it and when I tried it while writing this post it didn't.
So this might not even be an issue at all. :)

On Thu, 28 Dec 2006 19:59:15 -0800, doug () hcsw org said:
> 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.
>
> Best wishes,
>
> Doug Hoyte
-- 
  Hans Nilsson
  hasse_gg () ftml net

-- 
http://www.fastmail.fm - A no graphics, no pop-ups email service


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