Nmap Development mailing list archives

Testing requested of nmap-perf branch


From: David Fifield <david () bamsoftware com>
Date: Thu, 25 Dec 2008 02:40:45 -0700

Hi all,

The nmap-perf branch contains a new algorithm for detecting and
responding to remote rate limiting that I'd like some folks to test. Get
it with

        svn co --username guest --password "" svn://svn.insecure.org/nmap-exp/david/nmap-perf

You'll recall that Nmap's rate limit detection turns on a scan delay
that starts at 5 ms (50 ms for UDP) and doubles until it reaches
1000 ms. That imposed a severe penalty whenever scan delay kicked in
when it shouldn't have.

The new algorithm measures how fast replies are being received and uses
that to set the maximum rate. (It's handled internally as a maximum rate
rather than a fixed delay between probes.) When we get a lot of drops or
see a new tryno, we reduce the maximum scanning rate to the current
receive rate. We try to maintain about 5% headroom; the maximum rate can
slowly increase as long as few drops are detected.

The only changes made so far have been to rate limit detection and scan
delay. You won't (shouldn't) experience any difference in scanning hosts
that are not rate limited. Ideas of scans to try are UDP against Linux
(1 ICMP reply per second) or TCP against FreeBSD or Mac OS X (OS X
supposedly limits to 250 RSTs per second, but in practice it is more
like 130 for reasons I don't understand). With nmap-perf I have been
able to do a fast UDP scan of 95 closed and 5 open ports in under 100
seconds, which is close to the lower limit I found experimentally at
http://www.bamsoftware.com/wiki/Nmap/PerformanceNotes#rate-scatter.

I'm interested in reports of speed and especially accuracy. The new code
should not be any slower than the old in any case, and may be much
faster in some cases. Of course any reduction in accuracy will point to
a flaw in the algorithm that I need to fix. In fact I just found one,
which I'll deal with later: running a 1000-port UDP scan against Mac OS X
sometimes goes too fast and misses drops, leading to too many
open|filtered ports.

Lots of graphs showing the evolution of the nmap-perf branch are at
http://www.bamsoftware.com/wiki/Nmap/PerformanceNotes.

David Fifield

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


Current thread: