Re: Desired improvements in Nmap performance? [SCAN BUDDIES]

[Brandon Enright <bmenrigh () ucsd edu>]

-----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 Fifield
>
> I'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