Re: New Nmap vs SinFP benchmark

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

Ok, thanks for your reply. I mean it kind of turned out that it actually
worked. And I'm sure it'll just keep improving from here. It's
definitely something I'd like to see incorporated into the standard
realease of Nmap.


On Thu, 28 Dec 2006 23:18:04 -0800, doug () hcsw org said:
> Hi Hans!
>
> Thanks for giving Qscan a try. I've noticed this behaviour too and it
> is an example of the major difference between Qscan and other Nmap
> scans (and, come to think of it, most network security tools): Qscan
> is a statistical test rather than a deterministic test.
>
> In your example I think one of the round-trips that Nmap measured was
> probably unusually above the mean which causes an extremely high
> standard deviation:
>
> On Thu, Dec 28, 2006 at 06:22:33PM -1100 or thereabouts, Hans Nilsson
> wrote:
> >          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
>
> This could be for any number of possible reasons, ie:
>
> - Unexpected increase in network activity (increase in network queues).
>
> - An operating system was in an important context switch and the
>   packet was delayed inordinatley long. The OS could be either yours,
>   your target's or any routers/NAT machines in between.
>
> - The seemingly random nature of the universe. :)
>
> It makes sense, at least to me, that packet round-trip times aren't
> perfectly normal: There are stronger lower boundaries than a normal
> distribution would imply (and the mean is likely quite close to this
> boundary) and we sometimes find round-trip values that would be
> fantastically unlikley if round-trip times were really normally
> distributed.
>
> As I mention in the "Future Work" section of the QSCAN file, I think
> a median filter is the logical next step:
>
> o The algorithm could possibly be improved. Some sort of median
>   filter would be helpful in throwing out packets that are
>   obviously outliers and not representative of the packet delays.
>
> Regarding your suggestions on the detection of packet forwarding devices
> by looking at window sizes and other TCP/IP attributes - These are all
> great ideas but I believe their scope is outside of Qscan.
>
> Best,
>
> Doug
-- 
  Hans Nilsson
  hasse_gg () ftml net

-- 
http://www.fastmail.fm - Faster than the air-speed velocity of an
                          unladen european swallow


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