23 October, 2006

Hacker's friend: nmap, part one

Nmap, the network mapper is a great tool for profiling whole networks, even ones as large as the Internet. It redefines the meaning of port scanner, while having much more other uses. This part of the series will discuss nmap's general port scanning capabilities.

Port scanner


TCP scan


TCP is the most widely used protocol on the Internet, so the default scanning mode for non-root users is the TCP scan. (Root can enforce it with the “-sT” switch.) It's the most simple scanning mode, tries to open a TCP connection to the selected ports, and then reports back the results.

$ nmap localhost

Starting Nmap 4.01 ( http://www.insecure.org/nmap/ ) at 2006-10-23 00:19 CEST
Interesting ports on localhost (127.0.0.1):
(The 1671 ports scanned but not shown below are in state: closed)
PORT STATE SERVICE
22/tcp open ssh

Nmap finished: 1 IP address (1 host up) scanned in 0.275 seconds


It found port 22 open, which is the default port for ssh. There are 1671 ports which were scanned, and found to be closed, thus not reported. By default, nmap scans for only “interesting” ports, we can override this behaviour by specifying a port range or list with the “-p” command, like this:

$ nmap -sT localhost -p 1-65535

Starting Nmap 4.01 ( http://www.insecure.org/nmap/ ) at 2006-10-23 00:30 CEST
Interesting ports on localhost (127.0.0.1):
(The 65534 ports scanned but not shown below are in state: closed)
PORT STATE SERVICE
22/tcp open ssh

Nmap finished: 1 IP address (1 host up) scanned in 3.874 seconds

The closed port count went up to 65534, meaning that there are no ports open other than 22. Port ranges are denoted n-m, where n is the starting port number, m is the ending. If either side of the range is missing, 1 is assumed for starting and 65535 for ending, thus “-p 1-65535” means the same range as “-p 1-”, “-p -65535” and even “-p -”. Port lists are formed by supplying port numbers and ranges separated by commas, like this: “-p 20-25,80,443”.

As this scan use an ordinary TCP connection to find open ports, there are three possible states reported back, depending on the outcome of the TCP handshake attempt. First, the initiating machine sends a packet with the SYN (Synchronize) flag set, this indicates that it wants to connect the specified port. If the port is closed, a ACK+RST (Acknowledge, Reset) packed is sent back, these ports are reported as closed by nmap. If the port is open, the target sends a SYN+ACK packet, and the initiator machine responds it with an ACK, acknowledging the acknowledge if the SYN. As soon as this ACK arrives to the target, the handshake is completed, the connection is established, and reported as open by nmap.
The third scenario is when the SYN packet has no replies at all, these ports are reported as “filtered” by nmap. This could mean a firewall set up to drop packets without notification or a machine offline. By default, nmap makes a ping probe before every scan to make sure the target is online so it won't bang nonexistent doors. If the machine does not respond to an ordinary ping packet, the scan does not start at all. This can be overridden with the “-P0” argument in case the machine is reachable but does not respond to pings.

Stealth scan


The problem with the TCP scan is that it opens a TCP connection, so the scan might appear in the log files of the programs listening on the scanned ports, and definitely appears in firewall/IDS logs, and we might just not want that. One solution might be the use of stealth (SYN) scan, which is the default scanning mode for root users, and can be enforced with the “-sS” argument. This scan (just like other, more advanced features offered by nmap) needs to create raw packets, which is generally available for root users only.

This scan starts with a SYN packet, just like a normal TCP handshake. No replies reported back as filtered, RST ones as closed, and SYN+ACK as open. However, the scanner never replies with ACK to the SYN+ACK packets, so the connection will not be established. After some waiting for the ACK packet, the target gives up and drops the half-opened connection.

By not making any TCP connections, this scan might just stay under the radar. However, most modern firewalls and every decent intrusion detection systems (IDSs) do detect SYN scans, so there's still a good chance the scan will get noticed. The next part will discuss what measurements nmap has to reduce this chance.

UDP scan


UDP is a connectionless protocol, thus it lacks the 3-way handshake TCP has. UDP packets are sent out without any initiation, and then forgot about. There are no acknowledge of acceptance or loss, the only response an UDP packet can generate is a “Port unreachable” ICMP packet, which roughly means “don't send any more UDP packets to this port, I'm not accepting it”.

Nmap does UDP scans if the -sU argument is specified.

$ sudo nmap -sU -P0 10.0.0.138

Starting Nmap 4.01 ( http://www.insecure.org/nmap/ ) at 2006-10-23 14:14 CEST
Interesting ports on 10.0.0.138:
(The 1477 ports scanned but not shown below are in state: closed)
PORT STATE SERVICE
53/udp open|filtered domain
67/udp open|filtered dhcps
68/udp open|filtered dhcpc
161/udp open|filtered snmp
1900/udp open|filtered UPnP
MAC Address: 00:90:D0:B0:5A:6E (Thomson Telecom Belgium)

Nmap finished: 1 IP address (1 host up) scanned in 3.314 seconds


Nmap reports closed state if it got “port unreachable” response and open|filtered if there was no response to the UDP packet sent, because there are no ways to know the reason for the lack of response. Possible reasons are: 1. the port is open and the packet was accepted; 2. the firewall dropped the UDP packet, so the port can be either open or closed; 3. the packet was lost before reaching the target computer; 4. the “port unreachable” ICMP response was lost before reaching the scanning computer.
This makes the scan very unreliable. Also, the rate at which the “port unreachable” packets are generated are generally limited, so a thorough UDP scan needs to wait a lot before giving up waiting for the response, which makes the scan slow too. These and the limited number of services using UDP make this scan less than useful for most of the cases.

One thing to notice is the MAC address line. On ethernet networks, nmap reports the MAC address, and the vendor which owns the address range it's in.

Part two