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

[David Fifield <david () bamsoftware com>]

On Tue, Dec 02, 2008 at 09:41:12PM +0000, Brandon Enright 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.
> > >
> > > Write back with possibilities you see for improvement. I'd like any
> > > changes we make to be in response to actual user concerns.
>
> 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
>
> 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
>
> Completed SYN Stealth Scan at 21:25, 25.98s elapsed (131070 total ports)
> Overall sending rates: 7567.13 packets / s, 332953.75 bytes / s.

That is a good thing to think about. I had been thinking about the
problem mostly in terms of the growth of the global and per-host
congestion windows. I hadn't thought about the change in the timeout
variables srtt and rttvar.

What's happening is that the one totally filtered host has never sent a
reply, so we have no idea what its RTT is. Nmap uses the default of one
second, which is pretty slow. But the scan buddy provides a global RTT
estimate, which Nmap will use when a host doesn't have its own estimate
(HostScanStats::probeTimeout in scan_engine.cc). The approximation is
justified in this case as the two hosts are likely to have
near-identical RTTs. So the unanswered probes time out much more quickly
and the scan goes fast.

If you scan the filtered host with --initial-rtt-timeout 50 does the
scan go as fast as with the buddy?

This is a difficult situation, because the symptom of not receiving any
replies could occur on any variety of slow or fast networks and hosts.
What's a reasonable speed at which to scan when we have no information?
Brandon suggests 250 packets/s. Unicornscan does 300 packets/s by
default. Scanrand's default is infinity.

Nmap has a default congestion window of 10 and a default timeout of 1 s,
which should work out to 10 packets/s. That's probably too slow. I'd
love for someone to find references as to what the "right" number should
be. Note that except for --max-rate and --min-rate, Nmap's scheduler
doesn't work with packets per second but with the number of packets
outstanding in the network. If someone can back up a number in packets
per second we can probably make it work though.

David Fifield

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