Timing and Performance
One of my highest Nmap development priorities has always been
performance. A default scan (nmap
<hostname>
) of a host on my local
network takes a fifth of a second. That is barely enough time to
blink, but adds up when you are scanning hundreds or thousands
of hosts. Moreover, certain scan options such as UDP scanning and
version detection can increase scan times substantially. So can
certain firewall configurations, particularly response rate limiting.
While Nmap utilizes parallelism and many advanced algorithms to
accelerate these scans, the user has ultimate control over how Nmap
runs. Expert users carefully craft Nmap commands to obtain only the
information they care about while meeting their time
constraints.
Techniques for improving scan times include omitting non-critical tests, and upgrading to the latest version of Nmap (performance enhancements are made frequently). Optimizing timing parameters can also make a substantial difference. Those options are listed below.
Some options accept a time
parameter. This
is specified in seconds by default, though you can append
‘ms’, ‘s’, ‘m’, or ‘h’ to the value to
specify milliseconds, seconds, minutes, or hours. So the
--host-timeout
arguments 900000ms
,
900
, 900s
, and 15m
all do the same thing.
-
--min-hostgroup
;<numhosts>
--max-hostgroup
(Adjust parallel scan group sizes)<numhosts>
-
--min-parallelism
;<numprobes>
--max-parallelism
(Adjust probe parallelization)<numprobes>
-
--min-rtt-timeout
,<time>
--max-rtt-timeout
,<time>
--initial-rtt-timeout
(Adjust probe timeouts)<time>
Nmap maintains a running timeout value for determining how long it will wait for a probe response before giving up or retransmitting the probe. This is calculated 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 a conservative (high) level and may stay that way for a while when Nmap scans unresponsive hosts.
Specifying a lower
--max-rtt-timeout
and--initial-rtt-timeout
than the defaults can cut scan times significantly. This is particularly true for pingless (-Pn
) scans, and those against heavily filtered networks. Don't get too aggressive though. The scan can end up taking longer if you specify such a low value that many probes are timing 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 a reasonable aggressive value. If routing is involved, ping a host on the network first with the ICMP ping utility, or with a custom packet crafter such as Nping that is more likely to get through a firewall. Look at the maximum round trip time out of ten packets or so. You might want to double that for the--initial-rtt-timeout
and triple or quadruple it for the--max-rtt-timeout
. I generally do not set the maximum RTT below 100 ms, no matter what the ping times are. Nor do I exceed 1000 ms.--min-rtt-timeout
is a rarely used option that could be useful when a network is so unreliable that even Nmap's default is too aggressive. Since Nmap only reduces the timeout down to the minimum when the network seems to be reliable, this need is unusual and should be reported as a bug to the nmap-dev mailing list.-
--max-retries
(Specify the maximum number of port scan probe retransmissions)<numtries>
-
--host-timeout
(Give up on slow target hosts)<time>
-
--script-timeout
<time>
-
--scan-delay
;<time>
--max-scan-delay
(Adjust delay between probes)<time>
This option causes Nmap to wait at least the given amount of time between each probe it sends to a given host. This is particularly useful in the case of rate limiting. Solaris machines (among many others) will usually respond to UDP scan probe packets with only one ICMP message per second. Any more than that sent by Nmap will be wasteful. A
--scan-delay
of1s
will keep Nmap at that slow rate. Nmap tries to detect rate limiting and adjust the scan delay accordingly, but it doesn't hurt to specify it explicitly if you already know what rate works best.Another use of
--scan-delay
is to evade threshold based intrusion detection and prevention systems (IDS/IPS). This technique 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 other intrusion detection systems can be defeated in the same way.-
--min-rate
;<number>
--max-rate
(Directly control the scanning rate)<number>
Specifying a minimum rate should be done with care. Scanning faster than a network can support may lead to a loss of accuracy. In some cases, using a faster rate can make a scan take longer than it would with a slower rate. This is because Nmap's adaptive retransmission algorithms will detect the network congestion caused by an excessive scanning rate and increase the number of retransmissions in order to improve accuracy. So even though packets are sent at a higher rate, more packets are sent overall. Cap the number of retransmissions with the
--max-retries
option if you need to set an upper limit on total scan time.--defeat-rst-ratelimit
Many hosts have long used rate limiting to reduce the number of 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 it adjusts its timing to reflect those rate limits. You can tell Nmap to ignore those rate limits (for port scans such as SYN scan which don't treat non-responsive ports as
open
) by specifying--defeat-rst-ratelimit
.--defeat-icmp-ratelimit
--nsock-engine iocp|epoll|kqueue|poll|select
-
-T paranoid|sneaky|polite|normal|aggressive|insane
(Set a timing template) While the fine-grained timing controls discussed in the previous section are powerful and effective, some people find them confusing. Moreover, choosing the appropriate values can sometimes take more time than the scan you are trying to optimize. Fortunately, Nmap offers a simpler approach, 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
), andinsane
(5
). The first two are for IDS evasion. Polite mode slows down the scan to use less bandwidth and target machine resources. Normal mode is the default and so-T3
does nothing. Aggressive mode speeds scans up by making the assumption that you are on a reasonably fast and reliable network. Finally insane mode assumes that you are on an extraordinarily fast network or are willing to sacrifice some accuracy for speed.These templates allow the user to specify how aggressive they wish to be, while leaving Nmap to pick the exact timing values. The templates also make some minor speed adjustments for which fine-grained control options do not currently exist. For example,
-T4
prohibits the dynamic scan delay from exceeding 10 ms for TCP ports and-T5
caps that value at 5 ms. Templates can be used in combination with fine-grained controls, and the fine-grained controls that you specify will take precedence over the timing template default for that parameter. I recommend using-T4
when scanning reasonably modern and reliable networks. Keep that option even when you add fine-grained controls so that you benefit from those extra minor optimizations that it enables.If you are on a decent broadband or ethernet connection, I would recommend always using
-T4
. Some people love-T5
though it is too aggressive for my taste. People sometimes specify-T2
because they think it is less likely to crash hosts or because they consider themselves to be polite in general. They often don't realize just how slow-T polite
really is. Their scan may take ten times longer than a default scan. Machine crashes and bandwidth problems are rare with the default timing options (-T3
) and so I normally recommend that for cautious scanners. Omitting version detection is far more effective than playing with timing values at reducing these problems.While
-T0
and-T1
may be useful for avoiding IDS alerts, they will take an extraordinarily long time to scan thousands of machines or ports. For such a long scan, you may prefer to set the exact timing values you need rather than rely on the canned-T0
and-T1
values.The main effects of
T0
are serializing the scan so only one port is scanned at a time, and waiting five minutes between sending each probe.T1
andT2
are similar but they only wait 15 seconds and 0.4 seconds, respectively, between probes.T3
is Nmap's default behavior, which includes parallelization.-T4
does 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 delay to 10ms.T5
does 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 as setting the maximum TCP and SCTP scan delay to 5ms. Maximum UDP scan delay is not set byT4
orT5
, but it can be set with the--max-scan-delay
option.