Last month I started using nmap, Fyodor's network mapper, seriously. It has now displaced about four other ad-hoc tools I had been using and is, for me at least, the canonical way to find out what is on a network.
The interesting thing is that nmap is sold and discussed almost exclusively as an offensive tool — a thing attackers use to scan their targets. That is true. It is also exactly why every defender should be running it on their own networks, regularly, against their own perimeters.
The basics
nmap is a command-line tool. The simplest invocation is:
nmap 192.0.2.1This sends a connection attempt to a default selection of ports — the most commonly used ones — and reports which are open, closed, or filtered. "Open" means a service answered. "Closed" means the host responded with a refusal. "Filtered" means there was no response at all, which usually indicates a firewall.
A broader sweep across an address range, with all 65,535 TCP ports:
nmap -p1-65535 192.0.2.0/24That is a lot of probes. It takes time. It is also enormously informative.
Different scan types do different things
This is the part that took me longest to internalise. nmap supports several scan techniques, each with its own properties.
A full TCP connect scan (-sT) opens an actual connection on every port. It is reliable but very visible — the target sees a full three-way handshake to every probed port, which makes it trivial to log.
A SYN scan (-sS) sends only the initial SYN packet and reads the response. If it gets a SYN-ACK back, the port is open; nmap then sends a RST instead of completing the handshake. This is sometimes called a half-open scan. From the application's point of view there was no connection. From the kernel's point of view there was an aborted one. It is faster, and on many systems less visible to logging.
There are several more — FIN scans, XMAS scans, NULL scans — which exploit specific quirks of the TCP/IP RFCs to extract information from hosts that respond to abnormal packets in subtly different ways depending on their operating system.
The whole library is essentially a tour of the corners of the protocol stack.
Why a defender should care
I run nmap on my own perimeter weekly. Not because I expect anything to have changed, but because changes are exactly the thing I am trying to catch.
Last week's scan was identical to the previous week's. Reassuring.
The week before that, I noticed port 6000 was open on one of my hosts. Port 6000 is the default port for the X11 graphical protocol. I had installed an X server some time before — perfectly legitimately — and forgotten to firewall it off. The nmap run caught it. A weekly scan would catch a similar mistake before it had been exposed for very long.
This is the value proposition. Your firewall configuration drifts. Software you install opens ports you forgot about. Hosts get added that were never inventoried. A good vulnerability scanner, run regularly against your own network, is a kind of slow-motion alarm system.
Operating system fingerprinting
The other striking nmap feature is OS detection. The flag is -O. nmap sends a sequence of carefully chosen, slightly malformed packets and looks at the responses. Different operating systems have, over the years, made subtly different decisions about how to respond to each oddity. The pattern of those decisions, taken together, is a kind of signature.
This means that, in many cases, an attacker scanning your network can determine what operating system each host is running, even if the host itself does not advertise this anywhere. This is sobering. It means the "security through obscurity" of not telling people what you run is fragile at best.
The defensive implication: if your hosts are reachable, assume the attacker knows what they are. Plan accordingly.
A small caveat about scanning
nmap is a tool that is trivially misused. Scanning networks you do not own or have permission to scan is, in many jurisdictions, at minimum a computer misuse offence. It is also, in my experience, regarded with significant suspicion by ISPs even within their own customer base. Run it on your own networks. Get explicit written permission before running it on anyone else's. Always.
The tool is too useful to be lent recklessly.