Scan Time Reduction Techniques | Nmap Network Scanning (2024)

The electronic equivalent to buying a Hummer when you neverleave the pavement or carry more than groceries is to launch anintense and comprehensive Nmap scan to obtain a relatively trivialamount of information. Wasting a few seconds per host rarely matterson a home network, but can make daily WAN scans infeasible for largeenterprises. The following list details ways to avoid common over-scanningmistakes, starting with the most egregious problems and followed by more subtle optimizations that even advanced users often forget.

Nmap offers dozens of options for providing hints and rules tocontrol scan activity. These range from high level timingaggressiveness levels provided by the-Toption(described in the section called “Timing Templates (-T)”) to thefiner-grained controls described inthe section called “Low-Level Timing Controls”. You can even combine thetwo. These options are particularly useful when scanning highlyfiltered networks where Nmap receives few responses to determine itsown timing estimates. Scan time can often be safely cut in half.Most of these options will have little effect against a local LANfilled with responsive hosts, as Nmap can determine optimal valuesitself in that case.

Scanning UDP ports is important because many vulnerable servicesuse that protocol, but the timing characteristics and performancerequirements of UDP scans are much different than TCP scans. Ofparticular concern is ICMP error rate-limiting, which is extremelycommon and affects UDP scans far more often than TCP.

For these reasons, I don't recommend combining TCP and UDP scanswhen performance is critical, even though Nmap supports doing so withoptions such as -sSU. You often wantdifferent timing flags for each protocol, requiring separate command lines.the section called “Speeding Up UDP Scans” provides valuable tricksand real-life examples for improving UDP scan performance.

There have been many cases where I have investigated reports ofpoor Nmap performance only to find that the reporter used an ancientversion that was many years out of date. The newest versions of Nmaphave important algorithmic improvements, bug fixes,performance-enhancing features such as local network ARP scanning, andmore. The first response to performance problems should be to compareyour version of Nmap (run nmap -V) with the latestversion available from https://nmap.org.Upgrade if necessary. If it is still not fast enough, try the othertechniques in this chapter.

Some people try to speed up Nmap by executing many copies inparallel against one target each. For example, the Nessus scannerused to do this by default. This is usually much less efficient and slowerthan letting Nmap run against the whole network. Nmap has its ownparallelizationsystem that is customized to its needs, and Nmap isable to speed up as it learns about network reliability when it scansa large group. Further, there is substantial overhead in asking theOS to fork 65,536 separate Nmap instances just to scan a class B.Having dozens of copies of Nmap running in parallel is also a memorydrain since each instance loads its own copy of the data files such asnmap-services andnmap-os-db.

While launching single-host Nmap scans in parallel is a badidea, overall speed can usually be improved by dividing the scan intoseveral large groups and executing those concurrently. Don't gooverboard though. Five or ten Nmap processes are fine, but launching 100 Nmap processes at once is notrecommended. Launching too many concurrent Nmap processes leads toresource contention. Another sort of concurrency is to run Nmap fromdifferent hosts at once. You can have cron (or At on Windows)schedule local hosts on each of your networks to start scanning machineslocal to them at the same time, then mail the results to a central dataserver. Scanning your Australian network from the U.S. will be slowerthan scanning it from a local machine on that network. The difference will be evengreater if the U.S. machine must traverse extra firewalls to reach thedistant network.

Restrictive firewalls can turn a five-second scan into a multi-hourchore. Thelatencyand packet lossassociated with some Internetroutes doesn't help either. If you can run Nmap from host(s) local tothe target network, do so. Of course if the goal is to view thenetwork as an external attacker would, or to test the firewall,external scanning is required. On the other hand, scanning andsecuring the internal network provides defense in depth which iscritical against internal threats and those wily attackers who circumventthe firewall (see Chapter10, Detecting and Subverting Firewalls and Intrusion Detection Systems).

When doing reverse DNS resolution, especially if you have a heavily burdenedlocal nameserver, it can help to use a less busy nameserver or directly querythe authoritative nameservers. This gain is usually slight and only worth doing for repeated or enormous scans. Of course, there are sometimes non-performance reasons for choosing nameservers.

You can occasionally improve Nmap scan times by increasing youravailable bandwidth or CPU power. This may be done either by installinga new data line or CPU, or by halting concurrently running applicationswhich compete for these resources. For example, Nmap will run slower if you concurrently saturate your DSL line by downloading a pirate torrent of The MatrixReloaded.

It is far more common that Nmap is constrained by its owncongestion control algorithmsthan being CPU-bound or limited by theavailable local bandwidth. These controls help prevent networkflooding and increase accuracy. Increasing CPU power and localbandwidth won't help this sort of self-limiting by Nmap—timingoptions must be adjusted instead. You can test whether Nmap is CPUconstrained by monitoring your CPU load with an application such astop on Unix or the TaskManager on Windows. If your CPU spends most of its timeidle, then upgrading won't help much. To test Nmap's bandwidth usage,run it in verbose mode (-v). Nmap will then reportthe number of bytes sent and received and its execution time, as shownin Example6.1.

# nmap -v -n -p- sec.titan.netStarting Nmap ( https://nmap.org )[10 lines cut]Nmap scan report for 192.168.0.8Not shown: 65534 closed portsPORT STATE SERVICE22/tcp open sshMAC Address: 00:1A:6B:C1:33:37 (USI)Nmap done: 1 IP address (1 host up) scanned in 2.20 seconds Raw packets sent: 65536 (2.884MB) | Rcvd: 65536 (2.621MB)

Multiply the byte values by eight and divide by the execution timeto get the average bandwidth usage in bits per second. InExample6.1,Nmap received 2,621,000 bytes(Nmap considers 1,000,000 bytes to be a MB) in 2.20 seconds. Soreceive traffic was about 9.5Mbps (send rate was 10.5Mbps). Therefore the 100Mbps ethernet linkisn't likely constraining Nmap, and upgrading to gigabit ethernet won't helpmuch.

Some consumer broadband devices and other equipment struggles tohandle the rate of packets sent by Nmap, even though thesmall packet size (usually Nmap sends empty headers) keeps bandwidthlow. In Example6.1, “Bandwidth usage over local 100Mbps ethernet network”, Nmap sentabout 30,000 packets per second and received a similar number. Suchhigh packet rates can cause problem with low-quality devices. In thiscase, we see that both send and receive packet counts were 65,536,which is the number of scanned ports (65,535) plus one for the initialARP ping probe. Therefore Nmap did not encounter any packet dropsrequiring retransmission. This suggests again that the networkingequipment was not a limiting factor—Nmap was probably CPUbound.