Linux Firewalls - Michael Rash [34]
Matching Port Scans to Vulnerable Services
A port scan does not have to involve an exhaustive test for every possible port on a target system.[23] If an attacker is skilled at compromising, say, OpenSSH 3.3 and BIND 4.9 servers, then it is of little use to find out if the remaining 65,533[24] ports also have servers bound to them. Furthermore, generating a noisy scan to test all ports on a system is a good way to set off IDS alarm bells, because it is much more likely that any reasonable port scan thresholds would be tripped. As an attacker, it is better to not call unnecessary attention to oneself. To make it even more difficult for an IDS to determine the real source of a scan, an attacker can also use Nmap's decoy (-D) option. This allows a port scan to be duplicated from several spoofed source addresses, so it appears to the target system as though it is being scanned by several independent sources simultaneously. The goal is to make it harder for any security administrator who may be watching IDS alerts to work out the real source of a scan.
TCP Port Scan Techniques
Port scans of TCP ports can be accomplished using a surprising number of techniques. Each of these techniques looks slightly different on the wire as packets traverse a network, and we dedicate the next few sections (beginning with "TCP connect() Scans" and ending with "TCP Idle Scans" on page 58) to illustrating the major scanning techniques. Fortunately, the unequaled Nmap scanner (see http://www.insecure.org) has automated each of these techniques for us, and we use Nmap for all scan examples in this chapter. We launch scans against the iptablesfw system with the default iptables policy active (see Figure 3-2), and we will discuss the Nmap port-scanning techniques listed below:
TCP connect() scan—(Nmap -sT)
TCP SYN or half-open scan—(Nmap -sS)
TCP FIN, XMAS, and NULL scans—(Nmap -sF, -sX, -sN)
TCP ACK scan—(Nmap -sA)
TCP idle scan—(Nmap -sI)
UDP scan—(Nmap -sU)
In each of the following scans, the Nmap -P0 command line option is used to force Nmap to skip determining whether the iptablesfw system is up (i.e., host discovery is omitted) before sending a scan. From Nmap's perspective, each scanned port can be in one of three states:
open
There is a server bound to the port, and it is accessible.
closed
There is no server bound to the port.
filtered
There may be a server bound to the port, but attempts to communicate with it are blocked, and Nmap cannot determine if the port is open or closed.
TCP connect() Scans
When a normal client application attempts to communicate over a network to a server that is bound to a TCP port, the local TCP stack interacts with the remote stack on behalf of the client. Before any application layer data is transmitted, the two stacks must negotiate the parameters that govern the conversation that is about to take place between the client and server. This negotiation is the standard TCP three-way handshake and requires three packets, as shown in Figure 3-4.
Figure 3-4. TCP three-way handshake
The first packet, SYN (short for synchronize), is sent by the client to the server. This packet advertises the desired initial sequence number (among other things, such as the TCP window size and options such as whether Selective Acknowledgment is permissible) used for tracking data transmission across the TCP session to the server. If the SYN packet reaches an open port, the server TCP stack responds with a SYN/ACK to acknowledge the receipt of the initial sequence value from the client and to declare its own sequence number back to the client. The client receives the SYN/ACK and responds with an acknowledgment to the server. At this point, both sides have agreed on the connection parameters