Timing and Performance | Nmap Network Scanning (2024)

Nmap has the ability to port scan or version scan multiple hostsin parallel. Nmap does this by dividing the target IP space intogroups and then scanning one group at a time. In general, largergroups are more efficient. The downside is that host results can't beprovided until the whole group is finished. So if Nmap started outwith a group size of 50, the user would not receive any reports(except for the updates offered in verbose mode) until the first 50hosts are completed.

By default, Nmap takes a compromise approach to this conflict.It starts out with a group size as low as five so the first resultscome quickly and then increases the groupsize to as high as 1024. Theexact default numbers depend on the options given. For efficiencyreasons, Nmap uses larger group sizes for UDP or few-port TCPscans.

When a maximum group size is specified with--max-hostgroup, Nmap will never exceed that size.Specify a minimum size with --min-hostgroup and Nmapwill try to keep group sizes above that level. Nmap may have to usesmaller groups than you specify if there are not enough target hostsleft on a given interface to fulfill the specified minimum. Both maybe set to keep the group size within a specific range, though this israrely desired.

These options do not have an effect during the host discoveryphase of a scan. This includes plain ping scans (-sn).Host discovery always works in large groups of hosts to improve speedand accuracy.

The primary use of these options is to specify a large minimumgroup size so that the full scan runs more quickly. A common choiceis 256 to scan a network in /24 sized chunks. For a scan withmany ports, exceeding that number is unlikely to help much. For scansof just a few port numbers, host group sizes of 2048 or more may behelpful.

These options control the total number of probes that maybe outstanding for a host group. They are used for port scanning andhost discovery. By default, Nmap calculates an ever-changing idealparallelism based on network performance. If packets are being dropped,Nmap slows down and allows fewer outstanding probes. The ideal probenumber slowly rises as the network proves itself worthy. Theseoptions place minimum or maximum bounds on that variable. By default,the ideal parallelism can drop to one if the network proves unreliableand rise to several hundred in perfect conditions.

The most common usage is to set--min-parallelism to a number higher than one tospeed up scans of poorly performing hosts or networks. This is arisky option to play with, as setting it too high may affect accuracy.Setting this also reduces Nmap's ability to control parallelismdynamically based on network conditions. A value of 10 might bereasonable, though I only adjust this value as a last resort.

The --max-parallelism option is sometimes set to oneto prevent Nmap from sending more than one probe at a time to hosts.The --scan-delay option, discussed later, is anotherway to do this.

Nmap maintains arunning timeout value for determining how long it will wait for aprobe response before giving up or retransmitting the probe. This iscalculated based on the response times of previous probes.The exact formula is given in the section called “Scan Code and Algorithms”.If the network latency shows itself to be significant and variable,this timeout can grow to several seconds. It also starts at aconservative (high) level and may stay that way for a while when Nmapscans unresponsive hosts.

Specifying a lower --max-rtt-timeout and--initial-rtt-timeout than the defaults can cut scantimes significantly. This is particularly true for pingless(-Pn) scans, and those against heavily filterednetworks. Don't get too aggressive though. The scan can end uptaking longer if you specify such a low value that many probes aretiming out and retransmitting while the response is in transit.

If all the hosts are on a local network, 100 milliseconds(--max-rtt-timeout 100ms) is areasonable aggressive value. Ifrouting is involved, ping a host on the network first with the ICMPping utility, or with a custom packet crafter such asNpingthat ismore likely to get through a firewall. Look at the maximum round triptime out of ten packets or so. You might want to double that for the--initial-rtt-timeout and triple or quadruple it forthe --max-rtt-timeout. I generally do not set themaximum RTT below 100ms, no matter what the ping times are. Nor do Iexceed 1000ms.

--min-rtt-timeout is a rarely used option thatcould be useful when a network is so unreliable that even Nmap'sdefault is too aggressive. Since Nmap only reduces the timeout down tothe minimum when the network seems to be reliable, this need isunusual and should be reported as a bug to thenmap-dev mailing list.

When Nmap receives no response to a port scan probe, it couldmean the port is filtered. Or maybe the probe or response was simplylost on the network. It is also possible that the target host hasrate limiting enabled that temporarily blocked the response. So Nmaptries again by retransmitting the initial probe. If Nmap detects poornetwork reliability, it may try many more times before giving up on aport. While this benefits accuracy, it also lengthens scan times.When performance is critical, scans may be sped up by limiting thenumber of retransmissions allowed. You can even specify--max-retries 0 to prevent any retransmissions,though that is only recommended for situations such as informalsurveys where occasional missed ports and hosts are acceptable.

The default (with no -T template) is to allowten retransmissions. If a network seems reliable and the target hostsaren't rate limiting, Nmap usually only does one retransmission. Somost target scans aren't even affected by dropping--max-retries to a low value such as three. Suchvalues can substantially speed scans of slow (rate limited) hosts.You usually lose some information when Nmap gives up on ports early,though that may be preferable to letting the--host-timeout expire and losing all informationabout the target.

Some hosts simply take a long time to scan.This may be due to poorly performing or unreliable networking hardwareor software, packet rate limiting, or a restrictive firewall. Theslowest few percent of the scanned hosts can eat up a majority of thescan time. Sometimes it is best to cut your losses and skip thosehosts initially. Specify --host-timeout with the maximum amount of time youare willing to wait. For example,specify 30m to ensure that Nmap doesn't wastemore than half an hour on a single host. Note that Nmap may bescanning other hosts at the same time during that half an hour, so it isn't a complete loss. A host that times out is skipped.No port table, OS detection, or version detection results are printedfor that host.

The special value 0 can be used to mean “no timeout”, which can be used to override the T5 timing template, which sets the host timeout to 15 minutes.

While some scripts complete in fractions of a second, others can take hours or more depending on the nature of the script, arguments passed in, network and application conditions, and more. The --script-timeout option sets a ceiling on script execution time. Any script instance which exceeds that time will be terminated and no output will be shown. If debugging (-d) is enabled, Nmap will report on each timeout. For host and service scripts, a script instance only scans a single target host or port and the timeout period will be reset for the next instance.

The special value 0 can be used to mean “no timeout”, which can be used to override the T5 timing template, which sets the script timeout to 10 minutes.

This option causes Nmap to wait at least the given amount oftime between each probe it sends to a given host. This isparticularly useful in the case of rate limiting. Solaris machines(among many others) will usually respond to UDP scan probe packetswith only one ICMP message per second. Any more than that sent byNmap will be wasteful. A --scan-delay of1s will keep Nmap at that slow rate. Nmap tries todetect rate limiting and adjust the scan delay accordingly, but itdoesn't hurt to specify it explicitly if you already know what rateworks best.

When Nmap adjusts the scan delay upward to cope with ratelimiting, the scan slows down dramatically. The--max-scan-delay option specifies the largest delaythat Nmap will allow. A low --max-scan-delaycan speed up Nmap, but it is risky. Setting this value too low can lead to wastefulpacket retransmissions and possible missed ports when the targetimplements strict rate limiting.

Another use of --scan-delay is to evadethreshold based intrusion detection and prevention systems(IDS/IPS). Thistechnique is used in the section called “A practical example: bypassing default Snort 2.2.0 rules”to defeat the default port scan detector in Snort IDS. Most otherintrusion detection systems can be defeated in the same way.

Nmap's dynamic timing does a good job of finding an appropriatespeed at which to scan. Sometimes, however, you may happen to know anappropriate scanning rate for a network, or you may have to guaranteethat a scan will be finished by a certain time. Or perhaps you must keepNmap from scanning too quickly. The --min-rate and--max-rate options are designed for thesesituations.

When the--min-rate option is given Nmap will do its best tosend packets as fast as or faster than the given rate. The argument is apositive real number representing a packet rate in packets per second.For example, specifying --min-rate 300 means thatNmap will try to keep the sending rate at or above 300 packets persecond. Specifying a minimum rate does not keep Nmap from going fasterif conditions warrant.

Likewise, --max-rate limits a scan's sending rate to agiven maximum. Use --max-rate 100, for example, tolimit sending to 100 packets per second on a fast network. Use--max-rate 0.1 for a slow scan of one packet every tenseconds. Use --min-rate and --max-ratetogether to keep the rate inside a certain range.

These two options are global, affecting an entire scan, notindividual hosts. They only affect port scans and host discovery scans.Other features like OS detection implement their own timing.

There are two conditions when the actual scanning rate may fallbelow the requested minimum. The first is if the minimum is faster thanthe fastest rate at which Nmap can send, which is dependent on hardware.In this case Nmap will simply send packets as fast as possible, but beaware that such high rates are likely to cause a loss of accuracy. Thesecond case is when Nmap has nothing to send, for example at the end ofa scan when the last probes have been sent and Nmap is waiting for themto time out or be responded to. It's normal to see the scanning ratedrop at the end of a scan or in between hostgroups. The sending rate maytemporarily exceed the maximum to make up for unpredictable delays, buton average the rate will stay at or below the maximum.

Specifying a minimum rate should be done with care. Scanningfaster than a network can support may lead to a loss of accuracy. Insome cases, using a faster rate can make a scan takelonger than it would with a slower rate. This isbecause Nmap's adaptiveretransmissionalgorithms will detect the network congestion caused by an excessive scanning rateand increase the number of retransmissions in order to improve accuracy.So even though packets are sent at a higher rate, more packets are sentoverall. Cap the number of retransmissions with the--max-retries option if you need to set an upper limit on total scantime.

Many hosts have long usedrate limitingto reduce the numberof ICMP error messages (such as port-unreachable errors) they send.Some systems now apply similar rate limits to the RST (reset)packets they generate. This can slow Nmap down dramatically as itadjusts its timing to reflect those rate limits. You can tell Nmap toignore those rate limits (for port scans such as SYN scan whichdon't treat non-responsive ports asopen) by specifying--defeat-rst-ratelimit.

Using this option can reduce accuracy, as some ports will appearnon-responsive because Nmap didn't wait long enough for a rate-limitedRST response. With a SYNscan, the non-response results in the port being labeledfiltered rather than the closedstate we see when RST packets are received. This option is usefulwhen you only care about open ports, and distinguishing betweenclosed and filtered ports isn'tworth the extra time.

Similar to --defeat-rst-ratelimit, the --defeat-icmp-ratelimit option trades accuracy for speed, increasing UDP scanning speed against hosts that rate-limit ICMP error messages. Because this option causes Nmap to not delay in order to receive the port unreachable messages, a non-responsive port will be labeled closed|filtered instead of the default open|filtered. This has the effect of only treating ports which actually respond via UDP as open. Since many UDP services do not respond in this way, the chance for inaccuracy is greater with this option than with --defeat-rst-ratelimit.

Enforce use of a given nsock IO multiplexing engine. Only theselect(2)-based fallback engine is guaranteed to beavailable on your system. Engines are named after the name of the IOmanagement facility they leverage. Engines currently implemented areepoll, kqueue, poll,and select, but not all will be present on any platform.By default, Nmap will use the "best" engine, i.e. the first one in this list that is supported.Use nmap -V to see which engines are supported on your platform.

While the fine-grained timing controls discussed in the previoussection are powerful and effective, some people find them confusing.Moreover, choosing the appropriate values can sometimes take more timethan the scan you are trying to optimize. Fortunately, Nmap offers a simplerapproach, with six timing templates. You can specify them with the-T option and their number (0–5) or their name.The template names areparanoid(0),sneaky(1),polite(2),normal(3),aggressive(4),and insane(5).The first two are for IDS evasion.Polite mode slows down the scan to use less bandwidthand target machine resources. Normal mode is the default and so-T3 does nothing. Aggressive mode speeds scans up bymaking the assumption that you are on a reasonably fast and reliablenetwork. Finallyinsane modeassumes that you are on anextraordinarily fast network or are willing to sacrifice some accuracyfor speed.

These templates allow the user to specify how aggressive theywish to be, while leaving Nmap to pick the exact timing values. Thetemplates also make some minor speed adjustments for whichfine-grained control options do not currently exist. For example,-T4prohibits the dynamic scan delay from exceeding10ms for TCP ports and -T5 caps that value at 5ms.Templates can be used in combination with fine-grainedcontrols, and the fine-grained controls that you specify will takeprecedence over the timing template default for that parameter. Irecommend using -T4 when scanning reasonably modernand reliable networks. Keep that option even when you addfine-grained controls so that you benefit from those extra minoroptimizations that it enables.

If you are on a decent broadband or ethernet connection, I wouldrecommend always using -T4. Some people love-T5 though it is too aggressive for my taste. Peoplesometimes specify -T2 because they think it is lesslikely to crash hosts or because they consider themselves to be politein general. They often don't realize just how slow -Tpolitereally is. Their scan may take ten times longer than adefault scan.Machine crashes and bandwidth problems are rare with thedefault timing options (-T3) and so I normallyrecommend that for cautious scanners. Omitting version detection isfar more effective than playing with timing values at reducing theseproblems.

While-T0and -T1may beuseful for avoiding IDS alerts, they will take an extraordinarily longtime to scan thousands of machines or ports. For such a long scan,you may prefer to set the exact timing values you need rather thanrely on the canned -T0 and -T1values.

The main effects of T0 are serializing the scanso only one port is scanned at a time, and waiting five minutesbetween sending each probe. T1 andT2 are similar but they only wait 15 seconds and 0.4seconds, respectively, between probes. T3 is Nmap'sdefault behavior, which includes parallelization.-T4does the equivalent of --max-rtt-timeout 1250ms --min-rtt-timeout 100ms --initial-rtt-timeout 500ms --max-retries 6 and sets the maximum TCP and SCTP scan delayto 10ms. T5does the equivalent of --max-rtt-timeout 300ms --min-rtt-timeout 50ms --initial-rtt-timeout 250ms --max-retries 2 --host-timeout 15m --script-timeout 10m as well assetting the maximum TCP and SCTP scan delay to 5ms.Maximum UDP scan delay is not set by T4 or T5, but it can be set with the --max-scan-delay option.