hosts with this window size, and the second scan had 6.60 percent hosts with this window size. The conclusion that can be drawn examining the TCP window size is the same as examining the arriving TTL values. Looking at Figure 11.6, most of the scanning hosts appear to have a window size associated with Windows, yet it also appears that operating systems other than Windows

are involved in the scanning too.

TCP Options

Another interesting field for examination is the Maximum Segment Size (MSS), which is found in the TCP options. This represents the maximum amount of payload that a TCP segment can carry. This does not include the TCP header and the IP header. Generally speaking, the MSS is 40 bytes less than the Maximum Transmission Unit (MTU), assuming a 20-byte IP header with no IP options and a 20-byte TCP header with no TCP options. The MTU can then be used to determine the media on which the sending host resides.

In some instances, although not this one, the MTU, and hence the MSS, might reflect the path MTU. The sender might send a "discovery" packet that looks for the smallest MTU from source to destination by setting the DF flag on the packet. If no ICMP error messages are returned, it is assumed that using the size of the local MTU for packaging packets will not cause fragmentation. If an ICMP error message "unreachable – need to frag (mtu ###)" is returned, it contains the MTU size (###) of the link that is smaller than the size of the local MTU. The

sender can decrease the size of the packets to avoid fragmentation. The point is that it is possible that the MSS might not reflect the local MTU. However, because there is no indication of discovery packets or that path MTU was used, the assumption is that the MSS does reflect the local MTU.

Figure 11.7 reveals that the greatest percentage of scanning hosts resided on a link with an MTU of 1500. This is indicative of Ethernet, found in LAN connections or DSL. The MTU of 576 is associated with PPP or ISDN. Finally, the MTU of 1454 is associated with PPP over Ethernet that is also found on DSL connections.

Figure 11.7. MSS/MTU values.

Although the MSS of 536 is associated with PPP and dial-up modems, it is supposed that most of the hosts reside on ISDN, which uses the same MSS. The scenario is that these are all zombie hosts that are directed to do some type of activity at a given time. Either they respond to a catalyst or they all have some kind of time synchronization and are directed to respond at a given time.

The idea of participants from dial-up modems is worth some reflection. First, if a zombie is associated with a dial-up connection, this might not be a sustained connection unless there is some kind of dedicated phone line for the traffic. Additionally, many dial-up connections are at the mercy of Dynamic Host Configuration Protocol (DHCP) with a leased IP number for a certain period of time. How would the "commander" direct a zombie with a changing IP number to launch the activity? One guess is that the zombies report home to the commander periodically. Therefore, only ones that are active and online just before the attack are directed to participate in the attack.

Another question arises from this discussion. It has already been determined that zombies have assignments of mostly unique address ranges to scan. Is there some kind of formula used to assign the address ranges to scan so that the maximum numbers of hosts get scanned?

The suspicion is that most of the participating zombies have a sustained and dedicated Internet

connection, but this doesn't adequately explain the missing destination hosts and subnets.

TCP Retries

As mentioned, when a source host attempts a TCP connection to a destination host and is unsuccessful, yet gets no indication of the failure, it attempts one or more retries. A source host is not notified of a failure if the connection packet never gets to the destination or the destination host's response doesn't get back to the source. In the case of our scanned network, the activity to port 27374 was blocked.Yet, the firewall that blocks the activity "silently" drops the packet with no notification in the form of an ICMP error message to the original source host that there is a problem. The purpose of the silent drop is so that no additional reconnaissance is