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:
- Testing requested of nmap-perf branch David Fifield (Dec 25)
- Re: Testing requested of nmap-perf branch David Fifield (Dec 28)