ClearNet Security

maximizing nmap scans for accuracy

There have been some recent newsgroup postings about consistency problems with nmap results (especially when scanning over the internet). In my experience, if you want the best chance of obtaining accurate nmap scan results, you need to:

check the latency to your targets (ping some device on the target net block for awhile, what is the average rtt value?)
- use the average to configure the --max_rtt_timeout nmap option (e.g. if your ping time is 300ms, you obviously want to set this option to more than 300ms to prevent nmap for missing an open port if/when a probe takes longer than 300ms. Maybe set it to 500ms or even higher. Speed suffers, but we're chasing accuracy)
if you can, check the available bandwidth limit for you and the target net (e.g. T3:45mbps, T1:1.544mbps, DSL, etc.)
- use this to configure the --min-hostgroup and --max-hostgroup nmap options and the --min-parallelism and --max-parallelism options (i.e. the more bandwidth each side has available, the more hosts and ports you can scan in parallel). This can significantly reduce overall scan time while keeping accuracy as the highest priority. I typically use IPTraf to watch pps (packets per second) to guage my bandwidth usage. If my options are too aggressive (i.e. consuming too much bandwidth), I'll kill the current scan and start over with different tuning values. The objective here is to set --min-hostgroup and min-parallelism to something that both sides can handle without sacrificing accuracy. If bandwidth permits, I like to set min_parallelism to 100 (number of parallel SYN requests or whatever scan type you're doing). I've gone up to 300 for --min-hostgroup (had lots of bandwidth and plenty of server horsepower). You don't want to cause your scan server, the target, or any device the probes traverse to drop packets, so the more information you have about all the components involved the better you'll be able to tune these values.
if you can, verify there are no 'smart' devices impeding scans (e.g. IPS, rate limiting device, etc.)
run multiple nmap scans of the same target, preferably at different times of the day and different days of the week (e.g. nightly backups can saturate certain hosts/links which causes nmap to fail to discover open ports). I like to run multiple services scans (~1600 ports) and do one or two 65k scans depending on circumstances. If time permits, the confidence boost you get knowing you've maximized accuracy by running repeated scans is satisfying. It also shows your assiduity; you can tell your customer you fired off 5 scans at different times to obtain your final list of exposed services. If you missed something after repeated scans (assuming you used safe tuning values), something is likely wrong.
set --host_timeout to something you are comfortable with.
- if you determine a scan may take 20 hours to perform a 65k port scan of the target device, then set this option accordingly. Note: you can use 's', 'm', or 'h' to specify seconds, minutes, or hours.
set --max-scan-delay to something low if nothing is impeding scans
- I typically set this option to 0 because I'm confident in my other tuning values (no delay between probes, just fire them off)

While tuning nmap options can do lots of good things it is still important to verify your scan server can keep up. We've knocked down 8-way Opteron systems w/16GB of RAM, so optimal nmap options may not be realistic for your hardware.

Posted by tate 03/05/2006 at 01h05

OS	32bit	64bit (if different from 32)	Delimiter
AIX	LIBPATH		: (colon)
HP-UX	SHLIB_PATH	LD_LIBRARY_PATH	: (colon)
Solaris	LD_LIBRARY_PATH	LD_LIBRARY_PATH_64	: (colon)
Linux	LD_LIBRARY_PATH		: (colon)
Tru64	LD_LIBRARY_PATH		: (colon)
SCO	LD_LIBRARY_PATH		: (colon)
Unixware	LD_LIBRARY_PATH		: (colon)
Windows	PATH		; (semicolon

Category	Initial Registration Fee (US Dollars)	Assignment Size
X-small/ Micro-allocation	$1,250	/24 - < /20
Small	$2,250	/20 - /19
Medium	$4,500	> /19 - /16
Large	$9,000	> /16 - /14
X-large	$18,000	> /14

Tool	Date of last version	version	OS	Service	Protocol
nmap	Feb, 2006	4.01	yes	yes	yes
xprobe2	Feb, 2005	0.2.2	yes	no	no
p0f	Sep, 2004	2.0.6	yes	no	no
amap	Sep, 2005	5.2	no	yes	yes
nessus	Mar, 2006	3.02	yes	yes	yes
winfingerprint	Mar, 2006	0.6.x	yes	yes	yes
httprint	Dec, 2005	301	no	no	yes
queso	Aug, 1998	980922	yes	no	no
NTP-fingerprint	Feb, 2005	0.1a	yes	no	no
ike-scan	Dec, 2005	1.8	no	yes	yes
thcrut	May, 2003	1.2.5	yes	no	no
smtpmap	Dec, 2001	0.6	no	yes	no
smtpscan	May, 2003	0.5	no	yes	no
snacktime	Jun, 2003	0.5	yes	no	no
synscan	Apr, 2004	0.1	yes	no	no
telnetfp	Jan, 2001	0.1.2	yes	no	no
ldistfp	May, 2001	0.1.4	yes	no	no
telnet	N/A	N/A	yes	yes	yes
siphon	May, 2000	666	yes	no	no
ring		0.0.1
scanssh	Mar, 2005	2.1	no	yes	yes
hackbot	Dec, 2003	2.21	no	yes	yes
hping3	Nov, 2005	3.0.0	yes	no	no
induce-arp.pl	May, 2000	0.27	yes	no	no
vmap	Aug, 2003	0.6	no	yes	yes
disco	Jul, 2003	1.2	yes	no	no
k9			yes	no	no
ettercap	May, 2005	NG-0.7.3		yes
Net::SinFP	Mar, 2006	1.00	yes	no	no
Archaeopteryx	Jul, 2001	1.0	yes	no	no
iQ	Apr, 2002	0.2	yes	no	no
sprint	Mar, 2003	0.4.1	yes	no	no

Friday Fun Crossword Puzzle

Syndicate

Archives