Port-scanning tools are like the tools of any other trade. As an example, consider working on you car at home. You may pull out a hammer, pliers, screwdriver, and even some duct tape to try to fix a problem. If you compare that to a dealership that has a crew of trained mechanics, you will see that they have many tools and specialized devices to fix problems. Advanced port-scanning tools work in much the same way. Whereas today, as you initially work your way through the book, you may not need these tools, as your proficiency increases you will want to try out these techniques. Some advanced scan types include the following:
FTP bounce scan— Uses an FTP server to bounce packets off of and make the scan harder to trace
RPC scan— Attempts to determine whether open ports are RPC ports Window scan— Similar to an ACK scan but can sometimes determine open ports
Idle scan— Uses an idle host to bounce packets off of and make the scan harder to trace
Let’s look at the idle scan in more detail to see how one of the advanced methods actually works.
Idle Scan
Earlier in the chapter, I discussed the IP header. Remember that the IP header is responsible for fragmentation. During the fragmentation process, one of the ways that IP is able to reassemble the fragments is to look at the IDs of each fragment to see whether they go together. This field of the IP header is
actually known as the Internet Protocol identification number (IPID). Some systems randomly create an IPID or set the value to zero; however, the major-ity of operating systems increment this value by one for each sent packet.
The IPID is a 16-bit value. It is used to differentiate IP packets should frag-mentation occur. Without the IPID field, a receiving system would not be able to reassemble two or more packets that had been fragmented at the same time.
Before going through an example of idle scanning, let’s look at some basics on how TCP connections operate. Because TCP is a reliable service, it must perform a handshake before communication can begin. The initializing party of the handshake sends a SYN packet to which the receiving party will return a SYN/ACK packet if the port is open. For closed ports, the receiving party will return an RST. The RST acts as a notice that something is wrong and further attempts to communicate should be discontinued. RSTs are not replied to; if they were, we might have the situation in which two systems would flood each other with a stream of RSTs. This means that unsolicited RSTs are ignored. By combining these characteristics with IPID behavior, a successful idle scan is possible. Figure 4-7 shows an idle scan of an open port.
Step 1 - Idenfity IPID Step 2 - Scan Open Port
IPID Probe
Step 3 - Acquire Results
IPID Probe
IPID Response IPID = 12347
Victim
Attacker Idle Host
Figure 4-7 Idle scan of an open port.
Step 1 - Idenfity IPID
Step 2 - Scan Closed Port
IPID Probe
Step 3 - Acquire Results
IPID Probe
IPID Response IPID = 12346
Victim
Attacker Idle Host
Figure 4-8 Idle scan of a closed port.
An open port idle scan works as follows: an attacker sends an ID IP probe to the idle host to solicit a response. In Figure 4-7, we can see that the response produces an IPID of 12345. Next, the attacker sends a spoofed packet to the victim. This SYN packet is sent to the victim, but is addressed from the idle host. An open port on the victim’s system will then generate a SYN/ACK as seen in step 2, item 2. As the idle host was not the source of the initial SYN packet and did not at any time wish to initiate communication, it responds be sending an RST to terminate communications. This increments the IPID to 12346, as can be seen in step 2, item 3. Next, the attacker again queries the idle host as seen in step 3 and is issued an IPID response of 12347. Because the IPID count has now been incremented by two from the initial number of 12345, the attacker can deduce that the scanned port on the victim’s system is open.
Now let’s turn our attention to Figure 4-8 and look at the behavior of a closed port.
Step 1 of Figure 4-8 starts exactly the same way as previously described. An attacker makes an initial query to determine the idle host’s IPID value. Note that the value returned was 12345. In step 2, the attacker sends a SYN packet addressed to the victim but spoofs it to appear that it originated from the idle host. As the victim’s port is closed, it responds to this query by issuing an RST.
Because RSTs don’t generate additional RSTs, the communication between the idle host and the victim end here. Next, the attacker again probes the idle host and examines the response. Because the victim’s port was closed, we can see that the returned IPID was 12346. It was only incremented by one because no communication took place after the last IPID probe that determined the initial value.
There are limitations to the ability of an idle scan. First, the system that is designated to play the role of the idle host must truly be idle. A chatty system is of little use as the IPID will increment too much to be useful. There is also the fact that not all operating systems use an incrementing IPID. As an example, some versions of Linux set the IPID to zero or generate a random IPID value.
Again, these systems are of little use in such an attack. Finally, these results must be measured; by this I mean that several passes need to be performed to really validate the results and be somewhat sure that the attacker’s conclusions are valid. In conclusion, we can see that the overall value of an IPID scan is that it hides the attacker’s true address and is yet another example of how the misuse of the protocols allows malicious individuals more information than they should be privy to. Now, let’s turn our attention to some of the programs that can be used for port scanning.