What is the ideal speed to perform a network scan? There are three good reasons why the answer is rarely "as fast as possible."
Every network has a maximum capacity that when reached will cause packets to be silently dropped. Additionally, each host has finite processing and memory resources that can also cause packets to be dropped if received too fast. The end result is that if your scanner sends packets as fast as it possibly can, it is likely to cause packet loss, which leads to inaccurate results. (A scanner will likely interpret a dropped packet as being caused by a firewall or similar device.) We saw this behavior in Port Scanning when Scanrand was run without any throttling.
If you are scanning a network other than your own, there is the possibility of an intrusion detection system (IDS) or intrusion prevention system (IPS) device watching your every move. These devices are often configured to detect scans, and perhaps take an action in response (such as block your IP address for a period of time). Due to the way scan detection works, the faster the scan, the more likely it is to be detected.
Scans can wreak havoc on stateful network devices such as firewalls and NATing routers. Each packet of a scan typically represents a new connection, and a full-speed scan can easily exceed the resources of intermediary network devices. Depending on your network infrastructure, it is quite possible to perform a DoS (Denial of Service) attack on yourself by running a scan too fast. (I have personally crashed a number of commercial-grade firewalls by running Nmap with the -T5 option.) Another complication is that many firewall and IPS devices respond to a flood of SYN packets by enabling SYN cookies, which makes every port appear to be open.
Since controlling scan speed is so important, all three scanners provide various mechanisms to prevent packets from being sent too quickly. Each tool has taken its own approach to the problem, as detailed in the following sections.
Nmap provides a number of command-line options to fine-tune performance and packet timing. I almost never use these options myself, though, because Nmap provides premade timing templates that encapsulate a number of complex settings into five simple performance "levels." Additionally, Nmap tries to dynamically learn the capacity of the network and scan target and adjusts its behavior accordingly. This dynamic self-throttling is one of the key factors that causes Nmap to be so accurate (but also adds to the overall scan time).
The timing templates can be selected with the -T flag and may be referred to either by name or by number (for example: -T0 is equivalent to -T Paranoid.) The five templates are as follows:
This is by far the slowest template and is meant for serious IDS/IPS evasion. In this mode, Nmap scans only one port at a time (no parallelization) and waits five minutes between each packet being sent. While this extreme delay is likely to keep you below the radar, it also means that a default port scan of a single host takes nearly a week to complete.
This mode is also meant for IDS/IPS evasion but is a bit less, well, paranoid. Instead of waiting 5 minutes between packets, this mode waits a mere 15 seconds. This is more likely to be detected by a sensitive IDS/IPS device, but is considerably faster. A default scan of a single host takes under seven hours, compared to nearly a week for the Paranoid setting.
Modern IDS/IPS devices are likely sensitive enough to detect Sneaky scans. The Juniper IDP, for example, detects this scan with its default configuration. If you truly want to avoid detection, it is better to be paranoid or use an alternate method of avoiding detection (see Avoiding Detection).
This template is meant to slow the scan down to a level unlikely to interfere with fragile network devices. As with the previously mentioned templates, it disables parallelization, but waits only 0.4 seconds between packets. This should be slow enough to not overwhelm firewalls or other stateful devices while bringing the default scan time down to around 10 minutes.
This is the default behavior of Nmap when no performance options or templates are specified.
This is similar to the Normal template, but lowers the host and port timeouts and reduces the number of packet retransmissions. This speeds up the scan slightly when packet filtering (such as done by a firewall) is occurring.
This is the fastest template and lowers the timeouts and retransmissions even further. This can lead to a significant speed increase on a reliable network with firewalling, but can lead to inaccurate results when used on a slow or unreliable network.
If the provided templates aren't exactly what you want, you can fine-tune the performance by first specifying a template followed by the various tuning options. (To learn more about the Nmap tuning options, see the "Timing and Performance" section of the Nmap manpage.)
Tuning performance with Unicornscan is very simple. A single flag, -r pps is provided, which allows you to specify the packets per second to be sent during the scan. When no -r option is provided, the scan defaults to 300 packets per second. This is a reasonable value for most Internet links, but can be tuned up or down depending on the environment. In particular, large scans on a LAN segment can benefit from having the packets per second value increased. Compare the time of a default scan versus a scan with a packet-per-second value of 5000:
bryan@firemaw:˜$time sudo unicornscan 10.150.9.1/24Open ssh[ 22] From 10.150.9.15 ttl 64 Open sunrpc[ 111] From 10.150.9.15 ttl 64 [ Results omitted ] Open netbios-ssn[ 139] From 10.150.9.201 ttl 128 Open microsoft-ds[ 445] From 10.150.9.201 ttl 128 real1m44.673sbryan@firemaw:˜$time sudo unicornscan -r 5000 10.150.9.1/24Open ssh[ 22] From 10.150.9.15 ttl 64 Open sunrpc[ 111] From 10.150.9.15 ttl 64 [ Results omitted ] Open netbios-ssn[ 139] From 10.150.9.201 ttl 128 Open microsoft-ds[ 445] From 10.150.9.201 ttl 128 real0m15.033s
By increasing the rate of packet generation, we were able to obtain the same scan results in a fraction of the time of the default. Finding the ideal scan rate for the target typically takes some trial and error. A value too high may cause some ports to be missed, while a value too low wastes time.
As with Unicornscan, Scanrand provides only a single option for tuning performance. The -b numberunit option allows you specify the maximum bandwidth the scan can consume. The number can be any decimal value, while the unit can be one of b, k, m, or g, specifying bytes, kilobytes, megabytes, and gigabytes per second, respectively. For example, to scan the most common ports on my subnet at 12 kilobytes per second, I would type:
sudo scanrand -b 12k 10.150.9.1-254:squickIf you are more comfortable thinking in terms of packets per second, you can multiply that value by 40 (the size of a TCP SYN packet) to reach the desired bandwidth value. The value of 12k roughly corresponds to a packet per second value of 300, the default value for Unicornscan.
By default, Scanrand doesn't limit its bandwidth usage at all, which can lead to extremely inaccurate results (even a total lack of results) due to packet loss. It's always a good idea to use the -b flag to keep Scanrand well within the limits of the network being scanned.