In my previous Nmap article, I touched on some of the Nmap scan options that can be used to set time restrictions. In this last feature on Nmap, I want to look at a few more timing options and other factors that can affect whether your Nmap scan is productive or not. Finally I'll wrap up with a quick look at how to use the Zenmap GUI, the official graphical user interface for Nmap.
Optimizing the timing parameters your scan uses can reduce scan times dramatically. But scanning isn't necessarily always about speed. For example, the Maximum Delay Between Probes option, --max_scan_delay, sets an upper limit for the time Nmap will delay between each request. This option can significantly slow the total scan time, but can be useful on slow or congested WAN connections. On the other hand, the Minimum Delay Between Probes option, --scan_delay, lets you set the delay between each probe frame to speed up or slow down a scan as required, allowing you to scan over a slow link or test an intrusion prevention device, for example.
These and other low-level Nmap scan options can be particularly useful when analyzing networks where routers and firewalls are filtering the traffic to a point where Nmap can't determine its own timing estimates. You can read the Nmap Timing and Performance Reference Guide for a detailed explanation of the many timing options and how best to use them.
Collecting only the information you need is another way of improving scan performance. For example, if you need to scan UDP ports, you shouldn't combine the test with a TCP scan as the timing requirements will be different. UDP scans tend to take a lot longer to complete. One way to speed up any type of scan is to use the Parallel Host and Parallel Port scanning options to set the minimum, or maximum, number of hosts or ports that are scanned simultaneously. These options can be used to improve the efficiency of an unattended batch scan, or to allow Nmap to display results more quickly by reducing the number of simultaneous hosts being scanned.
If you don't want to configure all these options separately, you can use Nmap's predefined timing templates, with names like paranoid (T0) and insane (T5), instead. These range from the slow, quiet and accurate to the fast, loud and not so accurate. If you are auditing a remote office over a slow link, for example, you can add a lower-numbered timing template, such as –T2, to slow down the scan and use less bandwidth and resources on the target machines. Conversely, you can use more aggressive speeds, like –T4 and -T5 on more reliable networks. These timing templates are also great for testing security devices, such as intrusion detection and intrusion prevention systems. By running each timing template, you can refine your network monitoring thresholds based on the conditions that triggered particular alarm or packet filtering events to occur.
Unlike other Nmap commands, the location of a timing option on the command line is important because the last option takes priority. This means you can put a timing template at the beginning of the command line and specify other individual timing options afterwards to create a customized combination of timings without having to specify every possible timing option on the command line. For example:
nmap –T0 –-scan_delay 180000 scanreport.txt www.yourorg.com
The above command sets the scan delay to three minutes instead of the paranoid setting (T0) of five minutes, while leaving its other template settings unchanged. If it still appears to be taking longer than expected, even after your careful construction of a scan command, you can change certain options or request status messages while you're running a scan without having to abort and restart it. For example, typing V will increase the detail of the output while most keys will give you a status update showing hosts completed and estimated time remaining.
How to use the Zenmap GUI
As you can see, to get the most out of Nmap, you need to spend time exploring its many different options and how they affect your scan results. At first this can seem rather daunting, particularly if, like me, you don't like working from a command prompt. Thankfully, Nmap has for sometime had a very good GUI, which makes learning how to use Nmap a lot easier. The interface also has several advanced features for the more experienced user. One small gripe is that the Help button isn't context-sensitive; it just takes you to the online pages at http://nmap.org/zenmap/. These, however, do cover everything you need to know about using Zenmap.
As a beginner, I would recommend using the Command Constructor Wizard as this groups related options together, letting you see the Nmap command build up as you select an option. Not only is this good practice, but you get to appreciate the hundreds of different options available. Once you have built a scan using Zenmap that you want to reuse, it's easy to save it as a profile. You can then rerun the exact same scan, and Zenmap will graphically show any differences between the two scans. It can also compare scans against different hosts, which is great for checking if a new server has been set up in the same way as an existing one. It can also compare different scans against the same host, testing responses from security devices, for example.
This ability to compare Nmap scans and present scan results in different formats makes Zenmap a great add-on even for experienced users. The ease with which an individual host detected in a scan can be scanned in more detail and have their results added to the original scan is also impressive -- it's something you can't do from a scan started from the command line. Features like this make auditing, monitoring and presenting information about a network much easier.
At the start of this series of articles I said you should consider open source security tools if they're the most effective solution for a particular task. Hopefully, I've managed to show you how useful and easy Nmap is to use and that it is an obvious choice for network administrators tasked with keeping track of what's running on their network and who's connecting to it.
About the author:
Michael Cobb, CISSP-ISSAP is the founder and managing director of Cobweb Applications Ltd., a consultancy that offers IT training and support in data security and analysis. He co-authored the book IIS Security and has written numerous technical articles for leading IT publications.
This was first published in June 2009