A look at nmap 4.0

February 13, 2006

This article was contributed by Jake Edge.

With its first major release in nearly 2 years, Nmap has made great strides in speed and usability. Nmap 4.00 was released on 31 January and has a very large list of features and upgrades since the 3.50 release in February 2004.

Nmap is a "network mapper" that allows a network administrator or curious user to discover many things about a network or host. Nmap will do host discovery to determine which hosts are available and port scanning to determine open ports and what services are running behind those ports. It can also try to determine which operating system is running on a target machine by examining the contents of packets and responses using a technique known as TCP/IP stack fingerprinting. One of the main uses for Nmap is security auditing a network in order to detect and possibly disable any and all unnecessary services running on a host or network.

The feature that users are most excited about, according to Fyodor, creator of Nmap, is status reporting which provides real-time information on how much progress Nmap has made and an estimated time of completion. One can get this report by pressing return while Nmap is running; other keys will increase or decrease the verbosity and debug levels or toggle packet tracing. This makes for a much nicer user experience:

With Nmap 3.50, you would start a scan and Nmap would quietly chug away for a variable amount of time (from minutes to hours) before suddenly reporting results for a target host. ... Staring at a screen for 30 minutes waiting for Nmap to complete is frustrating, but when you know the time in advance you can simply go out for lunch.

Speed and memory usage improvements in the port scanning engine were a big focus of the improvements made since 3.50. Several functions, such as reverse DNS lookup and UDP scans have been parallelized and Nmap now uses raw Ethernet packets to do ARP requests which speeds up host detection significantly. The speed improvements were not readily apparent in the relatively simple scans the author tried; they are largely geared for scanning many thousands of ports on large numbers of hosts.

Documentation was another focus of the 4.00 effort and Fyodor has rewritten the man page, an install guide, and a version detection guide. He says:

Open source software is frequently characterized as having poor documentation. I tried to fight that stereotype by putting a lot of work into Nmap 4.00 docs.

Thanks to the DAG repository, upgrading to Nmap 4.00 was painless on the (now obsolete) Fedora Core 3 distribution. Running Nmap is fairly straightforward, but there are an enormous number of options and ways to specify targets. Wading through the very comprehensive man page is required to do anything very complicated, though Nmap often seems to suggest useful options when scans fail and this feature can be very helpful.

Nmap 4.00 looks to be a very solid release of a tool that should be on every administrator's list of essential security tools.

Index entries for this article
GuestArticles	Edge, Jake

4.01 is Now Available

Posted Feb 16, 2006 6:24 UTC (Thu) by fyodor (guest, #3481) [Link] (3 responses)

I'm glad you like Nmap 4! It really has come a long way, though we certainly aren't resting on our laurels. We are now working on a 2nd generation OS detection system, and then possibly a scripting language optimized for concurrent I/O against many target ports. For more details on the release, see my SecurityFocus interview.

Nmap 4 had more than a 100,000 downloads in the first week and I'm afraid that so much testing exposed some minor bugs. 4.01 was released last week to deal with them. Grab a copy from the Nmap download page.

Cheers,
Fyodor (Enjoying LWN since the single-yellow-page days!)

4.01 is Now Available

Posted Feb 16, 2006 7:29 UTC (Thu) by Ross (guest, #4065) [Link] (1 responses)

This probably isn't the best forum to ask, but I've always wondered why nmap doesn't look at ICMP formatting for use in OS detection. Reportedly the way the original packets are quoted varies widely. Of course sometimes ICMP is blocked, but when it is not this might help disambiguate certain cases (or cases where people are using firewall rules to frustrate fingerprinting based on TCP option handling).

It already does to some degree

Posted Feb 16, 2006 7:55 UTC (Thu) by fyodor (guest, #3481) [Link]

Nmap already does look at various aspects of ICMP port unreachable replies. These tests can be seen in the "PU" fingerprint test line. Here is an example, from the Linux 2.4.7 fingerprint:

PU(DF=N%TOS=C0%IPLEN=164%RIPTL=148%RID=E%RIPCK=E%UCK=E%ULEN=134%DAT=E)

This means that in the ICMP response, the don't fragment bit was not set, the ToS byte is 0xC0, the total length (tells you how much of the original packet was echoed) is 164, the TTL is 148, the ID and IP checksum of the initial packet were returned uncorrupted, the UDP length field in the echod header was 134, and the data from that UDP packet was returned uncorrupted (but possibly truncated). More details can be found in my OS fingerprinting article.

But maybe we could glean even more information from these ICMP packets. Our current proposed new system is here, and I welcome ideas for new tests to add.

-Fyodor

Thanks

Posted Feb 19, 2006 23:42 UTC (Sun) by man_ls (guest, #15091) [Link]

Cannot resist: thanks for an invaluable tool, and keep up the good work!

A look at nmap 4.0

Posted Feb 16, 2006 14:58 UTC (Thu) by sbergman27 (guest, #10767) [Link]

Getting an idea of how long the scan is going to take is definitely a plus.

With the releases I have used, I never know if I should get up out of my chair at all, or get a cup of coffee, or make dinner, or go to the grocery store, or make a trip to Greece, while waiting for it to complete.

But thanks, Fyodor, for the tool. It has been extremely useful. And I have had enough confidence in its speed that I have not had occasion to actually see Greece yet. ;-)