by Rik Farrow <rik@spirit.com>
The Internet Control Message Protocol (ICMP) is simple, as Internet protocols go. Originally described in RFC 792 by Jon Postel, ICMP provides a way for IP stacks to send simple messages containing information or errors. And, while ICMP is important to the correct functioning of the Internet (and IP networks), understanding exactly what ICMP does, and how it may affect your network's security, has been something of a black art.
ICMP has been used for scanning, denial of service, and tunneling (see March 2000 and August 1999 Network Defense), besides the uses that Postel had in mind for it. Recently, a research paper written by an Israeli security consultant, Ofir Arkin, has drawn attention to some of the more arcane ways that ICMP can be employed in scanning networks. At the end of his paper (see Resources), Arken suggests permitting only one of the 52 ICMP types and codes through a firewall, and that only inbound.
This column explains something about ICMP, how it works, and how it can be abused for purposes of scanning networks. We'll also consider which ICMP types you might want to traverse your firewall.
The most familiar ICMP use involves ping, the Packet Internet Groper program. Ping commands your IP stack to send out an ICMP Echo Request (type 8) packet, and waits for ICMP Echo Replies (type 0). If the destination of the ICMP packet is up, has an IP stack, and is not behind a device blocking ICMP echoes (firewall), the ICMP Echo Reply will be received by your IP stack, and presented to your ping program so you can see that the replies were received, and that the remote system was up and reachable.
Obviously, ping can be used for scanning networks. By trying each host address in turn, ping can see which IP addresses within a network have systems with IP stacks connected. For this reason, many firewalls block incoming Echo Requests, to prevent ping scanning of networks.
But there are other ICMP types that can also be used for scanning. The ICMP Timestamp (type 13) will elicit an Timestamp Reply, but only from UNIX systems (Microsoft has not implemented this functionality it its IP stacks). Getting a response to an Timestamp request not only tells you that a system is up, but also that it is _not_ running a Microsoft operating system. [Note: W2K, ME and newer versions of Win98 WILL respond to Timestamp requests, as MS has released a newer stack. The trick mentioned in the next paragraph can be used to identify MS stacks.]
Arkin points out in his paper that
you can identify Microsoft stacks using ICMP Echo Requests. Some
ICMP types also have subtypes, called codes, but not ICMP Echo
Requests or Replies. If however, you send an Echo Request with a
code value set, Microsoft stacks clear the code in the response,
but not UNIX stacks. There are also differences in how IP
stacks handle IP header errors, which can elicit Parameter Problem
messages (type 12). So, using ICMP, it is possible to identify
both UNIX and Window stacks.
ICMP Address Mask Requests (type 16) should only be answered by routers, with an Address Mask Reply (type 17). The Address Mask Request can not only be used to identify routers, but also to collect subnet information, useful in mapping out networks. As this ICMP type should only be used by local hosts looking for the subnet masks, it is an obvious candidate for blocking at firewalls, and router vendors can design router software that only responds to requests from neighboring networks. [Note: Solaris systems DO respond to address mask requests, although they should not. You can distinguish Solaris systems from routers by sending the ICMP request in two fragments: when received as a single packet, you will get the correct netmask, when sent in two fragments, you will get all zeroes as the netmask. This according to a posting made by Arkin on August 6.]
Redirects (type 5) are used to adjust routing tables. Imagine that your desktop is on a subnet where there are two routers, each leading to different networks. Your system will be configured to treat one of these routers as the default route, but when packets that should be sent to the other router arrive at the default router's address, this router will send an ICMP redirect to your host adjusting its routing table. Depending on the information available to the router, it can send one of the four codes, for example a host redirect (code 0) or a network redirect (code 1).
If an attacker can send your system ICMP Redirects, they can also adjust your routing table, causing a denial of service. Cisco routers, for example, will not forward ICMP Redirect messages from other networks, blocking this attack remotely (but not locally). But this is an example of an ICMP type that should never pass through a firewall.
Source quench (type 4) is not used for probing, but could be used for denial of service. Source quench is sent back to the sender of traffic to tell it to slow down the rate it sends packets to the receiver. While it makes sense to permit Source Quench messages to public servers, it makes no sense to permit these ICMP messages into your internal networks.
The Time Exceeded (type 11, code 0) message is used by traceroute and for error handling. IP headers include a time-to-live (TTL) value that gets decremented each time the IP packet passes through an IP layer. The TTL prevents packets from looping forever, as it will eventually become zero, and can start with a value of no greater than 255. The traceroute program sends out packets with the TTL set artificially low. This causes intermediate routers to send back Time Exceeded messages including their own source addresses, and is the information you see displayed when you use traceroute (or the Microsoft version, tracert). Obviously, Time Exceeded messages can be used to map out networks.
A less obvious use of Time Exceeded messages has to do with its other subtype (code 1). This subtype is used to signal a sending host that not all fragments were received, and that the fragment reassembly time was exceeded. Arkin points out that this can be used to scan by sending only the first fragment, and waiting for the Time Exceeded message to be sent back. This technique can be used for portmapping as well, although it relies on the systems and ports being accessible through a firewall.
One of the most interesting ideas suggested in Arkin's paper has to do with inverse mapping using Destination Unreachable (type 3) messages. The Destination Unreachable type has 15 subtypes (codes), distinguishing just what is unreachable, and sometimes why. For example, a router can report that a network, system, or a port on that system is unreachable, and it can also report that it is "Administratively Prohibited", in other words, blocked by a firewall or packet filter.
It makes sense to permit Destination Unreachable messages to pass inbound through your firewall. Blocking these messages means that Internet applications, like Navigator or IE will hang waiting until a failed connection attempt times out, instead of receiving the Destination Unreachable message, and relaying that information to the user. There is a very old denial of service attack, involving DEC ULTRIX systems, where all connections to a particular server could be shutdown in error by sending a single Destination Unreachable, but ULTRIX is sufficiently rare these days to ignore.
Allowing Destination Unreachables out through your firewall is another thing. Arkin suggests a technique he calls inverse mapping. If you can send packets to some port (for example, port 53, used by DNS) to all systems, the addresses that are not in use will provoke the router local to that network to send back a Destination Unreachable, Host Unreachable code back to the scanner. Thus, you get messages from not-inuse IP addresses, providing an inverse mapping of your network.
The only type of ICMP message that Arkin suggests you allow through your firewall has to do with determining the Path Maximum Transmission Unit, or Path MTU. Modern IP stacks avoid fragmentation of packets by choosing a packet size that will be the same size or smaller than the smallest MTU along the path. Systems exchange MTU information using a TCP option, but the way a system learns the Path MTU is by sending a packet no bigger than the local MTU with the "Don't Fragment" bit set in the IP header. If the packet is larger than any segment of the path's MTU, a Destination Unreachable, "Fragmentation Needed and Don't Fragment was Set" (code 4) will be returned. The system receiving this message is supposed to pare down the packet size.
Arkin's advice is certainly conservative and safe. Table 1 lists the different ICMP types, and you can get a complete listing of the codes using the Resources. What you decide to do really depends on the level of security you want for your network and the type of firewall you are using.
Application gateway firewalls, like Secure Computing Sidewinder
and Axent Raptor,
terminate TCP connections at the firewall itself. This means
that ICMP messages also communicate with the firewall's stack,
and do not pass through the firewall when an application
gateway is used.
Other firewall technologies must pass some ICMP messages through, or IP performance and network efficiency suffers. Of all of the ICMP types, the Destination Unreachables are the most important to pass inbound through a firewall. If you are using filtering to protect Web or other public servers, you may want to permit inbound Source Quench as well. For outbound, blocking all ICMP types is the safest approach, although again you may wish to permit some types, depending on the stance of your network's security.
ICMP is really pretty simple. There are just a few types of messages that should be allowed through for maximum security. For networks where security is not the priority, ICMP was designed for the smooth working of the Internet Protocol, and if you are not preventing other types of scanning, you should just leave it alone.
You can find all the types and code values for the different ICMP messages here: http://www.spirit.com/Resources/icmp.html
Jon Postel's original paper defining ICMP: http://www.faqs.org/rfcs/rfc792.html
Steve Deering's RFC1256 describing ICMP router discovery messages: http://www.faqs.org/rfcs/rfc1256.html
ICMP behaviou for IPv4 routers:
http://www.faqs.org/rfcs/rfc1812.html, section 5.2.7
Ofir Arkin's paper about tricks that can be done with ICMP that
are generally unrecognized:
http://www.sys-security.com/html/projects/X.html
Type Name Issues 0 Echo Reply Used in probes, tunneling, DoS 3 Destination Unreachable Improves performance, used in probes 4 Source Quench Improves performance 5 Redirect Improve local perf, local DoS 8 Echo Used in probes, DoS 9 Router Advertisement Local use only 10 Router Selection Local use only 11 Time Exceeded Used in traceroute, probes 12 Parameter Problem Report header errors, used in probes 13 Timestamp Used in probes 14 Timestamp Reply Can be used in probes 15 Information Request Obsolete 16 Information Reply Obsolete 17 Address Mask Request Local use okay, useful in probes 18 Address Mask Reply Only routers should reply, probes 30 Traceroute Possible replacement for traceroute