ICMP: The Good, the Bad, and the Ugly

Ron McCarty

The Internet Control Message Protocol (ICMP) as defined by RFC 792 is a key part of the TCP/IP protocol family. ICMP's most popular application, ping, is possibly the most common network application provided by UNIX and non-UNIX network operating systems.

The Good

In addition to the standard 20-byte IP header at the front of the datagram, the ICMP contains 32 bits that includes an 8-bit type field and an 8-bit code. The 8-bit type contains the values 0 through 18 (values 1,2, and 6 are not used). The most common types you are likely to see are: 0 Echo Reply, 3 Destination Unreachable, 5 Redirect, 8 Echo, and 11 Time Exceeded.

The type field defines the type of message, whereas the code is used to further define the ICMP message for interpretation by the receiving kernel or application. Most versions of ping, for example, send an ICMP message with type 8 and code 0, which is an echo request. The receiver will then reply with the ICMP message of type 0 and code 0.

Besides the connectivity troubleshooting provided by ping, ICMP plays other important roles for networks. The ICMP redirect (type 5) allows optimization of networks and is often used within networks without the knowledge of users and many junior network administrators. Figure 1 shows how the ICMP redirect works. Assume the workstation (192.168.1.1) only has a default route to the router on 192.168.1.254. Without ICMP redirect, it would send all traffic to the network of 10.0.0.0/8 through 192.168.1.254, which would then route the traffic to 192.168.1.253, requiring one more hop than necessary.

Adding static routes or using a routing protocol on individual workstations to route traffic for 10.0.0.0/8 to 192.168.1.253 can cause management headaches and is not good practice. With ICMP support a static route or routing protocol on the workstations is not necessary. When the router 192.168.1.254 receives the initial packet to be routed to the 10.0.0.0 network, it will route the traffic and send an ICMP redirect network message (type 5, code 0). The workstation then knows to send the traffic for 10.0.0.0/8 directly to 192.168.1.253. ICMP redirects can also provide a redirect for a specific host and even type of service network and type of service for host. (I've never seen the type of service redirects, so drop me an email if you've seen creative use and any dependencies of particular operating systems or routers.) ICMP redirects should be watched in environments with a large number of hosts (routers and networks, for example) in an environment where a central server farm is located on a network backbone with several routers providing various paths to the corporate network. If the ICMP redirects are affecting performance, then the design of the particular network area may need reconsideration as well as possible consolidation of the routers and networks.

In addition to ICMP redirect, ICMP also provides notices to applications that particular services are not available with the ICMP destination unreachable (type 3) message. ICMP can notify the requestor that the network is unreachable (type 0). A router will typically send this ICMP message when an interface goes down that affects a particular network. Additionally, the destination unreachable can report an unreachable host (the ping command recognizes this message), as well as the port unreachable. The port unreachable message is used by traceroute -- traceroute uses a high UDP port where there is likely no daemon listening, and the destination host returns the port unreachable message. (traceroute uses the ICMP message type 11; code 0 time is zero during transit in its operation.)

Besides the useful ping command, network administrators often have tools that use ICMP to troubleshoot and map networks in poorly documented environments. nmap (http://www.insecure.org/nmap/) for example, can quickly provide a list of hosts on a particular network with:

nmap -sP 192.168.1.0/24

The Bad

Based upon ICMP's network administrative function, it is clear where ICMP can play a very important role in troubleshooting. Unfortunately, ICMP and knowledge of specific network operating systems can also be used to gather information that can exploit networks. For example, many tools can fingerprint operating systems based upon how they report ICMP messages. nmap provides a parameter specifically for this purpose and can actually identify Linux and Solaris systems based upon how they reply with error messages. Although this information often proves useful to administrators in a heterogeneous environment, a hacker can also use the information to target specific hosts for attacks.

A hacker can also infer information because of what doesn't happen based upon knowledge of the ICMP protocol and an operating system. For example, not receiving a “destination unreachable”, but no connection will typically mean there is a packet filter or firewall between the source and destination.

Of course, the whole IP stack of many implementations can be used to determine the OS, and http://www.insecure.org/nmap/nmap-fingerprinting-article.html gives a good overview of some of the methods nmap uses for OS fingerprinting. However, ICMP is a favorite because of its small footprint and almost universal implementation across operating systems.

Creating a security policy that denies all fingerprinting capability is not realistic for most organizations since many services identify themselves to the world during normal operation. (Mail Transport Agents, WWW servers, and ftp servers often identify themselves and the version of software when connecting to clients.)

However, you can use the same tools hackers utilize to perform your security audits and determine what information can easily be withheld or, better yet, how specific hosts or services can be further hardened. In other words, typically a large amount of time spent hiding the fingerprints is better spent on auditing systems and applying security patches and performing recommended hardening procedures.

The Ugly

The normal unmonitored use of ICMP can, unfortunately, be exploited. ICMP redirects must be filtered at the external firewall and on internal firewalls to keep traffic from being diverted to a host that can sniff and then route the traffic or simply be used as a denial of service.

Notice I did not say that all ICMP traffic must be stopped at the firewall. ICMP is also a useful part of MTU path discovery. Although MTU path discovery support is not required, most organizations with various frame-sized networks (Ethernet, FDDI, TokenRing) rely on MTU path discovery to work correctly to take advantage of larger frame sizes supported by FDDI and TokenRing. Filtering of all ICMP requests can, therefore, actually break the MTU path discovery. Mark Slemko's paper at http://www.worldgate.com/~marcs/mtu/ has a good discussion of MTU path discovery and packet filtering.

An important part of seeing some of the “ugly” perspectives of ICMP is to take a closer look at some of the ICMP exploits published by security organizations and vendors. One of the most publicized ICMP denial of service attacks was the Smurf attack (http://users.quadrunner.com/chuegen/smurf.cgi). The Smurf attack consumed large amounts of bandwidth by pinging the broadcast address with a spoofed (the victim's) address. Dial-up links can be quickly brought to a standstill, and I've even seen E1s so over utilized by the replies that telnet sessions to routers on the path could not be initiated. Filtering can prevent the echo requests from being routed through, but an offspring of this attack has been automated scripts to ping a whole range of “known” hosts that reply to pings with a spoofed address in an attempt to deny services to the victim.

Poor implementations of ICMP have also caused other attacks -- typically a host-based denial of service caused by a racing condition triggered by an incorrectly formed ICMP packet. Fortunately, these weaknesses are usually well publicized with patches released quickly by vendors. With rare exceptions, vendors also include the fixes as part of new releases of software.

Since a sound security policy requires some filtering of ICMP, you will also need to have other troubleshooting methods for testing around and through firewalls. Pings to and from specific hosts are allowed by some policies. telnetting to specific open ports can often verify connectivity through the firewall. In some circumstances, policy may need to be temporarily relaxed to determine if firewall policy is breaking the connection. Placing packet sniffers on both sides of a firewall is also often necessary during phases of tightening security or performing security audits.

Summary

ICMP plays a very important role in network functionality and troubleshooting. However, a keen understanding of its purpose and weaknesses will ensure that networks are running smoothly and securely. Furthermore, a good understanding of the protocol and its uses will help you maintain an even head during a possible denial of service attack, which will help you document and shut down the attack.

There are many tools available for troubleshooting ICMP problems and attacks, but I generally prefer to use a sniffer such as tcpdump and a very large hard drive to capture all traffic and then later filter out the interesting parts of the traffic. However, many of the ICMP loggers seem to offer some interesting statistics analysis functions that may require a closer look.

About the Author

Ronald McCarty received his bachelor's degree in Computer and Information Systems at the University of Maryland's international campus at Schwaebisch Gmuend, Germany. After completing his degree, Ronald McCarty started his network career as network administrator at the Schwaebisch Gmuend campus. Ronald McCarty currently works for Software Spectrum, Inc. as a network engineer in the IT&S Network Services Project's team. He spends his free time with his two best friends in the world: his daughter, Janice, and his wife, Claudia. Ron can be reached at: mccarty@my-own-domain.to.