Virtually every network attack requires the IP address and port number of a vulnerable host in order to function. For example, if you have an Apache exploit ready to use, you need the IP address (and possibly the port number if the server is running on a nonstandard port) of a computer running Apache. Network scanners can provide you with this information, letting you know not only what IP addresses and ports are open but also what applications are running on which port.
Even if you don't have any specific intent, running a network scanner against a host or subnet provides valuable information you couldn't gather otherwise. Modern scanners can give you a feel for an entire network topology within a handful of seconds.
Scanners also are good at determining firewall rules and other access control policies. An administrator can verify his firewall is working properly using these techniques. Similarly, an attacker can use the same tricks to find holes in firewall coverage or simply learn the firewall rules to tailor his attack.
There are a number of network scanners out there, and each supports a different feature set and operates in a slightly different fashion. That said, most network scanners follow the same basic principles.
Networked applications communicate by sending packets back and forth. Scanners can determine whether an application is running on a computer by sending a packet that should elicit a response and waiting to see what comes back. If a response is sent, the application is likely to be running.
Tip
Some applications such as PortSentry exist for the sole purpose of confusing or frustrating port scans. Additionally, firewall features like SYN-cookies can make ports appear open when they are actually closed.
Most Internet applications communicate using either the TCP or UDP protocols. Both protocols use the concept of ports to allow for multiple applications to coexist on a single IP address. Both UDP and TCP support 65,536 (216) distinct ports that applications can choose to bind to. Most applications have default ports that are used the vast majority of the time. HTTP (web) servers typically use TCP port 80. SMTP (email) servers almost always use TCP port 25. DNS servers use UDP port 53, and so on.
Tip
The file /etc/services on most Unix machines contains a mapping of common applications to their default port number. For example, the following entry lets us know that IMAP servers typically use TCP port 143:
imap 143/tcp # Internet Message Access Protocol
Network scanners determine what network applications are running on a given computer by testing TCP or UDP ports to see whether they are accepting connections. If TCP port 80 is open on a given IP address, it can be assumed that an HTTP server is running on that computer. Some scanners such as Scanrand (see the later section "Scanrand") only tell you which ports are open, while others such as Nmap (see the later section "Nmap") or Unicornscan (see the section "Unicornscan," also later in this chapter) can communicate with the application to verify its guess or even identify the version of the application running.
A simple TCP scan of the computer at IP address 1.1.1.1 might involve attempting a connection to 1.1.1.1:1, then 1.1.1.1:2, then 1.1.1.1:3, and so on, until all ports have been attempted. (In reality, modern scanners are much more sophisticated about how they perform their scanning.)
The goal of a TCP scan is to determine which TCP ports have applications listening on them. For TCP scans, no actual communication with listening applications is necessary as the TCP protocol allows you to learn what ports are open without completing a full connection. TCP connections are initiated with a three-way handshake consisting of a SYN packet, a SYN/ACK packet, and a final ACK packet. This exchange is represented in Figure 2-1.
To see whether an application is listening on a specific TCP port, a scanner can send a TCP SYN packet to that port and wait for a response. If a SYN/ACK packet is returned, then that port is considered open. If a RST packet is returned, then the port is considered closed; if no response is seen after some time, the port is considered either filtered (i.e., a firewall is blocking connections to that port) or there is no host up at that IP address. To learn about other types of TCP scans, see Different Scan Types.
UDP scanning is slightly more difficult than TCP scanning. Unlike TCP, UDP does not use handshakes, so the very first packet sent goes directly to the application. UDP applications are prone to discarding packets that they can't parse, so scanner packets are likely to never see a response if an application is listening on a given port. However, if a UDP packet is sent to a port without an application bound to it, the IP stack returns an ICMP port unreachable packet. The scanner can assume that any port that returned an ICMP error is closed, while ports that didn't return an answer are either open or filtered by a firewall.
The inability to distinguish between open and filtered ports is a weakness of simple UDP scanners that has led many people to abandon UDP scanning entirely. Unicornscan improves on this limitation by speaking valid application packets for the most common UDP protocols, which provides much more accurate results.