Posted by Tate Hansen
Wed, 03 May 2006 07:05:00 GMT
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.
Tags accuracy, ClearNet Security, nmap, performance, Tate Hansen, tuning | no comments
Posted by Tate Hansen
Wed, 01 Feb 2006 06:41:00 GMT
Which vulnerability tests did Nessus run? How long did it take? Which tests take the most time?
Here is a quick perl piece I wrote awhile back to answer these questions. My main goal at the time was to find which vulnerability tests were consuming the most time. The script parsers the nessusd.messages file and generates an output which looks like the following (I added color to this sample to emphasize the different components):
[suse] > ./parseNessusdMessages.pl 10
===========================================================
xx.xxx.78.65: completed checks = 2262: Time to complete host scan = 369.65 (0:6:9)
68.785 (%18.608) invision_gallery_st_sql_injection.nasl
55.707 (%15.070) lighttpd_cgi.nasl
49.862 (%13.489) DDI_IIS_Compromised.nasl
47.847 (%12.944) horde_detect.nasl
31.121 (%8.419) rpc_portmap.nasl
30.254 (%8.184) amanda_detect.nasl
18.491 (%5.002) h323_detection.nasl
17.578 (%4.755) dont_print_on_printers.nasl
17.525 (%4.741) basilix_inc_files.nasl
16.554 (%4.478) ventrilo_detect.nasl
16.474 (%4.457) krb_pingpong.nasl
not showing remaining list... (only showing 10)
===========================================================
===========================================================
xx.xxx.217.250: completed checks = 2262: Time to complete host scan = 677.22 (0:11:17)
224.901 (%33.209) office_files.nasl
62.777 (%9.270) sql_injection.nasl
61.661 (%9.105) mozilla_default_perms.nasl
60.220 (%8.892) NetSphere.nasl
55.007 (%8.122) shells.nasl
47.335 (%6.990) mozilla_176.nasl
46.044 (%6.799) bnc_auth_bypass.nasl
45.214 (%6.676) qpopper2.nasl
45.110 (%6.661) squid_dos.nasl
44.425 (%6.560) dont_print_on_printers.nasl
44.394 (%6.555) CA_License_Service_Stack_Overflow.nasl
not showing remaining list... (only showing 10)
===========================================================
===========================================================
xx.xxx.78.6: completed checks = 2350: Time to complete host scan = 647.36 (0:10:47)
163.406 (%25.242) sendmail_ident.nasl
163.162 (%25.204) traceroute.nasl
120.236 (%18.573) nessus_detect.nasl
106.080 (%16.387) ftp_backdoor.nasl
101.724 (%15.714) mozilla_nntp_heap_overflow.nasl
96.309 (%14.877) quote.nasl
74.986 (%11.583) eserv_dir_traversal.nasl
60.184 (%9.297) cfengine_authdiag.nasl
53.321 (%8.237) crlinux_file_reading.nasl
45.546 (%7.036) bnc_auth_bypass.nasl
45.315 (%7.000) ircd_ignition_ircop_vuln2.nasl
not showing remaining list... (only showing 10)
The script parses all the tests found in the nessusd.messages file which were executed (not skipped) and displays the results organized by target IP address. It also sorts and displays in descending order the vulnerability tests which consumed the most time. The parseNessusdMessages.pl takes a single argument which specifies how many vulnerability checks to display per IP address (i.e. in the above example, 10). Few notes:
- This works best if you start with a empty nessusd.messages file. Run a nessus scan and after it is complete then you can run the script to generate the output like above.
- The nessusd.messages file is not always located in the same spot. You may have to modify the path in the script (likely locations include /opt/nessus/var/nessus/logs/nessusd.messages or /usr/local/var/nessus/logs/nessusd.messages). By default, you need root permission to view the nessusd.messages file. I often just copy the nessusd.messages (using sudo) file to my homedir and change the path in the script to check "~/nessusd.messages".
- The 1st column is the number of seconds the vulnerability test took followed by the percentage of overall time (i.e. how long it took to scan the target IP).
So, if you are in the business of tuning your Nessus scanner, then this script may provide you some value.
Tags ClearNet Security, nasl, nessus, scripts, Tate Hansen, tuning | no comments
Posted by Tate Hansen
Wed, 28 Dec 2005 05:51:00 GMT
We recently performed a relatively large TCP port scan for a client; a full 65k SYN scan of ~70,000 IP addresses. Nmap is a great port scanner and was our first choice. We had two new and beautiful Sun quad v40z dual core opteron servers (16GB of RAM each) dedicated to the task. We were under a restrictive change control window and time was the limiting factor. We broke the scans down like this:
- Executed 8 unique nmap instances on each system (one for each ‘virtual’ processor)
- Divided the scans on /24 blocks (the optimal breakdown would’ve been on a 100 boundary, but we ran with this)
- Set min_hostgroup to 100 (minimum number of devices to scan in parallel)
- Set min_parallelism to 100 (minimum number or ports to scan in parallel)
- Set max_rtt_timeout to 1250 (wait a maximum of 1.25 seconds to receive a reply from a port query)
- Other command line options used (-vv: verbose, -sS: SYN Scan, -P0: no ICMP, -p: port range)
All together, a single nmap statement looked like the following:
/usr/local/bin/nmap -vv -sS -P0 -p 1-65535 -n --min_hostgroup 100
--max_rtt_timeout 1250 --min_parallelism 100 <a_/24_block>
We paid close attention to the number of outbound pps (packets per second) using iptraf for a couple reasons: To watch our bandwidth utilizations to avoid ISP overage charges and to gain a rough baseline so we could detect a problem.
If I remember right, the outbound pps initially was between 2k and 4k per server. Things were rocking and it looked like we would sail through the port scans. Alas, when doing a quick check after ~30 hours of scanning, we noticed the pps had slowed to ~550 per server. We deduced nmap had some memory management issues when used the way we crafted. Each nmap instance was consuming ~1.2GBytes of RAM, appeared to be increasing, and the CPU idle time for all processors was a continuous 0. This caught us off guard somewhat because we had successfully performed an nmap TCP services scan (~1668 ports) of the 70,000 IP addresses in less than 40 hours. This was all on SuSE Linux Enterprise Server 9 (x86_64) with nmap version 3.93. We knew now this was not going to be easy. The number of SYN requests to do this is big, roughly: 65,535 hosts x 65535 ports x 2 (number of port query attempts) = 8,589,672,450 outbound SYN packets. If we could sustain ~3,500 outbound pps on each server, then we could finish in approximately 15 days (within the change control window). At 1,100 total pps, it is ~90 days, ouch!
In the mix of this engagement, there was a timely posting on the network security pen-test newsgroup asking about scanning a large network with nmap in which I posted a reply. I subsequently received a response from Fyodor (the author of nmap) which not only confirmed our experiences but also contained a link to an updated version to better enable nmap to handle this scenario (thanks Fyodor!!). I haven’t had a chance to use this updated version yet, but I’m excited to check it out. Also I am going to explore some home grown scanners we used while building a vulnerability scan engine and play around with the scanrand and unicorn scanners. This ended up being a great experience and a wake-up call to verify the tools we depend on work at the scale we need before accepting the next job.
Tags ClearNet Security, nmap, port, scanning, Tate Hansen, tuning, v40z | no comments
