Many would agree that Nmap is probably the best network scanner available today. It’s incredibly versatile, allowing users to perform the most basic of scans, right up to its very own scripting engine which allows results to be parsed in almost infinite ways. There’s really no need to purchase anything else, since Nmap is, and always has been completely free.
Few applications get free air time in the movies – but you’ve probably seen Nmap in films such as The Matrix, and Die Hard 4 – it’s widely considered a must having hacking tool.
So apart from giving John McClane a headache, what typical uses does Nmap have? This article explains why Nmap is a vital tool for network administrators, security specialists, and even the hacking underworld, it’s a tool that can easily be used for good or evil, and how you use it is entirely up to you. But either way, I think you’ll appreciate how adaptive Nmap is.
Surely Ping is enough…
Forgive me, but it’s worth mentioning. It’s a common misconception that Ping does exactly the same tasks as Nmap – this couldn’t be further from the truth. Ping is a type of host discovery scan. It can only tell you if a device is online or not. ICMP can only take you so far, though a vital network troubleshooting tool, it’s incredibly limited to a simple ‘yes\no’ response. Sometimes this is enough – but when you want more, you have to go beyond Ping.
Once you see just how much Nmap is capable of, you’ll realize how simple Ping really is.
Nmap is the Swiss army knife of network reconnaissance tools. It’s designed to be as fast, efficient, stealthy and as simple to use as possible, though admittedly simplicity does escape its more ‘intimate’ features. It’s well maintained, and well documented, meaning learning the many parameter switches takes practice, but pays off.
Like Ping – Nmap starts at the bottom of the stack. It discovers hosts, advises weather they are online, performs scans of the ports, determining which are listening, and which are clearly locked down, it can then use responses from listening ports to guess the services running on those ports, usually right down to the specific version. It can also attempt to determine the underlying operating system, and even check for known exploits within the services it finds.
Network scanners typically have a bad reputation for being intrusive, flooding applications which ruin network performance and trigger every IDS (intrusion detection system) known to man – Nmap separates itself from the masses by implementing multiple scanning techniques designed to be as sensitive as possible.
So why do we use scanners? It’s an easy way to audit an unfamiliar network, whether it is for security auditing, simple discovery of services or just for plain old curiosity. Naturally I don’t advise scanning networks you don’t maintain, as Nmap allows you to scan absolutely everything – in depth!
Nmap is maintained by the good folks over at seclists.org, though it usually comes with most Linux distributions as a downloadable package. Chances are you may already have it, in which case you can simply execute ‘nmap’ on your shell. Without any parameters, Nmap prints the (rather large) usage instructions.
If you don’t have Nmap, check your distribution for an installation package (Ubuntu, Debian etc all have an Nmap build, this can be obtained using ‘apt-get install nmap’).
There’s a Windows version too, but as usual, Nmap isn’t particularly targeted for Windows, and therefore may function differently. This article assumes Nmap on Linux is in use.
Downloads, documentation and support are all over at http://nmap.org/. We recommend you try Nmap out on Linux – using its native command line interface. There is a GUI available for Nmap (called Zenmap), if you prefer.
A First Look
As mentioned, Nmap shows you all the possible switches you can provide it with when executed without any parameters. Don’t worry about all of them now, as chances are you’ll only ever use a handful of common switches anyway. That’s what I aim to cover – common scanning methods used in everyday networking.
I find it easy to place Nmap scans into two obvious categories; host discovery, and host scans. Scans are usually preceded by host discovery, meaning you can discover, discover and scan, or just scan – it’s entirely configurable.
Let’s start by doing some host discovery, and basically using Nmap as a glorified Ping:
$ nmap -sP 192.168.1.0/24 Host 192.168.1.1 is up (0.019s latency). Host 192.168.1.99 is up (0.018s latency). Host 192.168.1.100 is up (0.000087s latency). Host 192.168.1.254 is up (0.0020s latency). Nmap done: 256 IP addresses (4 hosts up) scanned in 2.59 seconds
Like Ping, Nmap tells us which hosts are up – the main difference being that we provided Nmap with an entire class C subnet to scan. Instead of running multiple Pings, we now know how many devices are online on our network.
This type of scan actually performs a little more than the usual Ping. It uses ARP, and considers a response ‘up’, but depending on the privilege of the user running the scan – will also attempt some basic connections to those hosts that are online, specifically on port 80 and 443.
The Ping scan is the most common discovery method. In fact, most of the host scanning methods begin with a Ping scan to ensure you’re scanning a host that’s up – though this can be disabled with the -PN switch.
But Nmap is all about host discovery, and that’s where its strengths lie. So let’s take a closer look at the host we’ve discovered:
$ nmap -sS 192.168.1.1 Starting Nmap 5.00 ( http://nmap.org ) at 2011-11-01 17:03 GMT Interesting ports on 192.168.1.1: Not shown: 981 closed ports PORT STATE SERVICE 7/tcp open echo 9/tcp open discard 13/tcp open daytime 17/tcp open qotd 19/tcp open chargen 80/tcp open http 135/tcp open msrpc 139/tcp open netbios-ssn 445/tcp open microsoft-ds 902/tcp open iss-realsecure 912/tcp open unknown 2967/tcp open symantec-av 3389/tcp open ms-term-serv 8009/tcp open ajp13 8081/tcp open blackice-icecap 8082/tcp open blackice-alerts 8222/tcp open unknown 8333/tcp open unknown 9081/tcp open unknown MAC Address: 00:1D:09:99:9C:D4 (Dell) Nmap done: 1 IP address (1 host up) scanned in 1.33 seconds
This scan produces some more detailed results for us. We specify -sS to probe the client IP with a TCP SYN scan, Nmap provides us with a list of ports which responded, as well as their default service name.
Note that in order to use the TCP SYN scan, your OS must support it and you may require administrative privileges.
The stealth scan is the most common and favourable scan type. If your OS doesn’t support it (or you don’t have the require privileges) you can use -sT, which provides the same results, but may alert IDS sensors, since Nmap will open a full TCP session for each port it scans.
Honing Your Scan
The beauty of Nmap is that is allows you to broadly scan thousands of targets, or intensely scan an individual host, or a combination of both – the scans above are very basic, let’s focus on an individual host and learn all we can about it. We’ll introduce some new switches, too.
$ nmap -sS -A 192.168.1.1 Starting Nmap 5.00 ( http://nmap.org ) at 2011-11-01 15:56 GMT Interesting ports on 192.168.1.1: Not shown: 981 closed ports PORT STATE SERVICE VERSION 7/tcp open echo 9/tcp open discard? 13/tcp open daytime Microsoft Windows International daytime 17/tcp open qotd Windows qotd 19/tcp open chargen 80/tcp open http Apache httpd 2.2.17 ((Win32)) |_ html-title: Index of / 135/tcp open msrpc Microsoft Windows RPC 139/tcp open netbios-ssn 445/tcp open microsoft-ds Microsoft Windows XP microsoft-ds 902/tcp open ssl/vmware-auth VMware Authentication Daemon 1.10 (Uses VNC, SOAP) 912/tcp open vmware-auth VMware Authentication Daemon 1.0 (Uses VNC, SOAP) 2967/tcp open symantec-av? 3389/tcp open microsoft-rdp Microsoft Terminal Service 8009/tcp open ajp13? 8081/tcp open blackice-icecap? 8082/tcp open ssl/blackice-alerts? |_ sslv2: server still supports SSLv2 8222/tcp open http VMware Server 2 http config |_ html-title: VMware Server 2 8333/tcp open ssl/http VMware Server 2 http config |_ html-title: VMware Server 2 MAC Address: 00:1D:09:99:9C:D4 (Dell) Device type: general purpose Running: Microsoft Windows XP OS details: Microsoft Windows XP SP2 or SP3, or Windows Server 2003 Network Distance: 1 hop Service Info: OS: Windows Host script results: |_ nbstat: NetBIOS name: XP-BOX1, NetBIOS user: , NetBIOS MAC: 00:1d:09:99:9c:d4 | smb-os-discovery: Windows XP | LAN Manager: Windows 2000 LAN Manager | Name: WORKGROUP\XP-BOX1 |_ System time: 2011-11-01 15:58:39 UTC+0 OS and Service detection performed. Please report any incorrect results at http: //nmap.org/submit/ Nmap done: 1 IP address (1 host up) scanned in 123.52 seconds
Here, we’ve added the -a switch. This switch effectively turns on many other options, notably:
- OS detection (-O)
- Version detection (-sV)
- Script scanning (–script=default or -sC)
- Traceroute (–traceroute)
Not really considered a ‘polite’ scan, this provides us with as much detail as Nmap can find. You can narrow down the results using a combination of the switches above.
A scanner such as Nmap won’t be much use if you don’t know the different port states. There are several that Nmap can report on, but you’ll likely come across three popular ones; closed, open and filtered.
$ nmap -sS -p1234 10.91.15.1 Starting Nmap 5.00 ( http://nmap.org ) at 2011-11-07 11:04 GMT Interesting ports on 10.91.15.1: PORT STATE SERVICE 1234/tcp closed hotline MAC Address: 00:1D:09:99:1A:F1 (Dell) Nmap done: 1 IP address (1 host up) scanned in 0.30 seconds
In the above scan, I’ve used the -p switch to focus on one specific port. You can focus on as many as you like, by adding more ports separated by a comma, e.g. -p21,445,8080.
We know there is nothing listening on that port (1234 isn’t a particular popular port), so the operating system simply returns a TCP RST packet. This tells Nmap there is no service there, or that it’s not running. It does however tell us the host is up. As a result – the port is considered closed.
$ nmap -sS -p80 10.91.15.1 Starting Nmap 5.00 ( http://nmap.org ) at 2011-11-07 11:04 GMT Interesting ports on 10.91.15.1: PORT STATE SERVICE 80/tcp open http MAC Address: 00:1D:09:99:1A:F1 (Dell) Nmap done: 1 IP address (1 host up) scanned in 0.30 seconds
Running the same scan with a port of 80 indicates that there is a service up and running and listening on that port. Hence the port is open.
$ nmap -sS -p445 10.91.15.1 Starting Nmap 5.00 ( http://nmap.org ) at 2011-11-07 11:10 GMT Interesting ports on 10.91.15.1: PORT STATE SERVICE 445/tcp filtered microsoft-ds MAC Address: 00:1D:09:99:1A:F1 (Dell) Nmap done: 1 IP address (1 host up) scanned in 0.30 seconds
Here we scan port 445 – the common port for CIFS file sharing. I’ve enabled the Windows Firewall (and removed the file sharing exception), resulting in the firewall blocking all file sharing. Nmap reports this as filtered. At the TCP level, this occurs when the client doesn’t respond to the port (the firewall simply drops the incoming SYN packet). But how does Nmap know that the client isn’t just genuinely unavailable?
Nmap performs its own ‘probes’ to confirm if a host is really up. This helps it distinguish from a filtered port, and a non-existent ant host. Probes can be disabled with -PN if you suspect the host is hiding, or you really know it’s online.
One of the most powerful and clever features of Nmap is the built in scripting support which allows you to run all results against your own tests. There is a handful of default scripts included, which vary in purpose, they can usually be found in the /opt/share/nmap/scripts folder.
$ nmap -sS --script=smb-security-mode.nse 10.91.15.1 Starting Nmap 5.00 ( http://nmap.org ) at 2011-11-07 11:53 GMT Interesting ports on 10.91.15.1: Not shown: 981 closed ports PORT STATE SERVICE 80/tcp open http MAC Address: 00:1D:09:99:1A:F1 (Dell) Host script results: | smb-security-mode: User-level authentication | SMB Security: Challenge/response passwords supported |_ SMB Security: Message signing not supported Nmap done: 1 IP address (1 host up) scanned in 1.31 seconds
In this scan, I’ve used the script ‘smb-security-scan’ which attempts to identify the security methods supported by the device. Included in our results are the script results – a list of the supported authentication methods.
There are many powerful scripts included, aimed at simple service detection to full on vulnerability exploitation. They can be quite intrusive and also somewhat unstable, so should be used with caution (you don’t want to crash the machine you’re scanning!)