Problems are always easier to solve when you have the right tools. It's no use having the latest power drill if you don't have the correct drill bit for the particular job at hand. Likewise with Nmap, the top of the range network scanner is not helpful if you don't know the right scan options for a given objective. In this article, let's look at using Nmap to scan for a variety of important network security information. We'll review real-life enterprise scenarios where the network mapper can be put to effective use.
Depending on the size of your network, a scan can take a long time to complete and can also cause disruption to the smooth running of the network. For this reason, it's important to have a clear aim of what you want to achieve from a particular scan in order to keep it targeted, simple and as quick and efficient as possible. Let me show you what I mean.
1) Using Nmap to scan for open
A common task for any network administrator is to find a particular open port on a large network. Hosts on a network, for example, may have been infected by a bot that opens a particular port in order to communicate with its controller. Targeting a scan just to look for that specific port can quickly identify any other compromised hosts. If the bot is opening port 21014, then the following scan will quickly identify machines with that specified port open:
nmap –PN –p21014 -oN botsearchreport.txt dev.yourorg.com/24
2) Using Nmap to scan for updated servers and databases
nmap –sS –A –p3306 –oN mysqlupgradereport.txt dev.yourorg.com/24
The results of this scan will be written to the file mysqlupgradereport.txt and can be used to check the version of MySQL running in the targeted IP address range on port 3306. An additional piece of useful information can also be gleaned from Nmap's service detection information regarding the security of each of these databases. If MySQL has been configured to disallow remote logins from untrusted IP addresses, the word "unauthorized" will be included in the output if you run the scan from an untrusted machine. If your security policy states that test databases should only accept connections from trusted IPs, any scanned database not returning an info field that contains an "unauthorized" distinction needs to be investigated and locked down.
It's important to recognize that this scan is aimed at verifying that all the MySQL databases running on port 3306 within the development team have been upgraded. If you were concerned that there may be unknown MySQL databases running elsewhere on the network, then you would need to broaden the scan's parameters to scan all IP addresses and all ports -- a different scan for a different task.
3) Using Nmap to scan for trust relationships
If you want to find out more about the trust relationships that exist on your network, you can use the IPID Idle scan (option -sI). This type of scan utilises a zombie host to disguise the scan and show open ports and map out IP-based trust relationships between machines from the zombie machine's perspective. So, for example, a normal scan against a database server may show no open ports, but by using a file server's IP address as the zombie, the database-related service ports on the database server may be shown as open, exposing a trust relationship.
Hackers can use trust relationships to prioritise their targets; a Web server is a far more attractive target if it has database access. If Nmap reveals your network is susceptible to IPID-related attacks, you need to configure or adjust your firewall and router rules to deny incoming packets with bogus source addresses. Also, you should enable egress filtering to stop spoofed packets from leaving your network to prevent internal users from launching this type of attack.
4) Using Nmap to scan for baseline information
You should, of course, keep the results of all the scans you run, as you never know when the information gathered will be valuable. One way to utilise this data is to store it in a database so future results can be compared to a known accepted baseline. The results from the following random scan, for example, could be compared to expected values in the database:
nmap –sS–iL scanlist.txt --exclude noscanlist.txt --randomize_hosts –R –O –T2 –oX randomscanresults.xml
As we reviewed in a previous article, the TCP SYN stealth scan (–sS) keeps network disruption to a minimum. The iL and –exclude options tell Nmap where to obtain the list of IP addresses to scan or exclude, while the –-randomize_hosts option ensures no one subnet is bombarded, as the scan randomly roams from one device to another. As assigned IP addresses in dynamic environments can change, you need to use the –R option so Nmap performs a reverse name resolution. This is essential for comparing past and future results.
Since this is a regular scan set up to watch over the network, speed is not essential, whereas keeping it undetectable is. In an effort to keep this scan passive, simple and relatively fast, the version scan option has not been included. Unlike the operating system fingerprinting function, version detection is a more invasive method of querying a remote device. However, we do need to know what's out there on the network; therefore use the operating system fingerprinting option, -O, to obtain as much information as possible with relatively little network interaction. A timing policy of -T2, "polite", allows the scan to run at a reasonable pace but again with a low amount of interactivity. Finally, outputting the results to an XML file means it can easily be imported to a database for checking.
Scanning on a regular basis offers a picture and feel for what's normal on your network. Anything that looks out of the ordinary can then be investigated further, allowing you to focus your attention on potential trouble spots. In my next article, we'll look at how Nmap can be used to test the effectiveness of your own firewalls and intrusion detection systems.
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 May 2009