Nmap Port Scanning « Handy Weblog

Nmap is by far the most popular port scanner available. You can download it from http://www.insecure.org/, and it compiles and installs in a breeze on most Windows and Unix operating systems including Mac OS X (via configure, make, make install). You can download Windows binaries (along with the required Winpcap) from http://www.insecure.org/. A graphical Windows frontend for nmap is available at http://www.nmapwin.org/. For this discussion, we’ll use the Unix nmap version 3.48.

Implementation

One reason why nmap is so useful is that it offers many different scanning techniques from which you can choose. You can scan for hosts that are up, TCP ports, UDP ports, and even other IP protocols. Because we’ll be talking in detail about how nmap performs some of its TCP scans, you’ll need to know a little bit about how TCP connections are made. Table 4-1 shows definitions for common TCP flags that are involved in TCP connections.

When a TCP connection is made to a port, the client sends a TCP packet with the SYN flag set to initiate the connection. If a server is listening on that port, it sends a packet with both the SYN and ACK flags set, acknowledging the client’s request to connect while asking to make a return connection. The client will then send a packet with the ACK flag set to acknowledge the server’s SYN. This is referred to as the TCP three-way handshake. When one side is done talking to the other, it will send a FIN packet. The other side will acknowledge that FIN and send a FIN of its own, waiting for the other side to acknowledge before the connection is truly closed. A RST packet can be sent by either side at any time to abort the connection. A sample TCP conversation between a client and server is shown here:

Client sends SYN to Server: “I want to connect.”
Server sends SYN/ACK to Client: “Okay; I need to connect to you.”
Client sends ACK to Server: “Okay.”
Client and Server send information back and forth, acknowledging each other’s transmissions with ACKs. If either side sends a RST, the connection aborts immediately.
Client has finished the conversation; Client sends FIN to Server: “Goodbye.”
Server sends ACK to Client (acknowledging Client’s FIN). Server then sends a separate FIN to Client: “Okay. Goodbye.”
Client sends ACK to Server (acknowledging Server’s FIN): “Okay.”

Keep this information in mind while reading through the next few sections. It will help you to get a better grasp on how nmap and other port scanners get their information.

Scanning for Hosts

If you care only about determining which hosts on a network are up, you can use the Ping scanning method (-sP). It works similarly to fping (see Chapter 14) in that it sends Internet Control Message Protocol (ICMP) echo requests to the specified range of IP addresses and awaits a response. However, many hosts these days block ICMP requests. In this case, nmap will attempt to make a TCP connection to port 80 (by default) on the host. If it receives anything (either a SYN/ACK or a RST), the host is up. If it receives nothing at all, the host is assumed to be down or not currently on the network. If you want only a list of hostnames for the IP range you’ve specified, try a list scan (-sL).

Scanning for TCP Ports

The basic method of TCP port scanning is to do a TCP connect() (-sT) to a port to see whether anything responds. This is the same thing any TCP client would do to make a connection (complete the three-way handshake), except nmap will disconnect by sending a RST packet as soon as the handshake is complete. If you want to, you can use an RPC scan (-sR) to scan every open port for RPC services (that is, a portmapper). Following are some examples of these types of scans:

[bjohnson@originix ~]$ nmap -sT 192.168.1.109

Starting nmap 3.48 ( http://www.insecure.org/nmap/ ) at 2003-10-08 16:17 EDT
Interesting ports on cauliflower (192.168.1.109):
(The 1639 ports scanned but not shown below are in state: closed)
Port       State       Service
22/tcp     open        ssh
111/tcp    open        sunrpc
884/tcp    open        unknown
889/tcp    open        unknown
6000/tcp   open        X11

Nmap run completed -- 1 IP address (1 host up) scanned in 0.587 seconds
[bjohnson@originix ~]$ nmap -sR 192.168.1.109

Starting nmap 3.48 ( http://www.insecure.org/nmap/ ) at 2003-10-08 16:18 EDT
Interesting ports on cauliflower (192.168.1.109):
(The 1639 ports scanned but not shown below are in state: closed)
Port       State       Service (RPC)
22/tcp     open        ssh
111/tcp    open        sunrpc (rpcbind V2)
884/tcp    open        (mountd V1-2)
889/tcp    open        (mountd V1-2)
6000/tcp   open        X11

Nmap run completed -- 1 IP address (1 host up) scanned in 3.320 seconds

Notice how the –sR scan uses remote procedure call (RPC) commands on the open ports to determine whether they are RPC services. Nmap discovers the types and version numbers of the rpcbind and mountd services running on cauliflower.

This is great, but since you’re just making basic TCP connections, your connection most likely gets logged by the service that answers. Sometimes you want to be a bit quieter.

Nmap lets you do some sneaky things with the TCP packets you use for port scanning. First, there’s the SYN scan (-sS), which makes the first part of the TCP connection (sending a TCP packet with the SYN flag set) but then behaves a bit differently. If it receives a TCP packet with the RST flag set (a reset packet), nmap assumes the port is closed and nothing more is done. However, if it receives a response (indicated by a packet with the SYN/ACK flag set), instead of acknowledging that packet like a normal connection would, it sends a RST packet, as shown in the next table. Since the TCP three-way handshake is never completed, many services will not log the connection. Because you have to manipulate some of these TCP flags at a lower level, you can’t perform this kind of scan without root access to your system.

Although services might not log these “incomplete” connections, some firewalls and intrusion-detection systems (IDSs) will be on the lookout for this kind of scan. Nmap has even sneakier scans for you to try, although a good IDS might still pick you up. Additionally, a firewall may filter out the sneaky packets and skew the scan results.

You should have already noticed that anytime you send TCP packets to a closed port, the TCP/IP stack on the other side is supposed to respond with a RST packet. So why even bother sending a legitimate TCP packet? If a closed port on a host will always respond with a RST, why not just send some garbage packets that make no sense and see what you get back?

The FIN scan (-sF) sends a FIN packet, which is normally used legitimately to close a connection. However, because we’re sending it before a connection has even been established, open ports should just ignore this garbage. Closed ports will still respond with a RST, as shown in the following table. Nmap offers two other garbage scans: the Xmas tree (-sX) scan (which sets the FIN, URG, and PUSH flags of a TCP packet, lighting it up like a Christmas tree) and the null (-sN) scan (which turns off all the flags). Because we’re doing some low-level packet mangling, these scans also require root privileges. Keep in mind that not all TCP/IP stacks are implemented correctly. Even though open ports are not supposed to send RST packets in response to these types of probes, some operating systems’ TCP/IP stacks don’t follow the specs and do this anyway. This means that you might get false positives with this scan on certain hosts. Also, any host that is protected by a firewall may return false positives. Nmap is assuming that the port is open if it receives nothing in response. What if a firewall is blocking that response? These scans are stealthier, but they’re also a lot less accurate.

Sometimes nmap will tell you that a port is filtered. This means that a firewall or port filter is interfering with nmap’s ability to determine accurately whether the port is open or closed. Some firewalls, however, will filter only on incoming connections (that is, looking only for incoming SYN packets to a particular port). When you want to test the rules on a firewall, run an ACK scan against a host behind that firewall. Whenever an ACK (acknowledgement) packet is sent that is not part of an existing connection, the receiving side is supposed to respond by sending a RST. The ACK scan (-sA) can use this fact to determine whether or not a port is being filtered or blocked. If a RST is received, the port is unfiltered; otherwise, it’s filtered, as shown in the next table. The ACK scan can tell you exactly what firewall rules are protecting a particular host.

Because this scan doesn’t tell you about ports that are actually open or closed, you might want to try a different scan in combination with the ACK scan. For example, you can use the ACK scan in combination with the SYN scan (-sS) to determine whether a host is being protected by a firewall that blocks only initial incoming connections (SYN flags). In the following example, a SYN scan reveals only port 80 open on 192.168.1.40. It also tells us that ports 21 and 22 are filtered and nmap can’t determine their state. An ACK scan tells us that all ports on 192.168.1.40 are unfiltered, even though the SYN scan told us they were filtered! This means ports 21 and 22 on 192.168.1.40 are being filtered by a stateless firewall; although the SYN is blocked, the ACK is able to pass through. An example of a stateless firewall is ipchains, which we’ll discuss in Chapter 13.

# nmap -sS 192.168.1.40

Starting nmap 3.48 ( http://www.insecure.org/nmap/ ) at 2003-10-08 16:22 EDT
Interesting ports on  (192.168.1.40):
(The 1641 ports scanned but not shown below are in state: closed)
Port       State       Service
21/tcp     filtered    ftp
22/tcp     filtered    ssh
80/tcp     open        http

Nmap run completed -- 1 IP address (1 host up) scanned in 4.321 seconds
# nmap -sA 192.168.1.40

Starting nmap 3.48 ( http://www.insecure.org/nmap/ ) at 2003-10-08 16:22 EDT
All 1644 scanned ports on  (192.168.1.40) are: UNfiltered

Nmap run completed -- 1 IP address (1 host up) scanned in 4.660 seconds

Scanning for UDP Ports

Yep, of course nmap can do this, too. The –sU option sends empty UDP packets and waits to receive ICMP “port unreachable” messages in return. If no messages are received, the port is assumed to be open, as shown in the next table. You can see some flaws in this. If return ICMP messages are being blocked by a firewall, it will appear that all UDP ports on the host are open. Also, if the UDP traffic itself is being blocked by a firewall, it will still appear that the UDP ports are open. This is the same pitfall we saw in Netcat with UDP port scanning. Additionally, many hosts will send out only a certain number of ICMP error messages per second to avoid network saturation. Nmap will automatically adjust its scan rate when this is detected, but this can greatly slow down your UDP scans. Since UDP is a connectionless protocol and not bound to acknowledge receipt of incoming packets, there’s no good way around this problem.

Handy Weblog