Port scanning is one of the best-known penetration testing techniques, but it has some nuances that are not as well known, and we’ll be exploring some of those in this chapter. A port is a term for a TCP or UDP endpoint. Both TCP and UDP protocols use port numbers to identify sessions and services; the combination of a local IP address and port, along with a remote IP address and port, uniquely identifies a session between a client and server.
Port numbers are represented by a 16-bit value and can range from 0 through 65535. Zero has a special meaning and can’t practically be used as a port number by a server application. By convention, port numbers below 1024 are known as reserved ports, and all others are high ports or registered ports. If you ask the operating system for a new socket, the socket will end up bound to a random high port, typically ranging from 1024 through 5000. The upper limit of the range is configurable under most operating systems. Port numbers above 5000 are infrequently used, though there are common exceptions, such as an X Window listener—typically found at port 6000 TCP. Various Trojans and backdoors have also been known to use the higher ranges of port numbers. So port scanning is the act of probing a system to determine whether TCP or UDP ports are listening, are closed, or are being filtered. For a more thorough explanation of the UDP and TCP protocols, TCP/IP Illustrated, Volume 1, by W. Richard Stevens (Addison-Wesley, 1993), and Internetworking with TCP/IP, Volume 1: Principles, Protocols, and Architecture (4th Edition), by Douglas E. Comer (Prentice Hall, 2000), are excellent references.
A typical TCP port scan is also known as a connect scan because a full connection is attempted and normal protocol conventions are followed. Figure 11-1 provides a graphical look at a normal TCP connection and tear-down sequence.
There are six defined flags, represented by bits in the options field of a TCP packet:
URG. This flag indicates that the packet contains urgent data that should be processed as soon as possible. This flag is used to provide two virtual channels within one TCP connection. The URG flag is also known as out-of-band.
ACK. This flag indicates that the packet is an acknowledgement for a previous packet. It is always set for normal data flow once a connection is established. The ACK bit is also sometimes called the established bit.
PSH. This flag, or push bit, tells the operating system to transmit the data at once; the receiving end should also transmit the data to the application right away. If this flag is not set, the operating system is free to buffer TCP transmissions to optimally manage the data.
RST. This flag resets the TCP connection when an error occurs. Errors can include an incomplete initial handshake, a timeout at another phase of the connection, or a SYN sent to a port that isn’t listening or is filtering connections.
SYN. This flag sets the initial request to synchronize sequence numbers and is used to initiate a connection between two hosts.
FIN. This flag is used to gracefully disconnect an existing session, notifying the remote system that there will be no more transmissions.
A normal connection, as diagrammed in Figure 11-1, begins with the client sending a SYN packet to the server, which then responds with a SYN/ACK. The client responds to the SYN/ACK with an ACK, and data can now be exchanged in both directions. The purpose of this three-way handshake is to establish the initial sequence numbers, which help in reassembling the data stream and provide some degree of protection against spoofing attacks, depending on how randomly chosen the sequence numbers are. A normal connection scan is very safe and unlikely to cause denial of service.
Once the connection is established, the process of closing the connection starts with a FIN sent by either client or server, indicating that there is no more data to send in that direction. The recipient of the FIN packet replies with a FIN/ACK. Under ideal conditions, both client and server initiate a FIN and respond with a FIN/ACK.
Now that you understand the connection sequence, let’s look at the results from a TCP port scan and what they mean. You have three typical outcomes:
Connection accepted. The server is listening on this port, and everything works as shown in Figure 11-1. Under some conditions, a server might not want connections from your IP address but will go ahead and complete the handshake while it figures out whether it wants to talk to you. If you see a successful initial connection followed by the connection immediately dropping, this is likely what is happening.
Connection refused. Your SYN prompted an RST reply. Most of the time, a refused connection means the port is not listening at all, but some more sophisticated implementations of IP connection filtering can return an RST as well.
Timeout. Either the network is congested or your SYN packets are getting dropped by a packet-filtering mechanism, either at the host or by a router at an intermediate hop.
You can tell the difference between these three states using many common probing techniques, such as a Telnet client. A good TCP port-scanning tool will also distinguish between these three states. In Figure 11-2, a server host is protected by a router, and you attempt to conduct a penetration test to determine whether the router is protecting the server properly.
In this scenario, your first task is to perform a normal full-connect port scan. Recall that the operating system assigns a random high port to your socket—you connect like a normal client. Suppose you receive the result that port 80 (usually a Web server) is open, and all other ports tested get a timeout. You’re probably getting filtered by the router, though there is a question of whether the router is filtering us or the host. Can you now conclude that the router or firewall is correctly configured? Not yet—you don’t have enough information to decide that. Some source-port scans are in order.
In a source-port scan, you set your source port to a port that you specify, not to the random high port assigned by the operating system. At first, this approach might seem a little peculiar, but let’s say there is a business need for the server to be able to access a Web service on the Internet. Or maybe the server operator is the same person who is running the firewall, and this individual wants to read the comics from the Web server—certainly not recommended, but it does happen. The packet filtering rule to enable the server to access Web servers on the Internet might look like the following. (Router configuration languages vary; the following isn’t meant to be an actual configuration command.)
Allow internal any IP high TCP to external any IP 80 TCP Allow external any IP 80 TCP to internal any IP high TCP
This rule says that the router is going to allow TCP packets coming from any internal high port to go to any external host with a destination port of 80, and that reply packets are also allowed. So if you set your source port to 80, and proceed to scan the server, you’re now getting RST packets and finding open ports. A number of security-critical services run on high ports, such as terminal services and Microsoft SQL Server. A critical step in conducting a port scan is to also try setting the source port to commonly misconfigured ports, such as 25 (e-mail), 53 (DNS), or 80 (Web). How can you actually do anything with these services, given that most clients can’t set a source port? How should the router administrator have set the rules? It turns out that only one keyword is missing: established. The rule should look like this:
Allow internal any IP high TCP to external any IP 80 TCP Allow external any IP 80 TCP established to internal any IP high TCP
The established keyword requires that any inbound TCP packets have the ACK bit set, which prevents random outsiders from making connections to internal systems on high ports, because only the initial SYN (and FIN) packets are missing the ACK bit. If possible, it would also be a good idea to restrict the internal IP addresses that are allowed to access external Web servers. Again, you need to consult the documentation for your router to determine the exact syntax.
You can conduct port scans using custom-crafted packets with interesting combinations of the TCP flags set. Because there are six legal flags, and two more that are not defined, you could potentially send 256 different types of packets out to test a host. We’re only going to cover a few of the more commonly used combinations in this chapter. One issue to note is that although most well-known operating systems stand up well to peculiar packets being thrown at them, many network devices will malfunction when presented with packets that have illegal combinations of flags or packets that are outside of the documented TCP state machine. On several occasions Nmap (available from http://www.nmap.org) has been reported to produce denial of service conditions on devices with IP stacks that aren’t robust. Use custom TCP scans with care. A good reference on custom TCP scans can be found at http://www.totse.com/en/hack/hacking_lans_wans_networks_outdials/162024.html.
A SYN scan is also known as a half-open scan. If you have the ability to craft custom IP packets, you can perform a SYN scan. The behavior with this type of scan is that you send only a SYN packet, and then look for corresponding SYN/ACK or RST packets in response. You can see what a SYN scan looks like if you just take the top two exchanges from Figure 11-1.
The advantage is that the operating system on the other end doesn’t usually log an incomplete connection. As a result, you realize some performance gains because you can resolve a port with only two packets as opposed to the seven required to do a complete three-way handshake and a FIN and FIN/ACK in both directions. The downside is that you have to program retries to improve reliability, and on a Windows system, many of the applications that perform these scans install custom Network Driver Interface Specification (NDIS) drivers to send the custom packets. Not all these drivers perform reliably or without dropping packets. You might find that in practice, a half-open scan is much less reliable than a regular TCP port scan, depending on the software you use.
Note
Performing a scan with too many retries will result in your SYN flooding your target system. SYN floods are covered in more detail in Chapter 16.
Because you want a FIN packet to be able to reach hosts, many packet-filtering routers and firewalls allow a FIN packet through by default. Some operating systems reply to a FIN packet sent to an open port with an RST, and most reply with an RST when the port is closed. If the host you’re scanning is one that replies differently, a FIN scan can be a useful check, and it is a good choice when trying to evade intrusion detection systems (IDS).
A packet-filtering device will often allow packets through when they have the ACK bit set. Again, behavior varies from one operating system to another regardless of whether these packets are ignored or replied to with an RST. Why even bother with these weird SYN/ACK and ACK scans? You can’t directly connect to the system; if you could, a normal SYN or connect scan would work. This is a question I’ve asked as well. The answer is that if you know what is protected by a firewall or router, you know how hard you might want to work to try and find a way to get behind it.
There are actually at least two variants of XMAS scans: one sets all 8 bits in the options field and the other sets just the 6 legal bits. There are substantial differences between operating system responses to these clearly illegal packets. Many common operating systems just drop an XMAS scan packet whether the port is closed or not. A good firewall always rejects XMAS packets, and most common intrusion detection systems alert on XMAS packets. Additionally, XMAS packets can cause disruption to systems with fragile TCP/IP implementations.
In a null scan, none of the bits in the options field are set. As with XMAS scans, many operating systems just drop these packets whether the port is listening or not. Although these are less likely to cause network disruption, intrusion detection systems will normally flag null scans. Although both XMAS and null scans work when targeting some operating systems, there are other scanning techniques that work more consistently and are less likely to trigger IDS alerts.
The idle scan approach involves finding another host (the zombie) that you’d like to have your port scans recorded as coming from. The general idea is that you spoof a packet by claiming to be from another host, and when the target replies, if that reply also generates a packet from the zombie, the IP sequence number for the zombie increments. Spurious RST packets get dropped; spurious SYN/ACK packets get an RST. You can then test whether the zombie sent packets with probes. Although this approach is of academic interest, and you can be sure real attackers might use it against you, many legitimate penetration testers won’t find it to be useful.
One possible use for the idle scan would be to show people who are overly ambitious about using intrusion detection systems (IDS) to block IP addresses that launch port scans against them the error of their ways. As shown in Figure 11-3, the first step would be to locate a system that your overly ambitious admin relies on, and then launch an idle scan with the important system as a source IP. The possibilities boggle the imagination: using the IP of a workstation used by the admin as the source could be fun as well. As always, don’t do this except in well-controlled tests, because the admin needs to be able to recover quickly. If you’re interested in playing with it, the latest version of Nmap does implement idle scans.
UDP port scans pose a more difficult problem than do TCP scans because a system is not required to respond to packets sent to an open UDP port. A packet sent to a closed UDP port typically provokes an Internet Control Message Protocol (ICMP) port unreachable message, but even that isn’t guaranteed. Many operating systems put a limit on the number of port unreachable messages they will generate to a remote host in a given time period. Outbound ICMP packets might be blocked.
As with host sweeping techniques, network bandwidth is important: if you’re shoving UDP packets down the pipe faster than the port unreachable messages can get out, you’re getting false positives out of your scan. The key point to remember is that a UDP port scan can definitively tell you which ports are not listening, but you can’t be sure which ports are listening. This tends to confuse a lot of people, so it bears repeating: getting an ICMP port unreachable message is proof the port isn’t listening, but not getting an unreachable means only that it might be listening. Another caution about UDP scans is that sending unexpected data or a lack of data to a listening port might cause a denial of service. This scenario is rare, but it can happen. Figure 11-4 shows the various scenarios for a UDP port scan.
Frequently, a better approach is to understand the protocol that you expect to be running on the port in question, and then send correctly formatted packets designed to produce a response. This is a good way to positively test whether a port is listening, although one implementation of a service can respond nicely while another dies. Another caveat is that you might think a certain service is running on the port only to find that a different service is actually running. This topic is covered in more detail in Chapter 12.
Back in the days when the Internet was a much smaller and friendlier place, people used the FTP protocol to move data not just between the client and a server but between the server and a third system. Let’s look at how a typical FTP connection is made not using "passive" mode. First, the client connects to port 21 on the remote server and logs on, establishing the control channel. When a file is transferred, the client tells the server the IP address and port to connect back to (typically, your IP address and a dynamically allocated high port) and then sends the file. However, it is possible to supply an arbitrary IP address to connect back to. In this case, the FTP server attempts to connect and reports the results. The problem was first publicly noted by Hobbit, and a complete account, including links to the RFC and other references, can be found at http://www.cert.org/tech_tips/ftp_port_attacks.html.
Enough theory: how do you use the FTP bounce scan? To disguise where a port scan is coming from, you can set up an FTP server that doesn’t restrict port attacks, or you can disable this protection against a port attack. On a Microsoft FTP server, the registry entry you would modify is found at HKLMSYSTEMCurrentControlSetServicesMSFTPSVCParameters, and the value is named EnablePortAttack, appropriately enough. Set this value to 1, restart the service, and you’re now a menace. You could then use the FTP service to port scan other systems reachable by the server—some of which you might not be able to reach directly. However, if you have enough control of the system to modify service parameters and restart the FTP service, you probably have enough control to run arbitrary executables, including more ordinary port scanners. Although it would be unusual to find a system running FTP that didn’t restrict the port command to the client’s IP, some very old systems on the Internet can be vulnerable to all sorts of interesting exploits.
As is the case with network and host discovery, using the correct amount of bandwidth is very important. If you suspect that a network has a limited amount of bandwidth, start by scanning slowly, a few ports at a time. A well-written port scanner allows you to specify a list of ports, and checking only 5–10 ports that you know are important will result in a faster scan that tends to be more accurate under low-bandwidth conditions.
Although a legitimate penetration tester is rarely concerned with setting off IDS systems, sometimes part of the testing involves determining whether the intrusion detection systems are working well enough or are monitored properly.
In these cases, you might want to employ evasion techniques. A port scan that sequentially walks the ports, or attempts to connect to dozens of ports on the same system at once, will trigger even the worst intrusion detection systems. If you’d like to avoid detection, try the same port across several hosts, and then try the next port. The longer the time between connection attempts, the less noticeable you’ll be. Likewise, trying every host in sequence is a fairly obvious attack—an attack involving random ports on random hosts scanned slowly is much less likely to be noticed. To make the scans even more difficult to notice, run them from a number of different systems, optimally from different networks. All this takes a while, and all too often the operational people wouldn’t notice the network equivalent of a herd of stampeding rhinos running through the data center. You’re usually better off spending the extra time trying to find and patch vulnerabilities than playing cat and mouse with the IDS operators, unless your goal is to specifically test their responses. As discussed earlier, both idle scans and FTP bounce scans can be used to hide the source of a port scan.
An IP packet can be fragmented into more than one portion, and operating systems vary in terms of how packets are reassembled. Sometimes, you can send packets that overlap, for example, the first packet contains an IP header and a TCP header, claiming to be for port 80. This looks benign to an intrusion detection system. The second fragment starts at the TCP header and changes the destination port.
Network-based IDS systems were notoriously bad at reassembling packets, though there have been recent improvements. Using this technique, you might be able to launch a port scan or even actual attacks without being noticed. Do note that most host-based IDS systems operate above the reassembly layer and thus are not fooled by fragmentation tactics. Also, network-based IDS systems are getting better at reassembly, and some firewalls can be configured to reassemble packets prior to forwarding. A smart IDS operator will be monitoring the normalized data stream.
Additionally, fragmented packets tend to be rare in normal usage, and many systems flag fragments—especially small fragments—as an indicator of attack. Because port scan detection tends to throw a lot of false positives and can often be ignored, using fragmentation can have exactly the opposite effect you intended: your fragmented port scan sticks out as a very unusual activity, drawing more attention than a very blatant sequential port scan.
One obvious countermeasure is to use multiple layers of filtering. Using the principle of least privilege for external networks is an important concept. For example, open TCP port 80 to authorized Web servers and nothing else. This can be difficult on larger networks but should certainly be done on smaller networks. Next, filter at the host level as well. If someone can breach a system behind a router or firewall, the filters can no longer protect the host.
Plan on failures! This cannot be emphasized enough. Most people wouldn’t dream of setting up a server without a RAID disk array, and redundant power supplies are common as well. You plan on failures in many, many areas, so plan on failures from a security standpoint as well. What are the odds that the router operator never makes mistakes? Not good. What are the odds that the router manufacturer will never have a security problem? Not good, either. Configure hosts so that they remain secure even when the router or firewall fails.
Intrusion detection systems aren’t perfect, but even an imperfect intrusion detection system is correct some of the time. Especially set alerts for packets that shouldn’t be seen behind the firewall.
One excellent port scanning countermeasure is to expose services through a reverse proxy, known as publishing the server if you’re running Microsoft ISA server. In this case, only the services you want exposed are available.