Re: nmap-3.7x MUCH slower than nmap-3.55 against firewalled hosts

[Martin Mačok <martin.macok () underground cz>]

On Thu, Dec 16, 2004 at 03:03:10AM -0800, Fyodor wrote:

> > Example (53 seconds versus 1214 seconds):
>
> This could be considered a feature, though I understand the
> frustration.  The host apparently was limiting ICMP unreachables to
> one per second. 

Which is (a) common behaviour and even (b) encouraged in RFC 1812.

> Nmap detected this and slowed down to that rate, so your 1,220 port
> scan took 1,214 seconds.  The older version just gave up on many
> ports, though admittedly the results don't differ because
> no-response and ICMP unreachable mean the same thing (filtered) for
> a SYN scan.

Which suggests that clever implementation shouldn't be waiting for an
ICMP response for *every* port because this way scanning all tcp ports
would always take at least 18 hours (!). Nmap-3.55 does the same job
in 50 minutes (and way faster when tweaking performance).

> Also remember that the new Nmap can scan many hostsl like this at
> the same time.  You could try something like --min_hostgroup 100, or
> even 256 to do the whole Class C at once.

Sure, this helps, but I consider it being more workaround than a real
solution.

And I'm still interested in single host scanning time too.

> Also, adding a small --max_scan_delay should improve things
> dramatically.

Theoretically yes, practically not. It just results in more (faster)
retrasmissions (10-11 with max-rtt-timeout=100) against every single
port during the second until it gets ICMP unreacheble. Still 1 port ==
1 second.

> Doesn't it?  Also, -T4 should be added, and I would recommend
> a max_rtt_timeout that matches the latency to your target hosts.

This helps only when max-rtt-timeout is much smaller than 100ms which
is not common in many scenarios.

With "-F --max_scan_delay 0 --max_rtt_timeout 10" I get the result in
244s with nmap-3.78. With nmap-3.55, I get the same results in 3s (!)
"-F --max_rtt_timeout 10". Adding -T4 doesn't make any difference here
(actually, it does, but only for 3.55 when it squeezes the total time
from 3s to 1,5s :-).

> If you have time to scan such a class C again, how does Nmap 3.78 do
> with "-T4 --min_hostgroup 256 --max_scan_delay 0 --max_rtt_timeout
> XXX" (where XXX is about double the average ping time against hosts
> on the target network).  How does that compare to 3.55?

Nmap-3.78 wins here but generates much more traffic. When scanning
less than 25 hosts paralelly, nmap-3.55 wins.

> You're right that adding more explicit controls over the maximum
> number of retransmissions may be worthwhile.

Yes. Sending more than 10 probes to every port is too much according
to my taste, something around 3 (by default) would suit it better.

Detecting rate-limit and not demanding ICMP unreachable on every
single port would be much nicer IMHO. Nmap-3.55 seems to behave much
more sane to me. (and, contrary to 3.7x, it has working fragmented
scanning too)

Martin Mačok
IT Security Consultant

---------------------------------------------------------------------
For help using this (nmap-dev) mailing list, send a blank email to 
nmap-dev-help () insecure org . List archive: http://seclists.org