Nmap Development mailing list archives
Re: Desired improvements in Nmap performance? [SCAN BUDDIES]
From: Brandon Enright <bmenrigh () ucsd edu>
Date: Tue, 2 Dec 2008 21:41:12 +0000
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tue, 2 Dec 2008 21:32:26 +0000 Brandon Enright <bmenrigh () ucsd edu> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sun, 30 Nov 2008 18:24:59 -0700 David Fifield <david () bamsoftware com> wrote:I'm starting a project to improve Nmap's performance and the predictability of the length of its scans. This may involve tuning performance parameters, adjusting the congestion control mechanism, or other things not thought of yet. What complaints do you have about Nmap's performance? One thing I have heard is that for very large scans Nmap may be too slow, or the time taken may be too unpredictable. One possible improvement is I've identified is that sometimes scan delay kicks in when I don't think it should. If a scan has just started and I see the scan delay go from 0 to 5 ms I'm likely to kill the scan and start it over. Write back with possibilities you see for improvement. I'd like any changes we make to be in response to actual user concerns. David FifieldI'll probably respond to this one several times as I can come up with decent examples of things that should be looked at. Brandon
Okay, using your nmap-perf branch, here is a technique that I sometimes have to use I call "scan buddies" to speed up the scanning of a poorly responding host. If I scan a heavily filtered (or non-existent) host the scan rate is unreasonably slow. Notice that this scan averages about 7.8 packets per second even when -T5 is used: $ time sudo ./nmap --datadir ./ -T5 -PN -n -v -d -p- 132.239.7.132 Starting Nmap 4.76 ( http://nmap.org ) at 2008-12-02 21:24 GMT Initiating SYN Stealth Scan at 21:24 Scanning 132.239.7.132 [65535 ports] Packet capture filter (device eth0): dst host 132.239.1.114 and (icmp or ((tcp or udp) and (src host 132.239.7.132))) Stats: 0:00:13 elapsed; 0 hosts completed (1 up), 1 undergoing SYN Stealth Scan SYN Stealth Scan Timing: About 0.07% done Current sending rates: 7.72 packets / s, 323.01 bytes / s. Stats: 0:00:15 elapsed; 0 hosts completed (1 up), 1 undergoing SYN Stealth Scan SYN Stealth Scan Timing: About 0.09% done Current sending rates: 7.80 packets / s, 326.06 bytes / s. ...will take a /very/ long time, scan killed... Now, if I mix a very quickly responding host (a scan buddy) in with the slow one, the overall scan goes much faster: $ time sudo ./nmap --datadir ./ -T5 -PN -n -v -d -p- 132.239.7.132,131 Starting Nmap 4.76 ( http://nmap.org ) at 2008-12-02 21:25 GMT Initiating SYN Stealth Scan at 21:25 Scanning 2 hosts [65535 ports/host] Packet capture filter (device eth0): dst host 132.239.1.114 and (icmp or ((tcp or udp) and (src host 132.239.7.132 or src host 132.239.7.131))) Discovered open port 22/tcp on 132.239.7.131 Discovered open port 80/tcp on 132.239.7.131 Increased max_successful_tryno for 132.239.7.131 to 1 (packet drop) Completed SYN Stealth Scan against 132.239.7.131 in 9.94s (1 host left) Stats: 0:00:13 elapsed; 0 hosts completed (2 up), 2 undergoing SYN Stealth Scan SYN Stealth Scan Timing: About 72.79% done; ETC: 21:25 (0:00:05 remaining) Current sending rates: 7834.54 packets / s, 344586.06 bytes / s. Stats: 0:00:14 elapsed; 0 hosts completed (2 up), 2 undergoing SYN Stealth Scan SYN Stealth Scan Timing: About 75.26% done; ETC: 21:25 (0:00:04 remaining) Current sending rates: 7429.12 packets / s, 326763.24 bytes / s. Stats: 0:00:15 elapsed; 0 hosts completed (2 up), 2 undergoing SYN Stealth Scan SYN Stealth Scan Timing: About 78.14% done; ETC: 21:25 (0:00:04 remaining) Current sending rates: 7051.69 packets / s, 310157.17 bytes / s. Stats: 0:00:17 elapsed; 0 hosts completed (2 up), 2 undergoing SYN Stealth Scan SYN Stealth Scan Timing: About 80.92% done; ETC: 21:25 (0:00:04 remaining) Current sending rates: 6753.13 packets / s, 297027.17 bytes / s. Stats: 0:00:20 elapsed; 0 hosts completed (2 up), 2 undergoing SYN Stealth Scan SYN Stealth Scan Timing: About 88.31% done; ETC: 21:25 (0:00:02 remaining) Current sending rates: 6275.81 packets / s, 276044.31 bytes / s. Stats: 0:00:23 elapsed; 0 hosts completed (2 up), 2 undergoing SYN Stealth Scan SYN Stealth Scan Timing: About 93.93% done; ETC: 21:25 (0:00:01 remaining) Current sending rates: 6080.04 packets / s, 265400.16 bytes / s. Completed SYN Stealth Scan at 21:25, 25.98s elapsed (131070 total ports) Overall sending rates: 7567.13 packets / s, 332953.75 bytes / s. Host 132.239.7.132 appears to be up ... good. All 65535 scanned ports on 132.239.7.132 are filtered because of 65535 no-responses Final times for host: srtt: -1 rttvar: -1 to: 250000 Host 132.239.7.131 appears to be up ... good. Scanned at 2008-12-02 21:25:14 GMT for 10s Interesting ports on 132.239.7.131: Not shown: 65533 closed ports Reason: 65533 resets PORT STATE SERVICE REASON 22/tcp open ssh syn-ack 80/tcp open http syn-ack Final times for host: srtt: 277 rttvar: 48 to: 50000 Read from ./: nmap-services. Nmap done: 2 IP addresses (2 hosts up) scanned in 26.12 seconds Raw packets sent: 196609 (8.651MB) | Rcvd: 65535 (2.621MB) real 0m26.131s user 0m0.324s sys 0m0.284s Now I know I've complained before that sometimes all it takes is a really filtered host to slow a whole scan down but sometimes the exact opposite is true -- as illustrated above. I'm not sure what the "elegant" solution is but I think it would be reasonable to dramatically increase the scan rate when the srtt and rttvar times are still at -1. Something like 250 pps seems like it would be a good choice. Brandon -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkk1q3gACgkQqaGPzAsl94LQ0wCeJcS4T2M9PkPBFIFTvGgVGos1 +4gAniPTLHZsb6hyrQZ7OJiuNYXVl3Fc =solV -----END PGP SIGNATURE----- _______________________________________________ Sent through the nmap-dev mailing list http://cgi.insecure.org/mailman/listinfo/nmap-dev Archived at http://SecLists.Org
Current thread:
- Desired improvements in Nmap performance? David Fifield (Nov 30)
- Re: Desired improvements in Nmap performance? sara fink (Dec 01)
- Re: Desired improvements in Nmap performance? DePriest, Jason R. (Dec 01)
- Re: Desired improvements in Nmap performance? Brandon Enright (Dec 02)
- Re: Desired improvements in Nmap performance? [SCAN BUDDIES] Brandon Enright (Dec 02)
- Re: Desired improvements in Nmap performance? [SCAN BUDDIES] David Fifield (Dec 02)
- Re: [CAPS] Re: Desired improvements in Nmap performance? [SCAN BUDDIES] Brandon Enright (Dec 02)
- Re: [CAPS] Re: Desired improvements in Nmap performance? [SCAN BUDDIES] David Fifield (Dec 02)
- Re: Desired improvements in Nmap performance? [SCAN BUDDIES] Brandon Enright (Dec 02)
- Re: Desired improvements in Nmap performance? [SCAN BUDDIES] Brandon Enright (Dec 02)
- Re: Desired improvements in Nmap performance? [FASTER IS SLOWER] David Fifield (Dec 02)
- <Possible follow-ups>
- Re: Desired improvements in Nmap performance? Rob Nicholls (Dec 01)
- Re: Desired improvements in Nmap performance? sara fink (Dec 01)