TCP port scanning is the process of discovering TCP/IP applications at a target system, and it's a key component...
of every network security audit. While most network and security professionals are familiar with TCP port scanning, many rarely understand the details behind different port-scanning techniques and their associated applicability. This article explains the theories behind the different TCP port-scanning techniques and provides a rationale for deciding when to employ each of them.
The goal of TCP port scanning is to discover the network services offered by a target system. The idea behind TCP port scanning is relatively simple. A probe packet is sent to the target port, and based on the target system's response -- or lack of response -- one of the following states can be inferred about the target port: The port is open, closed or filtered.
An open port accepts incoming connections on that port to provide a given service. On the other hand, a closed port has no application accepting incoming connections, and it thereby rejects possible connection requests. Finally, if some type of packet-filtering device is configured to drop packets sent to the target port, the port is in the filtered state -- it is usually not possible to determine whether the port is open or closed.
In order to understand TCP port-scanning techniques, one has to understand a key mechanism of the known Transmission Control Protocol: the TCP connection establishment mechanism. There are two main scenarios for the TCP connection establishment, which can be depicted as follows:
In the first open port scenario, an application -- in Host B -- listens for incoming connections on the given port. The port is thus considered open -- or, more specifically, in the TCP LISTEN state. Upon receipt of an incoming connection request -- a SYN, or synchronization, packet -- the target system (Host B) responds with a SYN/ACK, or synchronization acknowledgement, packet. Once Host A -- i.e., the host that issued the connection request -- responds with an ACK packet, the connection is established on both sides.
In the second scenario, there is no application listening for incoming connections on the given port at Host B. Therefore, the port is said to be closed, or in the TCP CLOSED state. Upon receipt of an incoming connection request, the target system (Host B) will reject the connection request with a RST, or reset, packet.
The use of packet filtering introduces a third possible scenario, in which packets sent to a target node are simply dropped either at some intermediate system or at the target system itself; as a result, the target system never responds. Since the target system doesn't respond when the port is probed, the port is said to be filtered. In some cases, packet-filtering devices may be configured to signal the packet drops with Internet Control Message Protocol error messages.
Filtered ports have two associated considerations. First, when a probe packet doesn't receive a response, it is not possible to conclude whether the port is actually filtered or if the probe packet was simply dropped -- e.g., as a result of network congestion. Secondly, even if it can be assumed no packets are dropped due to network congestion, one has to wait for a longer period of time than in open and closed cases in order to infer the port is being filtered. Essentially, in the former two cases, there is a positive response that clearly indicates the state of the port; whereas in a filtered port scenario, one has to wait longer to make sure no response is received from the target system.
The connect() scan
The most basic TCP port-scanning technique is known as the TCP connect() scan. In this scan, the scanning tool simply tries to establish a normal TCP connection with the target port, employing the normal function and system calls. The amount of time required for this technique to obtain a target port result is roughly as follows:
- In an open or closed state: 1 * Round Trip Time -- that is, the tool must wait for the SYN packet to reach the target node and for the SYN/ACK or RST packets to be received in response to the connection-establishment attempt.
- In a filtered state: Typically, at least 75 seconds. This is an implementation-dependent amount of time, after which the connection request times out. However, a scanning tool may be able to reduce this timeout value.
Another important aspect associated with the TCP connect() scan is, since the local TCP/IP stack -- typically in the operating system kernel -- is employed to handle the connection-establishment attempts, each scanned port results in system resources tied for the corresponding TCP connection. This includes, among others, an entry in the list of ongoing connections, which can eventually limit the maximum number of ports that can be simultaneously scanned at any given time.
Also noteworthy, in the case of an open port, the TCP connection is fully established. This means a monitoring device -- like an intrusion detection system -- could isolate the IP address of the scanning node and deduce it has not been forged or spoofed. This could be undesirable if the TCP port scan is actually the result of malicious activity.
The TCP connect() scan can be invoked with Nmap as follows:
# nmap -sT example.com
The SYN scan
When performing a TCP port scan, it should be evident there is no interest in actually establishing a connection with the target system. Instead, the intent is to obtain a response, or no response, to the probe packet -- typically a SYN packet. Thus, TCP scanning tools typically implement the so-called SYN scan. In a SYN scan, the probe packet is a crafted SYN packet sent by the scanning tool, rather than by the underlying TCP implementation. This method has a number of advantages, including:
- Scanning a TCP port does not necessarily tie local resources to the scanned ports -- e.g., the operating system kernel does not become aware of the connection-establishment attempt.
- Since, even in the case of open ports, the TCP connections are never fully established, the scanned node cannot tell whether the source address of the probe packets has been forged or spoofed. This is particularly the case when decoy traffic -- i.e., forged traffic to conceal the real scanning traffic -- is employed, as with Nmap's "-D" option.
- It typically results in fewer packets, since the established connections resulting from open ports don't need to be closed or aborted.
Because this technique requires the scanning tool to craft the TCP packets, superuser privileges are typically required. However, this is not a challenge nowadays, because users usually have full control of the system they employ.
To perform a SYN scan with Nmap, plug in the following:
# nmap -sS example.com
The FIN, NULL and XMAS scans
The TCP specification covers the processing rules of packets for all possible scenarios, including some that, while theoretically possible, rarely happen in practice. Some of these scenarios can be triggered and leveraged for TCP port-scanning purposes. For example, the TCP specification states when an incoming TCP packet is received without the ACK bit set, and the packet is not a SYN or RST, the host must react as follows:
- If the port is closed -- i.e., TCP CLOSED state -- a RST segment should be sent in response.
- If the port is open -- i.e., TCP LISTEN state -- the incoming packet should be silently dropped.
Since a given packet can result in two different responses, depending on the state the corresponding port is in, the aforementioned packets can be leveraged for the purpose of TCP port scanning. Any packet that doesn't have the ACK bit set -- and is not a SYN or RST packet -- could be leveraged to elicit one of the two possible behaviors described above. When the probe packet doesn't have any TCP flags set, the scanning technique is considered a TCP NULL scan. When the probe packet has only the FIN, or finish, bit set, the technique is referred to as a TCP FIN scan. And when only the FIN, PSH (push) and URG (urgent) bits are set in the probe packet, the technique is said to be a XMAS scan. While the scanning technique names vary depending on which flags are set in the TCP probe packet, all three techniques leverage the same TCP processing rules.
One possible advantage of these techniques when compared to the connect or SYN scans is they allow the port scan to work even when a filtering device prevents incoming connections by dropping SYN packets. As with the SYN scan, a target node cannot assume the received probe packets have a forged source address or not -- particularly when decoy traffic is employed.
On the other hand, a possible shortcoming of these techniques is the incorrect interpretation of ports. For example, since one of the two possible outcomes for a scanned port is a dropped probe packet for an open port, a dropped packet resulting from network congestion -- or other reasons -- may be incorrectly interpreted as a corresponding open port. Additionally, in order to detect a packet drop, the scanning tool would typically need to wait for a longer period of time than if a positive answer were received to indicate an open port.
Because these scanning techniques require the scanning tool to send crafted TCP packets, the scanning tool will typically need to run with superuser privileges. However, as already noted for the SYN scan, this typically doesn't present a challenge.
Using Nmap, the FIN scan can be invoked as follows:
# nmap -sF example.com
The NULL and XMAS scans can be invoked with the "-sN" and "-sX", respectively, instead of the "-sF" option used to indicate a FIN scan.
The ACK scan
The ACK scan is not really a port-scanning technique, but rather a technique aimed at determining whether a given port is filtered or not. When a packet with only the ACK bit is sent to a target port, there are two possible outcomes, depending on whether the port is filtered or not:
- Unfiltered -- i.e., the port is open or closed. An RST packet is sent in response to the probe packet.
- Filtered. No response is sent in response to the probe packet.
Typically, when connections to a given port are prohibited by dropping incoming SYN packets, they are dropped silently, whether the port is open or closed. However, ACK packets will still elicit a response and help determine the type of packet filtering that is preventing incoming connection requests.
As with the other scanning techniques that involve crafted TCP probe packets, the identity of the scanning node can be easily concealed, particularly when decoy traffic is employed -- as with Nmap's "-D" option -- during the port scan.
Finally, since the ACK scan requires the scanning tool to send crafted TCP packets, the tool will typically have to run with superuser privileges. Once again, however, this rarely creates a problem.
To run an ACK scan using Nmap, plug in the following:
# nmap -sA example.com
While most networking and security professionals are familiar with TCP port scanning, the details behind different port-scanning techniques and their associated applicability are rarely understood. This article has explained the theory behind each of the different TCP port-scanning techniques, so networking and security professionals can identify and leverage the scanning techniques that better suit their needs for different scenarios. While all the examples in this article employ Nmap, they are all implemented in any popular scanning tools -- including the scan6 tool of SI6 Networks' IPv6 Toolkit.
Optimizing TCP traffic across the WAN
Why TCP traffic spikes should sound an alarm
New security considerations in era of NFV