#readwise # Nmap Timing and Performance  ## Metadata - Author: [[nmap.org]] - Full Title: Nmap Timing and Performance - URL: https://nmap.org/book/man-performance.html ## Summary Nmap can scan a host on a local network in just a fifth of a second, but certain options can slow it down. You can improve scan times by reducing timeout values and limiting retransmissions. It’s also possible to control the scan rate with options like --min-rate and --max-rate. However, scanning too quickly may lead to inaccurate results due to network congestion. ## Highlights `--max-rtt-timeout <time>`, `--initial-rtt-timeout <time>` (Adjust probe timeouts) 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”](https://nmap.org/book/man-performance.html/port-scanning-algorithms.html). 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. ([View Highlight](https://read.readwise.io/read/01jp4wr4wd77es3a4b3n7zqdaq)) ^p2uaql --- `--max-retries <numtries>` (Specify the maximum number of port scan probe retransmissions) When Nmap receives no response to a port scan probe, it could mean the port is filtered. Or maybe the probe or response was simply lost on the network. It is also possible that the target host has rate limiting enabled that temporarily blocked the response. So Nmap tries again by retransmitting the initial probe. If Nmap detects poor network reliability, it may try many more times before giving up on a port. While this benefits accuracy, it also lengthens scan times. When performance is critical, scans may be sped up by limiting the number of retransmissions allowed. You can even specify `--max-retries 0` to prevent any retransmissions, though that is only recommended for situations such as informal surveys where occasional missed ports and hosts are acceptable. The default (with no `-T` template) is to allow ten retransmissions. If a network seems reliable and the target hosts aren't rate limiting, Nmap usually only does one retransmission. So most target scans aren't even affected by dropping `--max-retries` to a low value such as three. Such values 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 information about the target. ([View Highlight](https://read.readwise.io/read/01jp4ww5z87b3t3zv827wvg3sh)) ^hxnyvm --- `--host-timeout <time>` (Give up on slow target hosts) Some hosts simply take a *long* time to scan. This may be due to poorly performing or unreliable networking hardware or software, packet rate limiting, or a restrictive firewall. The slowest few percent of the scanned hosts can eat up a majority of the scan time. Sometimes it is best to cut your losses and skip those hosts initially. Specify `--host-timeout` with the maximum amount of time you are willing to wait. For example, specify `30m` to ensure that Nmap doesn't waste more than half an hour on a single host. Note that Nmap may be scanning 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 printed for 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. ([View Highlight](https://read.readwise.io/read/01jp4wxr23fcyks9s70g77r04a)) --- `--scan-delay <time>` `--max-scan-delay <time>` (Adjust delay between probes) 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` of `1s` 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. When Nmap adjusts the scan delay upward to cope with rate limiting, the scan slows down dramatically. The `--max-scan-delay` option specifies the largest delay that Nmap will allow. A low `--max-scan-delay` can speed up Nmap, but it is risky. Setting this value too low can lead to wasteful packet retransmissions and possible missed ports when the target implements strict rate limiting. 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”](https://nmap.org/book/man-performance.html/subvert-ids.html#defeating-ids-snort-portscan) to defeat the default port scan detector in Snort IDS. Most other intrusion detection systems can be defeated in the same way. ([View Highlight](https://read.readwise.io/read/01jp4wzxn1a7tv6q78tnd22j7f)) ---