Port of Entry

Without explicitly enabling firewalling, any software that opens up a port (of which there are 65,535 TCP ports and 65,535 UDP ports) is exposing itself to the outside world and is therefore vulnerable to attack. Thus, it is imperative, first, that you know which ports are open and, second, that you know whether they really should be open. Even today, in the murky world of the modern Internet, some operating systems insist on opening up ports by default on installation.

Along with a handful of other tools the Network Mapper (Nmap) [1] utility is commonly used by both system administrators and hackers alike. In this article, I will show you how to protect your server, and how to diagnose any problems with extended debugging, by looking into some of the unquestionably powerful capabilities of Nmap.

Design

The highly coveted performance Nmap exhibits is not by chance. Apparently, the tool was originally designed to scan large networks. Some other penetration testing tools you might encounter need to be left running overnight. That's hardly a realistic timeframe for checking the status of, or responding to, an urgent security issue, but comprehensive tests can take longer for obvious reasons. The fast and easy-to-use Nmap, however, gives you relatively detailed feedback with usefully speedy response times.

Popular GUI implementations of Nmap exist for various OSs and desktop environments (e.g., KNmap for KDE, which uses the Nmap front end (NmapFE)), but here I'll talk about the command-line version.

Output

In true hacker style, Nmap lists things that might pique an individual's attention by producing a tantalizing table of "interesting ports." Key to the output is whether the ports are Open, Filtered, Closed, or Unfiltered.

• A Filtered Port occurs when there's likely to be a piece of software (maybe on a hardware firewall) hindering Nmap's scanning ability. In other words, something is getting in the way of Nmap determining whether a port is open or closed.
• Closed Ports don't have any software sitting behind them listening for a connection, but of course they can be opened up by an application whenever a new process is spawned.
• An Unfiltered Port means that Nmap can't see through the fog and tell whether the port is even open or closed
• Open Ports should be self-explanatory; they're available for connection.

Worth noting is that Nmap will apparently respond with open|filtered and closed|filtered when it can't make a decision about which of the two is correct.

Sample

To avoid prosecution for attacking someone else's remote server, I'll turn to the man pages for Nmap (using man nmap) to retrieve a sample of the output it produces (Listing 1).

# nmap -A -T4 scanme.nmap.org
           Starting Nmap ( http://nmap.org )
           Interesting ports on scanme.nmap.org (64.13.134.52):
           Not shown: 994 filtered ports
           PORT    STATE  SERVICE VERSION
           22/tcp  open   ssh     OpenSSH 4.3 (protocol 2.0)
           25/tcp  closed smtp
           53/tcp  open   domain  ISC BIND 9.3.4
           70/tcp  closed gopher
           80/tcp  open   http    Apache httpd 2.2.2 ((Fedora))
           |_ HTML title: Go ahead and ScanMe!
           113/tcp closed auth
           Device type: general purpose
           Running: Linux 2.6.X
           OS details: Linux 2.6.20-1 (Fedora Core 5)
           TRACEROUTE (using port 80/tcp)
           HOP RTT   ADDRESS
           [Cut first seven hops for brevity]
           8   10.59 so-4-2-0.mpr3.pao1.us.above.net (64.125.28.142)
           9   11.00 metro0.sv.svcolo.com (208.185.168.173)
           10  9.93  scanme.nmap.org (64.13.134.52)
           Nmap done: 1 IP address (1 host up) scanned in 17.00 seconds

Whether or not you have much experience with networks and operating systems, you should see a few familiar pieces of information such as the traceroute at the foot of the output.

Starting at the top, however, look at the port output. Nmap has been clever enough even to pick up the SSH version running on port 22 (version numbers are useful for comparing with lists of known exploits). It has also found a couple of closed ports and has pulled the version number of Apache from port 80 and even the title of the website's splash page for convenience.

Ignoring the last port and moving further down, you can see that through magic (which I admit I don't fully understand), Nmap has determined the operating system on the server. Not only do you know that it's Fedora, but you've even gleaned a kernel version that is relatively terrifying if it's one that has known remote exploits: Linux 2.6.20-1 (Fedora Core 5).

What can only be described as busier output is shown in the OS detection example in Listing 2. For a myriad of reasons, Nmap can't quite be sure it has detected a Linux box (and it's guessing at 97% certainty). Cloaking your OS using a clandestine disguise is useful in deterring less sophisticated or automated attackers who need version numbers to succeed. From the list of possible operating system choices that Nmap has generated, you can get an idea of how large its impressive knowledge base is.

Warning: OSScan results may be unreliable because we could not find at least 1 open and 1 closed port
Device type: general purpose|WAP|webcam|broadband router
Running (JUST GUESSING) : Linux 2.6.X|2.4.X (97%), Asus embedded (91%), AXIS embedded (89%), AXIS Linux 2.6.X (89%), Sphairon embedded (89%)
OS fingerprint not ideal because: Missing a closed TCP port so results incomplete
Aggressive OS guesses: Linux 2.6.19 - 2.6.31 (97%), Asus WL-500gP wireless broadband router (91%), Linux 2.6.17 - 2.6.31 (91%), Linux 2.6.24 - 2.6.31 (91%), Linux 2.6.9 - 2.6.30 (91%), AXIS 207W Network Camera (89%), AXIS 207 Network Camera (Linux 2.6.16) or 241Q Video Server (89%), Linux 2.4.33 (89%), DD-WRT v23 - v24 (Linux 2.4.20 - 2.4.37) (89%), DD-WRT v24 SP1 (Linux 2.4) (89%)
No exact OS matches for host (test conditions non-ideal).

Switches

Like many pieces of software that communicate with networks, Nmap can be run in variety of ways. Nmap has become so popular that some intrusion detection software even has rules to spot its probes, firmly placing it in the white hat and hackers camps at the same time.

A multitude of command-line switches are available, so I'll start with the scan modes using the example IP address above as the target.

In terms of scanning with Nmap, you have two different modes to enable.

In the first mode, you connect with -sT, which refers to a TCP Connect scan that doesn't use raw packets but instead triggers the operating system to make a connection. The second mode – and both types appear to need root privileges, at least on my desktop – is a -sS scan referencing a SYN scan, also known as a half-open, or Stealth Scanning, which is harder for the operating system to detect. For the curious, Stealth Scanning mode sends a reset packet straight after sending a synchronize packet, which effectively closes the connection it just initiated. Nmap is determined not to show up in the logs and can manage such a task using this cloak and dagger approach in some circumstances.

There's also a very useful UDP scan switch, -sU. This important, sometimes forgotten, protocol – in terms of vulnerabilities, at least – is used throughout the Internet for services such as DNS, SNMP, and DHCP. Nmap is wise enough to let you combine several of these scans, but where possible, the Stealth Scan should be used instead of the TCP Connect scan. Obviously, running a Stealth Scan and a UDP scan concurrently can delay your results.

Another of the hackeresque qualities that Nmap can employ is randomizing its port scan numbers. It's common knowledge that less sophisticated penetration testing tools will run through incremental, sequential port scans, making probing highly predictable. By avoiding such sequences in the port numbers it connects to, you can bypass some firewall and intrusion products used on the Internet.

Scripting Engine

As well as the features included with the command line, Nmap has a mighty addition to its arsenal. The Nmap Scripting Engine (NSE) [2] means you can create scripts in the Lua language to automate tasks such as scanning very large networks and detect operating system and application version detection more precisely. A comprehensively detailed and informative chapter about the powerful scripting engine that Nmap can use is available if it's of any interest, but it's beyond the scope of this article.

Examples

Now I'll run through some useful examples. For these, I'll use the target IP address 12.34.56.78. A cautionary note to using Nmap wisely: There's a very good chance that you'll be logged attempting to connect to remote servers that don't belong to you, especially those with the more sophisticated corporate intrusion detection systems.

Snort [3], the ever-faithful Linux intrusion prevention and detection system, also logs many of Nmap's actions, so it's not limited to corporate installations. I'd go as far to say that any network admin or server admin keeping a close eye on attack patterns on their networks will be alerted to your activities, and if you don't want to face prosecution, it's probably sensible to avoid such behavior in the first place.

To start, disable ping, in case that triggers a firewall's ruleset:

# nmap -P0 12.34.56.78

Then, run the UDP and SYN (Stealth) scans concurrently, as mentioned previously:

# nmap -sUS 12.34.56.78

With the use of the -f parameter, Nmap breaks the IP packet up into small fragments if it's run in tandem with -sS, -sF, -sX, or -sN. This is a common trick to fool the remote intrusion detection system or firewall because it's significantly more difficult to fathom what type of packet is being routed through or at it:

# nmap -sSf 12.34.56.78

My personal preference for outputting results to a log is this switch:

# nmap -sS 12.34.56.78 -oN filename

If you want screeds of detail, then it's also simple just to add the verbosity switch (twice for even more detail):

# nmap -vv -sS 12.34.56.78

To truly avoid detection (in conjunction with other settings), you can even send a single packet every few minutes! The available switches for the timing parameter are paranoid, sneaky, polite, normal, aggressive, and insane, and these load a template that determines the frequency of your connections to the remote host. Some can take a very long time to complete, as you can imagine. I can't emphasize enough how important the timing can be in some scenarios; tune it to your own needs:

# nmap -sS -Tparanoid 12.34.56.78

Next, try to spoof your source IP address, but not for nefarious use,

# nmap -S 3.3.3.3 12.34.56.78

then by port range, with no pings to avoid immediate detection and with operating system detection (-A):

# nmap -P0 -p1-65535 -A 12.34.56.78

To check just a single port, you can use the -p option:

# nmap -vv -sS -p3389 12.34.56.78

Finally, you might want to use:

# nmap -vv -sS 12.34.56.78 -oN filename --log-errors

to keep an eye out for errors in an output file.

Further Reading

I have hardly even scratched the surface of Nmap's truly powerful feature set. Along with Netcat [4], Nmap has become the de facto standard that other port scanners and penetration testing tools struggle to equal. I highly recommend that you to try this magnificent tool yourself if you haven't already, and in the process, you never know: You might find a way to improve your security with its fantastic features.