Original releases of Loki had a signature of a static value in the sixth and seventh bytes (starting with byte 0) of the ICMP message. This could be determined by dumping the traffic using TCPdump with hexadecimal output and observing the lack of change in this field that is the ICMP sequence number. This field is usually unique for each ICMP echo request sent out and, much like the IP header identification number, increments by 1 or 256 for each subsequent ICMP echo request. Later incarnations of Loki might use encryption and might not be decipherable in this manner.

As you have witnessed, ICMP echo traffic, whether request or reply, can facilitate some

noxious activity. So, this is an excellent candidate for blocking by a packet-filtering device.

Summary of Malicious ICMP Traffic

To wrap up this section, you learned that ICMP has been manipulated in use for other purposes than the intended ones. ICMP can be used in a denial-of-service attack, as you observed in the Smurf and WinFreeze attacks. ICMP was used more as a conduit for communication in the TFN attack. It might not be used directly as a denial-of-service attack, but it enables a denial-of-service attack to occur by providing the communication vehicle between the TFN master and daemons. Finally, you saw that Loki has completely altered the original purpose of ICMP by using it as a tunneling mechanism for malicious activity.

To Block or Not to Block

After reading about all the havoc that ICMP now can wreak, it appears that ICMP left Kansas along with Dorothy and Toto. From a reconnaissance aspect, if you can elicit any of the following ICMP messages from a host, you know you have reached a live host:

●"protocol unreachable"

●"port unreachable"

●"IP reassembly time exceeded"

●"parameter problem"

●"echo reply"

●"timestamp reply"

●"address mask reply"

Also, if you can get a router to report ICMP host unreachable errors, it is possible to

inversely map a network assuming that those hosts which do not have this error reported are indeed live hosts.

As if this isn't enough information, the following common ICMP messages are sent by routers only so if you can elicit any of the following, you can identify a site's routers:

●"fragmentation needed but don't-fragment bit set"

●"admin prohibited"

●"time exceeded in transit"

●"network unreachable"

●"host unreachable"

And, finally, we can discover more reconnaissance by the following ICMP messages:

●"admin prohibited: can assist in examining what type of traffic the site blocks"

●"address mask reply: gives the subnet mask of the network on which the responding

host resides"

●"time exceeded in transit: used in traceroute to discover routers and network topology"

●"protocol unreachable: can be used to inversely map a host's listening protocols"

●"port unreachable: can be used to inversely map a live host's listening UDP ports"

●"fragmentation needed but don't fragment bit set: can be used to determine the MTU of links for use in attacks that use fragments"

Given all the reconnaissance that ICMP can supply, why not just unconditionally block all incoming and outgoing ICMP traffic? Some sites do just this, but let's examine some of the

repercussions of blocking all inbound ICMP.

Unrequited ICMP Echo Requests

Obviously, your ability to do diagnostic activity using ping is broken when you block both inbound ICMP echo requests and echo replies. The good news is that ICMP echo requests and replies cannot be used as a front for stolen goods if blocked. The inconvenience suffered by this loss might be justified by the improvement of your security posture, eliminating a possible stealthy avenue into your network.

You might face a temptation to block only inbound ICMP echo requests, which would enable you to do diagnostics from your network and receive a response by virtue of the ICMP echo response gaining inbound access. The hackers know this, however, and as you have witnessed with Tribe Flood Network and Loki, they are relying more on the use of ICMP echo reply as a

delivery mechanism.

Kiss traceroute Goodbye

Whether you use the UNIX traceroute command or the Windows tracert command to discover the routers through which a datagram travels on its path from source to destination, blocking inbound ICMP prevents you from executing these commands from your network to other networks. These commands require inbound ICMP "time exceeded in-transit" messages to operate correctly. By preventing all ICMP into the network, you break your use of traceroute outbound.

The Windows tracert command uses the ICMP echo request, so blocking inbound ICMP precludes a user from doing a tracert to a machine in your network. The UNIX traceroute uses UDP as the protocol, however, so blocking inbound ICMP does not prevent someone from

executing a UNIX traceroute to a host in your network.

Silence of the LANs

As you learned in this chapter, ICMP can inform about unreachable conditions to a particular host or port. When you block all inbound ICMP messages, hosts or routers on your network cannot receive these informative messages. This does not produce catastrophic results, but it does cause some inefficiencies. As an example, a host on your network might attempt a TCP connection to another host that might be down. This could elicit a "host unreachable" message from a remote router, but the host attempting this connection doesn't receive the ICMP unreachable message because it is blocked. The sending host retries until it times out, thereby

sending unnecessary traffic.

Broken Path MTU Discovery

As discussed previously, when possible, a host sending TCP traffic tries to avoid fragmentation of datagrams. This is done using path MTU discovery. As covered in this chapter, a sending host uses the Don't Fragment flag in a discovery packet. The intent is for the discovery packet to reach the destination host without being fragmented, or for the sending host to receive an ICMP "need to frag" message with the value of the smaller MTU found in the message. Therefore, blocking all inbound ICMP breaks this mechanism and causes some significant problems. A host sending the discovery packet expects to receive an ICMP "need to frag" message if fragmentation is required. Because it receives no such message due to the inbound ICMP block, it continues to send oversized datagrams with the Don't Fragment flag set. These are dropped, but the sending host is never informed of this. Packets sent that are smaller than