If a scanner can determine a subnet mask of a network, he knows exactly how many hosts need to be scanned. Although the subnet mask of a host usually can be determined from looking at the first octet of the IP number, this request might discover the networks that don't have a "natural" subnet mask. That type of knowledge cannot be obtained from looking at the

IP number alone. In this example, the scanned routers respond with subnet masks of a hexadecimal ffffff00. This translates to a decimal 255.255.255.0 subnet mask of the

network on which they reside. This means that these hosts all belong to a Class C network. Querying for address masks is another type of ICMP activity that should be disallowed into the network, for obvious reasons.

Summary of Mapping

Let's briefly recap the discussion about mapping. Mapping can be done using the following methods:

∙Sending individual ICMP echo requests to hosts in a network

∙Sending ICMP echo requests to the broadcast addresses of a network

∙Sending ICMP echo requests to network and broadcast addresses of subdivided networks

∙Sending an ICMP address mask request to a host on the network to determine the subnet mask to better understand how to map efficiently

Normal ICMP Activity

This section examines some of the expected uses of ICMP—specifically, several different error messages that ICMP sends to inform a host of some kind of problem situation. Looking at mutant ICMP activity is more intriguing, but you've got to be able to understand what's normal before you can recognize abnormal ICMP activity.

Host Unreachable

In the following ICMP output, you can see an error message to sending.host, which is attempting to send traffic to a target host:

router > sending.host: icmp: host target.host unreachable

For some reason, the target.host is unreachable—perhaps no host resides at the requested

IP address, perhaps the host is temporarily unavailable, or perhaps the host is suffering from some kind of misconfiguration that prevents it from responding.

In a situation such as this, the host obviously cannot send an error message, so the router

that oversees the target host's network intervenes to deliver the message. In this case, the router informs the sending host that the target host is unreachable. As you can probably guess, this gives a scanner valuable information that he can use to help him map the network. If a scanner is collecting information about live hosts in a network to later scan, those that have been identified as unreachable would likely not be scanned again. This makes any subsequent scans more focused.

The valuable reconnaissance information that can be gleaned from many of the ICMP

unreachable commands can be detrimental to the security of a given network. Cisco router access control lists have a statement no ip unreachables that can silence the router

interface from issuing the ICMP unreachable messages.

Port Unreachable

The ICMP output that follows demonstrates how a target host informs a sending host that a requested UDP port is not listening. In this example, the sending host attempts to send traffic to the target host on the UDP network time protocol (ntp) port:

target.host > sending.host: icmp: target.host udp port ntp unreachable (DF)

Therefore, the protocol used to deliver the error message is ICMP. Remember that when you examined TCP, that protocol had a different way of informing a sending host that a port was not active. It returned a packet with the TCP RESET flag set to indicate that the port was not listening. UDP has no built-in mechanism to report about this error, so it enlists ICMP to assist.

Again, you can see that valuable reconnaissance can be gained from this ICMP error message—namely that scanned UDP ports that do not respond with this message could be listening ports. But, it is also possible that scanned UDP ports that do not respond might never have received that scan due to packet loss. It is also possible that outbound port unreachable messages are blocked from leaving the network. So, you can see that the absence of a port unreachable message from a scanned UDP port is not a definitive confirmation that the port is listening.

Admin Prohibited

Take a look at another possible problem situation with the following output:

router > sending.host: icmp: host target.host unreachable - admin prohibited

In this scenario, a sending host is attempting to deliver traffic to a target host. A router is at the gateway of the target host network.

The router has an access control list that prohibits certain types of traffic from entering the network. This could be a port that is blocked, a protocol that is blocked, or possibly the source IP or subnet that is denied access, or the destination IP or subnet that is protected. A router might respond to this condition with an ICMP "unreachable - admin prohibited" message. Although this ICMP message does not indicate what is being blocked (a destination port, a source IP, or an IP protocol, for instance), an astute scanner can attempt different combinations of connections and figure out what is being disallowed into the network and possibly find other avenues into the network that are not blocked.

Need to Frag

Another ICMP message warns that a desired host is unreachable because of a problem with fragmenting a datagram:

router > sending.host.net: icmp: target.host unreachable - need to frag (mtu 1500)

The DF output in TCPdump means that the Don't Fragment flag is set. As the name implies, if this flag is set, fragmentation will not be done on the datagram. If this flag is set and the datagram crosses a network in which fragmentation is required, the router discovers this, discards the datagram, and sends an ICMP error message back to the sending host.

The ICMP error message contains the maximum transmission unit (MTU) of the network that required fragmentation. Some hosts conversing in TCP intentionally send an initial datagram across the network with the DF flag set as a way to discover the smallest MTU for a particular source-to-destination path. If the ICMP error message is returned with the smallest MTU, the host then packages all datagrams bound for that destination in small enough chunks to avoid fragmentation. The intent is to eliminate the overhead and inefficiencies in packet loss associated with fragmentation.

Time Exceeded In-Transit

This ICMP message informs a sending host that a datagram has overstayed its welcome on the Internet:

routerx > sending host: icmp: time exceeded in-transit

IP needs a way to flush a lost datagram from the Internet, perhaps one that is in some kind of routing loop in which it is bouncing aimlessly between routers. The means used to prevent wayward datagram activity involves a field in the IP header known as the time-to-live (TTL) value.

Different operating systems set different initial TTL values. To examine default initial TTL

values set by operating systems, go to http://project.honeynet.org/papers/finger/traces.txt.

When a datagram traverses a router on its travel from the source to destination, each router decrements the TTL value by 1. If the value ever becomes 0, the router discards the datagram and sends an ICMP "time exceeded in-transit" message back to the sending host. Chapter 5, "Stimulus and Response," shows how traceroute uses this ICMP "time exceeded in-transit" message along with incrementing TTL values to discover and record interim routers along the path from a given source to destination.

Embedded Information in ICMP Error Messages

It is helpful to understand that when an ICMP error message is returned, there is some additional information that is supplied in the datagram. Specifically, after the actual ICMP message, you will find the IP header followed by eight bytes of protocol header and data of the original datagram that caused the error, as seen in Figure 4.2. This information allows the receiving host to associate this error with the sending process and react appropriately. An external response to an ICMP error message is not expected because RFC 1122 describes this