Nmap Development mailing list archives
nmap performance -> timeout issue
From: "Maarten Hartsuijker" <subscriptions () hartsuijker com>
Date: Wed, 13 Apr 2005 20:29:53 +0200
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
Current thread:
- nmap performance -> timeout issue Maarten Hartsuijker (Apr 13)
- Re: nmap performance -> timeout issue MadHat (Apr 13)
- Re: nmap performance -> timeout issue Maarten Hartsuijker (Apr 20)
- Re: nmap performance -> timeout issue MadHat (Apr 13)
- Re: nmap performance -> timeout issue Maarten Hartsuijker (Apr 20)
- Re: nmap performance -> timeout issue Martin Mačok (Apr 14)
- <Possible follow-ups>
- nmap performance -> timeout issue Maarten Hartsuijker (Apr 20)
- Re: nmap performance -> timeout issue MadHat (Apr 13)