Timing and Performance:
Option –min-hostgroup <numhosts>; –max-hostgroup <numhosts> (Adjust parallel scan group sizes):
Nmap has the ability to port scan or version scan multiple hosts in parallel. Nmap does this by dividing the target IP space into groups and then scanning one group at a time. In general, larger groups are more efficient. The downside is that host results can’t be provided until the whole group is finished. So if Nmap started out with a group size of 50, the user would not receive any reports (except for the updates offered in verbose mode) until the first 50 hosts 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 results come quickly and then increases the groupsize to as high as 1024. The exact default numbers depend on the options given. For efficiency reasons, Nmap uses larger group sizes for UDP or few-port TCP scans.
When a maximum group size is specified with –max-hostgroup, Nmap will never exceed that size. Specify a minimum size with –min-hostgroup and Nmap will try to keep group sizes above that level. Nmap may have to use smaller groups than you specify if there are not enough target hosts left on a given interface to fulfill the specified minimum. Both may be set to keep the group size within a specific range, though this is rarely desired.
For the purpose of this demonstration, we used port limitions of 1-2, random ip range, 1 max-hostgroup.
Option –min-parallelism <numprobes>; –max-parallelism <numprobes> (Adjust probe parallelization):
These options control the total number of probes that may be outstanding for a host group. They are used for port scanning and host discovery. By default, Nmap calculates an ever-changing ideal parallelism based on network performance. If packets are being dropped, Nmap slows down and allows fewer outstanding probes. The ideal probe number slowly rises as the network proves itself worthy. These options place minimum or maximum bounds on that variable. By default, the ideal parallelism can drop to 1 if the network proves unreliable and rise to several hundred in perfect conditions.
The most common usage is to set –min-parallelism to a number higher than one to speed up scans of poorly performing hosts or networks. This is a risky option to play with, as setting it too high may affect accuracy. Setting this also reduces Nmap’s ability to control parallelism dynamically based on network conditions. A value of ten might be reasonable, though I only adjust this value as a last resort.
With max-parallelism 100. Result! very fast!
Option –min-rtt-timeout <time>, –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. 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.
With 100ms max-rtt-timeout 10 ips were scanned in 2.023 seconds. Ofcourse for only 2 ports. But that’s very fast not recommended if you care about accurecy.
Option –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 lengthen 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 rarely recommended.
We did it with max-retries set at 0, and we got a warning for hitting retransmission cap.
Option –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.
We did it with 2 sec. It took 11.217s . A default scan for the same ip took 3.27 second.
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 nonresponsive ports as open) by specifying –defeat-rst-ratelimit.
Option -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. So 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 are paranoid (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 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.
Lets try insane…Hacking Hacking Linux News News Software Review Hacking Tools News Nmap Software Review