Chapter 9: Active Reconnaissance Techniques - Building.Open.Source.Network.Security.Tools.Components.And.Techniques [Electronic resources] نسخه متنی

Chapter 9: Active Reconnaissance Techniques

One drawback of passive reconnaissance is that it does not enable the user to specify a request to an entity in order to elicit a specific response. The user must take whatever information is at hand, be it pertinent, relevant, or otherwise. This chapter shows how you can use active reconnaissance techniques to get much more specific information in a timely manner. We discuss a pair of popular techniques: port scanning and IP expiry.

Port Scanning

Ports are transport layer (TCP and UDP) connection points numbered from 0-65,535, where applications talk to each other across a network. A port is "open" when an application is listening on that port number; otherwise, it is "closed." Well-known network-enabled applications listen on well-known ports. For example, HTTP listens on TCP port number 80 while DNS listens on UDP port number 53. Port scanning is the act of connecting to successive numbers of ports on a destination host (target) with the intent of determining port status (and optionally, if the port is open, to determine what application is listening).

Chapters 2 and 3.

The moderately astute reader will note that DNS actually uses both UDP and TCP as a transport, depending on circumstances beyond our scope. If you are curious, read RFC 1035.

Port Scanning Considerations

While the technique of port scanning is cut and dry, several mitigating considerations are involved when determining the mechanics of how to implement the scan. They widely vary and depend on several factors, which we discuss next.

Protocol

First and foremost, you need to make a decision about which protocol to scan. Different applications, depending on their requirements, are built on top of different transport protocols. For example, e-mail and Web servers are TCP-based applications because they require assured delivery and proper sequencing of data. DNS queries, in contrast, are mostly UDP-based—favoring speed over reliability. The protocol choice largely affects the mechanics of the scan, as we will see next.

Detection and Filtering

Detection is more of a consideration for security practitioners. For example, during the execution of a typical network penetration test consulting engagement, security consultants need to enumerate applications across a series of hosts. Often, it is within the scope of the engagement to attempt to determine the level of awareness, preparedness, and vigilance of the client's information technology (IT) staff. As such, attempting to evade or test the effectiveness of network intrusion detection systems and network firewalls is an issue, and you might employ stealth methods of port scanning.

Time and Bandwidth

Time and bandwidth issues come into play when either there is a large set of hosts to be scanned or network bandwidth is limited. If the set of hosts is large, bandwidth permitting, a parallel scan multiplexed over multiple generator hosts might be employed. If the bandwidth is limited, perhaps only a subset of "interesting" ports should be scanned.

Port Scanning Mechanics

Depending on some of these concerns, one or more of the following methods should be employed. There are numerous published methods for traditional port scans, each with their own benefits and drawbacks.

Full-Open

The full-open TCP port scan, also referred to as a TCP connect scan (we will see why next), was the first widely used TCP port scanning method. The scanning host makes a TCP connection to the target on each port to be scanned. If the port is open, the TCP three-way handshake and four-way connection tear-down procedures execute. If the port is closed, the exchange consists of a much simpler two-packet exchange. Figure 9.1 illustrates both scenarios.

Figure 9.1: Full-open TCP port scan.

Full-open TCP port scans are among the easiest to codify. Most every modern operating system exports a simple interface for the application programmer to establish TCP connections to remote hosts. For example, OpenBSD (and almost every other modern operating system these days) supports the socket interface. A few simple high-level system calls are exposed, and the entire work of building and maintaining the TCP connection is the responsibility of the OS kernel. The following excerpt of code shows how to use the socket interface to implement a full-open TCP port scan.

First, we declare our local variables and set up our socket address structure with the proper address family (in this case, AF_INET or the IP protocol suite and the IP address of the target that we will scan):

int fd, n, c;
struct sockaddr_in addr;
u_short port_list[]= (22, 23, 25, 80, 6000, 0);
addr.sin_family ,= AF_INET;
addr.sin_addr.s_addr= 0x200a8c0; /* 192.168.0.2 in network byte order */

The port scanning loop itself is as follows. Individual port numbers are placed in the socket structure, with the connection process then being called repeatedly:

for (n = 0; port_list[n] != 0; n++)
{
addr.sin_port = htons(port_list[n]);

We issue a socket() system call to set up the local endpoint of the TCP connection, which returns a file descriptor referencing the client's end of the session:

fd = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP);
if (fd == -1)
{
/* error */
}

A connect() system call is issued to start a TCP session. If the port is open, the system call succeeds and returns 0. If the port is closed, the system call fails and returns -1.

c = connect(fd, (struct sockaddr *)&addr, sizeof (addr));
if (c == -1)
{
/* error */
}
else if (c == 0)
{
printf("port %d open n", port_list[n]);
}
else
{
printf("port %d closed\n", port_list[n]);
}

Because we are responsible users of finite system resources and are done with this socket, we close it down:

close(fd);
}

Ident

The Identification Protocol (Ident) as specified in RFC 1413 provides a means to determine the identity of a user of a particular TCP connection. Given a TCP port number pair, Ident returns a character string that identifies the owner of that connection on the server's system. In order to execute an Ident scan, the scanning host needs to start with a full-open scan, and the target host needs to be running Ident (on TCP port 113). When the scanning host makes the full-open TCP connection to the target host and finds an open port, it then makes a connection to the Ident server and queries the username. This process enables the scanning host to build a list of applications and their owners that are running on the target.

FTP Bounce

FTP bounce port scans, based off the FTP bounce attack, take advantage of the fact that FTP servers support a proxy feature enabling them to open connections to arbitrary hosts on arbitrary ports. These scans are also based off full-open TCP scans and afford the scanning host obfuscation of the source of the scan and potential access to filtered hosts. The source of the scan is obfuscated because it is "bounced" through the FTP server, and a direct connection between the scanning host and the target is never created. FTP bounce scans also might give the scanning host access to hosts that are not normally reachable because the FTP server itself might have unfettered access to surrounding hosts (in other words, from behind a filtering firewall). The FTP bounce scan appears in Figure 9.2.

Figure 9.2: FTP bounce prot scan.

Half-Open

Also called a "SYN scan," a half-open scan completes only the first part of the TCP three-way handshake by sending out only one packet. The scanning host sends a SYN to a port and waits for a response. If a SYN|ACK is received, the port is open. If an RST is received, the port is closed. This scanning can be a bit "quieter" than full-open scanning because the TCP layer on the scanned host never sees a full connection and therefore has nothing to log.

It should be noted that most half-open scans will result in a side-effect packet from the operating system if the port is found to be open. When the port is open on the target host, it will send back a SYN|ACK in response to the scanning machine's SYN. The scanning application will make note of this open port and then move on. However, the operating system also receives a copy of the SYN | ACK to whatever port the scanning application specified in the SYN packet. Since the operating system doesn't have any state for this connection (it didn't initiate the connection), it will send out an RST to the target host. The only way to obviate this is with prohibitive filtering or with a kernel patch.

Some literature refers to half-open scans as stealth scans, but these days this name is a misnomer. It might have been true when this method was first discovered, but it is hardly the case these days because most contemporary firewalls and NIDS can detect and act on half-open scans. A half-open port scan appears in Figure 9.3.

Figure 9.3: Half-open TCP port scan.

Writing code for a half-open scan is a bit more involved than a full-open scan, because the application programmer has to construct and send the SYN packet and then capture and process the SYN|ACK or RST packet. Fortunately, components such as libpcap and libnet make this process considerably easier. The sample code at the end of this chapter implements half-open TCP port scanning.

Parallel

When there is a large list of IP addresses to be scanned and bandwidth and detection are not issues, full-open and half-open TCP port scans can be implemented in parallel. Parallel port scans can considerably increase the area of coverage with respect to time.

UDP

UDP is a stateless protocol and has no intrinsic connection establishment procedure to misuse (as with TCP). Applications using UDP as a transport simply send properly crafted UDP packets across the network and hope that they make it there intact. Responses to arbitrary ports are application specific. As such, a UDP port-scanning tool cannot look for a specific packet to determine open port status; instead, in order to enumerate open UDP ports, the sense of scanning is reversed. The scanning host looks for explicitly closed ports and flags the rest as "open." The scanning host sends out an empty UDP datagram to the target and waits for a response. If an ICMP port unreachable packet is received, the port is assumed to be closed. If no response is received, it is thought that the application on that port attempted to process the invalid packet, resulting in it dropping the packet and sending no response (although technically, the response is undefined). At that point, the port is considered open; however, this situation does not take into account lost packets, filtering firewalls, or RFC 1812-compliant hosts. UDP scanning is a best-effort service. A UDP port scan appears in Figure 9.4.

Figure 9.4: UDP port scan.

You can write UDP scanning programs by using either the operating system native socket interface or components such as libpcap and libnet. Using the operating system native primitives can be a bit onerous due to the fact that the application programmer has to deal with two separate protocols (UDP and ICMP) and their associated operating system-dependent primitives. The sample code at the end of this chapter implements UDP port scanning via the component model.

Stealth

Stealth scans cover a few different methods that attempt to bypass filtering firewalls and logging NIDS to scan ports. Most of them take advantage of quirks or ambiguities in protocol specifications, RFCs, and protocol stacks. This situation results because all possible behaviors are not explicitly specified. Results vary across different operating systems. Examples of stealth scans include the following.

FIN

FIN scans send out a TCP packet with the FIN flag set to a port; if that port is closed, it usually sends out an RST packet. If the port is open, it usually ignores the packet. This situation prompts the FIN scanning host to set a timeout akin to UDP port scanning and to look for the ports that do not respond. The sample code at the end of the chapter implements FIN port scanning.

XMAS

XMAS scans are identical to FIN scans except that they use a TCP packet with the URG|ACK|PUSH control flags set. The sample code at the end of the chapter implements XMAS port scanning.

NULL

NULL scans are identical to FIN scans except that they use a TCP packet with no control flags set.

Fragmented IF

Fragmented IP scans, which you can use with any of these TCP or UDP scans, break down the packets into tiny IP fragments in an attempt to squeeze them past filtering firewalls and NIDS. The fragments themselves are small enough so that the TCP or UDP header information will not fit in the first fragment. The idea is that some stateless filtering and monitoring devices that filter on Layer 3 information would not be capable of applying their filters to the initial fragment and enabling all of the fragments to pass by unmolested. Most stateful devices, however, will reassemble fragmented IP datagrams before applying filtering information-rendering this scanning technique ineffective. A fragmented IP port scan appears in Figure 9.5.

Figure 9.5: Fragmented port scan.