You'll find a complete description of the command-line switches in the manual (man) page for Nmap. (Nmap's UNIX man page covers the Win32 version adequately.) In addition, the Phrack Magazine article "The Art of Port Scanning," by Fyodor, September 1, 1997, offers an excellent description of the port-scanning techniques and features that Nmap uses. For these references and additional detailed information about how to use Nmap effectively, go to http://www.insecure.org/nmap/nmap_documentation.html. For a description of a sample port-scanning process, see the Web-exclusive sidebar "Basic Port Scanning in Action." (To read this sidebar, go to http://www.secadministrator.com and enter InstantDoc ID 23688.)
Getting Started with Nmap
Even if you've used port scanners before, I recommend using Nmap on a system you know to get a feel for the tool. Then, broaden the types of systems you scan as you become more comfortable with the tool's output. First, scan a few machines on your internal network to gauge how the tool reports your environment. Second, from an external IP address, scan your external network. Note how your firewall, Intrusion Detection System (IDS), and other network tools respond to your port scanning. For example, the TCP connect() scan tells Nmap to use the TCP connect() function for the scan. Most IDSs will log that function, but they won't necessarily log the half-connect TCP SYN scan function in a TCP SYN scan. Catalog the information that Nmap provides about your network for future reference.
Notify those concerned. In your testing, remember that many companies regard port scanning as a hostile act, so be considerate and limit port scanning to your own network. Also, let your colleagues know that you're port scanning because the process might trigger IDS alerts and possibly cause other networking problems.
Shut down unnecessary services. Use the information Nmap provides (taking into account your network's sensitivity) to shut down unneeded services or revise your router ACLs to block ports in front of your network. For example, suppose that you run IIS for an external Web server. Figure 4 shows output from an Nmap scan of a default installation of Win2K server running IIS. Depending on your build process and security modifications to the default build, your scan should show less. Use Nmap to see what's exposed on your servers and make modifications to limit your exposure.
In this example, even if you can't disable all the listening services (perhaps because of other application requirements), you might be able to enable an ACL on the router bordering the Internet to limit traffic to ports 80 and 443. After you make changes, rescan your network and note differences.
Also consider upgrading or revising your IDS software to alert you about scans that you initiate. These alerts will assure you that your IDS software will notify you about similar scans that might target your network in the future.
Create a baseline. After you use Nmap to help lock down your network and identify sources of information that intruders might be able to access, create a baseline from these known systems and services. Communicate this baseline to others in your IT group. Then, when someone brings a new server or service online, everyone knows the importance of documenting (or registering) the server or service and updating the baseline.
Schedule Nmap. Consider scheduling Nmap to run against the network to look for anomalies. Don't limit running Nmap to your external network only; your internal network might be vulnerable to attack as well. For example, one way that CodeRed and Nimda propagate is through IIS. You can use Nmap to detect all internal IIS installations by scanning for port 80 and compiling the IP addresses of machines that might be vulnerable and need to be upgraded or patched. You can get special worm scanners that look for vulnerable machines, but the release time for specialized scanners can be longer than it takes you to scan for a service's listening port and patch the host server conventionally.
Using Nmap's Output
I sometimes prefer command-line tools to their GUI counterparts because I can include command-line tools in scripts and direct the output to a variety of devices or programs. Nmap is no exception; in fact, Nmap provides not only standard output to the console but also delimited and XML output to a file. These output options help you scan multiple subnets and aggregate data in a central reporting system or tool. Web Figure 5 shows standard Nmap output in a user-friendly format.
However, for importing to spreadsheets or parsing scripts, Nmap supports a grepable format, which Web Figure 6 shows. (Grep is a UNIX file-parsing utility similar to but more powerful than Windows' Find command.)
Best of all, Nmap's XML output provides the most flexible means of transporting the data into other applications. You can import this well-defined XML output into a database such as Microsoft Access, display it on a Web page, or open it with another XML-capable program. The XML format lends itself to baselining activities because the format facilitates comparing repeated scans. Web Figure 7 shows a Microsoft Internet Explorer (IE) display of Nmap XML output. Note the well-formed, hierarchical XML formatting that permits reliable, repeatable data collection.
Nmap: Security Scout
As with any product in the development stages, Nmap's Win32 port has known bugs and limitations. The Windows version lags behind the UNIX version in stability and features, so always refer to the latest README documents when you use a new version or run into a problem. Nevertheless, port scanning and OS fingerprinting can be important to your security program. Although patches and firewalls serve as the fortresses and defensive weaponry, consider Nmap a valuable scout to assist and recon your security position. I think that after you use Nmap, you'll keep it in your security toolkit for a long time.
End of Article
Prev. page
1
2
[3]
next page -->
