Re: Ideas for rate limit detection?

[Brandon Enright <bmenrigh () ucsd edu>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Fri, 09 Jan 2009 00:54:50 +0200
"ithilgore.ryu.L () gmail com" <ithilgore.ryu.l () gmail com> wrote:

...snip...

> In addition, we could take a look into what kind of traffic is usually
> rate-limited (maybe by observing best-practices/patterns on firewall
> policies), so that we could mainly focus on it and thus extract more
> accurate results. For example, if ICMP echo replies are usually
> rate-limited, then Nmap should be more on the lookout for rate-limit
> behaviour rather than network congestion, on this particular kind of
> traffic.

I don't categorically disagree with your above point but I'll add that
at high scan speeds almost everything is rate-limited. For example,
Windows seems to have a 4000-5000 RST-per-second rate limit. I suppose
one could argue that if you're scanning at 3000+ pps who cares that
you /could/ be doing 4000+.  The trouble used to be that Nmap would
increase the scan delay to 5ms and the rate would go from 4000+ to
200.  David has fixed that.

OS X has a 150-250 RST-per-second limit.  There is so much variance
between 4000-5000 and 150-250 that I think it is hard to make a simple
rate-limit/congestion discriminator.  Add to that the wildly varying
firewall configurations out there and the task is near impossible.

But hey, if I come up with any ideas I'll pass them along.

Brandon

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAklmjwcACgkQqaGPzAsl94JlnACePfWtousVixMDNcttswNNrodp
XbAAoKpG4kJIJP7hBf1yfO+MxibSlq6L
=HCVv
-----END PGP SIGNATURE-----

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