nmap performance -> timeout issue

["Maarten Hartsuijker" <subscriptionsNOSPAM.please () hartsuijker com>]

I'm currently installing an audit environment that should periodically
audit several subnets. I've been trying to tune nmap for the initial sweep
of the subnets in order to bring the time-to-completion down.

The first subnet I'm testing is /23, pix protected->icmp filtered and
after finishing only half the scan after two days, I aborted and started
tuning.

The audit machine is located in the same DMZ the pix is terminated in. I'm
using dell hardware, with a default GB interface, set to 100/full/negOFF.
Nmap is running of FC.3/2.6.10/DualXeon3.2/2GB with wmem en rmem boosted
to 8M, backlog->4096 and optmem_max->40000

The audit script from which nmap is running, bases the rtt timeouts of a
tcptraceroute to the main webserver in the subnet I'm testing. The RTT
from my scanbox to this particular network is < 10ms.

I am scanning the subnet using:
-sS -sV
-p 1-65535
-n
-P0
--max_scan_delay 5
--max_rtt_timeout 20 --initial_rtt_timeout 10 --min_rtt_timeout 10
(based on RTT determined by traceroute. even though my connection is
faster, I adopted these as minimal values)
--min_parallelism 60
--min_hostgroup 52

My problem is visualized in the verbosed output below:
Discovered open port 443/tcp on IP.1
Discovered open port 443/tcp on IP.2
SYN Stealth Scan Timing: About 1.17% done; ETC: 10:26 (0:42:07 remaining)
Increasing send delay for IP.1 from 0 to 5 due to ..
Increasing send delay for IP.2 from 0 to 5 due to ..
Increasing send delay for IP.3 from 0 to 5 due to
SYN Stealth Scan Timing: About 26.17% done; ETC: 12:26 (2:00:15 remaining)
SYN Stealth Scan Timing: About 46.17% done; ETC: 15:36 (3:09:55 remaining)

Nmap starts off performing quite well and estimates the completion of
scanning 64 IP-addresses at 42 minutes. However, as soon as it finds an
open port on one of my hosts, it starts increasing the scan delay. I
thought I mitigated this by using the max_scan_delay option, but I'm not
quite sure if this is the case...

Since my max_rtt is 20 and my max_scan_delay is 5, nmap should be able to
probe 40 times per second. Including the parallelisation, there should be
2400 probes/second

I'm auditting 64 hosts * 65536 ports * 2 (retransmits) = 8388608 ports
This should take nmap a maximum of 3500 seconds = 1 hour

I think this calculation matches the initial guess of nmap quite well, but
starts drifting away as soon as nmap finds open ports on hosts. I noticed
that hosts with open ports take between 9 and 10 hours to complete....
Some might suggest to add a host timeout, but I don't think this is an
option, because I don't want to have nmap abort scans before it approached
all ports.

My guess is that since nmap does not receive resets from a pix, it starts
managing dropped packages differently as soon as an ack has been received
from an open port.... Hosts that are completely blocked by the pix (and of
which all packages are dropped) complete much, much faster than hosts that
have 1 open port.

Did I make an error in my calculations? Does anyone know how the behaviour
can be explained? Or why an nmap scan takes longer than #ports * max_rtt *
max_scan_delay * 2? Or maybe even know a way to tackle this problem???

A side question: does anyone know about benchmarks on scan accuracy in
relation to the number of packets transmitted per second.

I appreciate all feedback!
Maarten Hartsuijker


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