 |  |
22.4. ICMP and Network Diagnostics
The ICMP and network diagnostic protocols and programs are mostly used by network administrators to debug networks. They are the network administration equivalent of a carpenter's hammer and saw: the most basic, simple, and critical tools, ancient in design but nonetheless indispensable.Because they are widely accepted low-level protocols, they are also frequently exploited for attacks. A number of denial of service attacks are based upon malformed ICMP packets, and a number of Trojan horses use ICMP to send information out of compromised sites. In addition, forged or inaccurate ICMP packets are often used as part or all of attacks on systems. For instance, an attacker can send an ICMP "destination unreachable packet" for a host that is actually reachable; this will interfere with communications to the attacked destination.
any packet filtering systems let you filter ICMP packets in much the same way as TCP or UDP packets: by specifying the ICMP message type code instead of the TCP or UDP source or destination port number. If your packet filtering system has this capability, its documentation should include a list of the ICMP numeric codes or keywords that the packet filtering system understands. You may not want to filter all ICMP because it will prevent path MTU discovery from functioning, and this may cause problems (see Chapter 4, "Packets and Protocols ", for more information about path MTU discovery).
22.4.1. ping
The ping[156] program checks network connectivity. The ping application generates an ICMP "echo request" packet. The destination system responds with an ICMP "echo response" packet. ICMP is typically implemented in the kernel, so it's the kernel that generates the "echo response" packet; there is no separate server for ICMP on most systems. (On some machines, the echo response is actually generated in the network interface itself, not in the operating system, and the machine need not even be fully running to respond to ping.) ping is not the only program that uses ICMP echo; others include spray and almost any dedicated network management tool.[156]ping is not an acronym. Mike Muus, who wrote the original program, confirms that he named it after the noise sonar makes.ping is a useful network troubleshooting tool, and it is reasonably safe. You'll probably want to allow ping outbound from at least the machines your network operations staff uses and inbound from at least the network operations center machines of your network service provider.
Because of where it is implemented, it is almost impossible to disable replies to ping on individual hosts; packet filtering is the only way to control it.
There are multiple dangers in allowing ICMP echo:
- It can be used for a denial of service attack -- that is, to flood your network. Although any protocol you accept can be used in this way, ICMP echo is particularly tempting because commonly available programs designed for network testing (including some versions of ping) let you flood networks with simple command-line options.
- Anybody who can send ICMP echo requests to and receive ICMP echo responses from your network can discover how many machines you have and what network addresses they're at; this increases the efficiency of any further attacks. That's why you want to limit requests to machines that have a legitimate reason to be probing your network.
- Malformed ICMP echo requests may have unfortunate effects on weak implementations of IP. This is true of all protocols, but ICMP is easily overlooked and therefore tends to have hastily written implementations that are particularly vulnerable.
- The data portion of ICMP echo requests and responses are unimportant to the protocol and may legally contain anything. This makes ICMP echo a particularly useful way to smuggle information through a firewall.
22.4.1.1. Packet filtering characteristics of ping
To allow the ping program to operate outbound (i.e., pinging remote hosts), you'll have to allow ICMP echo request packets outbound and ICMP echo response packets inbound. To allow inbound ping (i.e., a remote host pinging a local host), you'll have to allow ICMP echo request packets inbound and ICMP echo response packets outbound. If possible, you will also want to limit the acceptable size of ICMP echo request packets. Limiting the inbound size is a self-protection measure, designed to protect against denial of service attacks; limiting the outbound size is a matter of politeness.| Direction | SourceAddr. | Dest.Addr. | Protocol |
essageType[157]
|
Notes |
|---|---|---|---|---|---|
| In | Ext | Int | ICMP | 8 | Incoming ping |
| Out | Int | Ext | ICMP | 0 | Response to incoming ping |
| Out | Int | Ext | ICMP | 8 | Outgoing ping |
| In | Ext | Int | ICMP | 0 | Response to outgoing ping |
[157]ICMP messages do not have source or destination port numbers; they have a single ICMP message type field instead. ICMP has no ACK equivalent.If you have a stateful packet filtering system, it is wise to configure it so that you allow responses only if you have seen a matching request. This is particularly important if you only allow requests in one direction, since the responses will be going in the direction where requests are denied. Unsolicited responses are always hostile, whether they are actual attacks or being used as covert channels to smuggle information.
22.4.1.2. Proxying characteristics of ping
SOCKS5 provides a modified-client proxy system for ping. Because ping is neither TCP- nor UDP-based, it won't work with most generic proxy servers for modified-client proxying. Because ping transmits no user-supplied data to the destination host, modified-procedure proxying for ping is not possible. odified-procedure proxying also relies on the ability of the proxy server to intercept the request before the machine it's running on generates a reply, which is difficult with ping. In a pure modified-procedure proxying environment, ping will have to be provided by letting users connect to the proxying host (for instance, with a special web page) and run ping from there, as discussed in Chapter 9, "Proxy Systems". Several systems that use packet interception to do proxying supply ping proxies.When proxying ping, it is a good idea to sanitize the packet bodies. Instead of passing the original data portion of the response or request, the proxy should replace it with an equivalent length of data generated by the proxy. This will prevent the use of ping as a covert channel. In a few cases, it will also interfere with debugging (some network problems are dependent on particular data patterns triggering bugs in networking hardware). Fortunately, this kind of debugging rarely needs to cross the Internet.
22.4.2. traceroute
traceroute (also known as tracert on Microsoft systems) is an application that shows you the route that packets take to a particular IP destination. Because no system typically knows the full path to the destination (merely the next step towards the destination), this is a neat trick.[158] traceroute works by carefully constructing special packets. The destination address of the packets is the remote host; depending on the implementation, the packets are either ICMP echo packets or UDP packets where the destination port is an unused (or so we hope, as we'll discuss later) port on the remote host. The really special thing about the packets, though, is that the time to live (TTL) fields are set very low (starting at 1), so that the packets will be rejected by intermediate routers as if they were looping in the network. By looking where the rejections (ICMP "time to live exceeded" messages) come from, traceroute can determine who the intermediate routers are.[158]traceroute is, fundamentally, a "cool hack".TTL is a field in the header of every IP packet. It normally isn't of interest from a firewall point of view. The name is somewhat misleading; it might be more intuitively called "hops to live". When a packet is first created, its TTL field is set to some value (typically 16, 30, or 255). Every router that handles the packet along its journey decrements the TTL field by 1. If the TTL field ever reaches 0, the packet is assumed to be in some sort of a loop; it is encapsulated within an ICMP "time to live exceeded" message and is returned to the source address.
Thus, the first router that handles the first of traceroute's specially constructed packets (which has a TTL of 1) will decrement the TTL field, see that it's 0, and return an ICMP "time to live exceeded" message, telling traceroute the IP address of the first router (the IP source address in the ICMP message).
traceroute then constructs another packet, this time with a TTL of 2, and sends it out. This packet gets to the second router before TTL gets decremented to 0, and traceroute knows that the router that returns the ICMP "time to live exceeded" for that packet is the second router along the path to the destination. traceroute then constructs a packet with a TTL of 3, then 4, and so on, to determine the path to the destination.
traceroute knows it's finished when it gets back an ICMP "echo reply" or ICMP "destination unreachable" message, rather than an ICMP "time to live exceeded" message from some intermediate router.
ost versions of traceroute will also note and display relevant ICMP "host unreachable", "network unreachable", and other ICMP messages received.
If traceroute can't reach the destination host (or can't get anything back from it), it eventually times out.
22.4.2.1. Packet filtering characteristics of traceroute
To allow traceroute outbound through your packet filters (i.e., someone running traceroute from the inside, to an external destination), you have to allow the constructed UDP or ICMP packets outbound, and the relevant ICMP response packets inbound (particularly "time to live exceeded" and "destination unreachable").To allow traceroute inbound, you have to allow the constructed UDP or ICMP packets inbound, and the relevant ICMP messages back outbound. You may wish to limit this capability to the traceroute machines used by the network operations center of your network service provider, in order to keep a tight rein on the UDP packets allowed through your firewall. Limiting UDP protects RPC-based services (like NFS and NIS) and keeps attackers from using traceroute to discover which addresses at your site are actually assigned to hosts. The issues with ICMP echo, and the characteristics of echo and echo reply packets, are discussed earlier in the section about ping.
Some versions of traceroute that use UDP can be told (via a command-line or a compile-time option) which range of UDP ports to use for the destination. You may need to establish a convention for your site of what port(s) will be allowed through the packet filters for use by traceroute. You don't want to allow any more latitude in your packet filters for traceroute than absolutely necessary (particularly for incoming traceroute). Because traceroute is UDP-based, an attacker could potentially take advantage of the UDP-based rules in your packet filtering that are there to allow traceroute in order to attack other UDP-based services like NFS and NIS.
| Direction | SourceAddr. | Dest.Addr. | Protocol |
SourcePort[159]
|
Dest.Port[159] | essageType[159] | Notes |
|---|---|---|---|---|---|---|---|
| Out | Int | Ext | UDP |
[160]
|
[160] | [159] | Outgoing UDP traceroute probe |
| Out | Int | Ext | ICMP | [159] | [159] | 8 | Outgoing ICMP traceroute probe |
| In | Ext | Int | ICMP | [159] | [159] | 0 | ICMP echo response (answering probe) |
| In | Ext | Int | ICMP | [159] | [159] | 11 | Incoming "time to live exceeded" |
| In | Ext | Int | ICMP | [159] | [159] | 3 | Incoming "destination unreachable" |
| In | Ext | Int | UDP | [160] | [160] | [159] | Incoming UDP traceroute probe |
| In | Ext | Int | ICMP | [159] | [159] | 8 | Incoming ICMP traceroute probe |
| Out | Int | Ext | ICMP | [159] | [159] | 0 | ICMP echo response (answering probe) |
| Out | Int | Ext | ICMP | [159] | [159] | 11 | Outgoing "time to live exceeded" |
| Out | Int | Ext | ICMP | [159] | [159] | 3 | Outgoing "destination unreachable" |
[159]UDP packets have source and destination ports; ICMP packets have only message type fields. UDP or ICMP have no ACK equivalent.
[160]traceroute probe packet UDP source/destination ports vary by implementation, invocation, and/or command-line arguments. They are generally >32768, but that's about the only generalization you can make about them. Specific implementations (particularly in routers and on non-Unix platforms) may vary. Destination ports, in particular, are usually in the range 33434 through 33523. (Why this is the case is somewhat complicated, and you should read the comments in the Unix traceroute source code if you're perversely curious.)
22.4.2.2. Proxying characteristics of traceroute
Like ping, traceroute could easily be supported by an ICMP-knowledgeable modified-client proxy server. An appropriate server and client are provided as part of the SOCKS5 package. odified-procedure proxying is not possible with traceroute, although it is easy to use a web page to give people access to run traceroute on a bastion host.
22.4.2.3. Network address translation and traceroute
Since traceroute is intended to determine the network addresses that packets go through, using it with a network address translation system will often create confusion. If the network address translation statement is aware of ICMP, there is no reason for the traceroute to actually fail, but the information it returns to the user will include the translated addresses. For somebody running traceroute from a translated address, this should not be a problem. On the other hand, running a traceroute to a translated address may produce unpredictable results. There often will simply be no relevant mapping, and the traceroute will fail.
22.4.3. Other ICMP Packets
A number of ICMP message types used for network management don't have programs associated with them. These are automatically generated and interpreted by various programs and network devices.ICMP message types may also have codes, which contain more information. For instance, there are a number of codes under "destination unreachable", including "service unavailable", "communication administratively prohibited", and "fragmentation required and Don't Fragment set". In most cases, the codes within "destination unreachable" are the only ones of interest; none of the other widely used ICMP types actually use codes this way
What to do with ICMP messages depends on the message and the direction it's going in. We've already talked about "echo request", "echo reply", "destination unreachable", and "time to live exceeded" messages. The other ICMP message types you probably want to allow, both inbound and outbound, are "source quench" (used by a receiver to tell a sender to "slow down" because it's sending data too fast) and "parameter problem" (which is sort of a catch-all code to return when a problem with packet headers can't be reported any other way).
any other ICMP message types have the potential to change local information on your hosts (for example, "redirect" causes changes to a host's routing tables), so you probably don't want to allow such messages inbound through your packet filters.
Even "destination unreachable" can be problematic. Some attackers send out false "destination unreachable" messages, which may cause hosts to cut off communications in progress. (This is a popular attack against people using IRC.) There is no way to tell a valid "destination unreachable" from an invalid one, in general, because a "destination unreachable" can be sent by any machine in the path between the two hosts. However, most "destination unreachable" messages can legitimately be sent only at the beginning of a connection, and it is reasonable for hosts to ignore "destination unreachable" messages that are not plausible responses to packets that have been sent.
In general, you want to allow ICMP outbound only when it has the chance of doing you some good. Both "source quench" and "parameter problem" are used to get the sending host to be nicer to you and are worth allowing outbound. Any of the ICMP types that indicate that the connection can't be made ("destination unavailable", "network unavailable", "service unavailable", "destination administratively unavailable", or "network administratively unavailable", for example) will help an attacker probe your network without giving you much benefit, and you may want to block these outbound.
There are two exceptions to this rule. First, you may find it expedient to return some sort of error (either an ICMP error or a TCP reset) to Auth[161] queries if you are not going to allow them, in order to speed up mail transmission. This is discussed further in Chapter 21, "Authentication and Auditing Services". Second, you will want to return "fragmentation required and Don't Fragment set" from any host that can be directly reached with TCP from the Internet, in order to support path MTU discovery. This is discussed further in Chapter 4, "Packets and Protocols ". In both these cases, the rules that you really want to implement are impossible to specify on most packet filtering systems; they don't allow you to specify that an ICMP type is allowable only in response to a specific port, or to specify specific codes within a type. You may be able to use other workarounds discussed in the detail sections on these issues.
[161]The Auth protocol is also known as identd after a popular Unix daemon that implements it.
22.4.3.1. Packet filtering characteristics of ICMP
As we've said earlier, ICMP packets do not have source or destination port numbers but have a single ICMP message type field instead. Many packet filtering systems will let you filter ICMP packets based on that field in the same way they allow you to filter TCP or UDP packets based on the source and destination port number fields. The following table lists some common ICMP message types and how you should handle them (whether you should allow them through your firewall or block them).| essageType | Description | Permit/Deny |
|---|---|---|
| 0 | Echo reply (reply to ping). | See ping section earlier. |
| 3 | Destination unreachable. May indicate host unreachable, network unreachable, port unreachable, or other. | See traceroute section earlier. |
| 4 | Source quench (somebody telling destination "slow down; you're talking too fast"). | Should usually be allowed in both directions. |
| 5 | Redirect (somebody telling destination to change a route); is supposed to be ignored by your systems unless it comes from a directly connected router. In particular, make sure the routers that are part of your firewall ignore it. | Should usually be blocked inbound. Definitely block to routers that are part of your firewall. |
| 8 | Echo request (generated by ping). | See ping section earlier. |
| 9 | Router announcement (used by router discovery). | Should be blocked in both directions (see router discovery section earlier). |
| 10 | Router selection (used by router discovery). | Should be blocked in both directions (see router discovery section earlier). |
| 11 | Time to live exceeded (packet appears to be looping). | Should usually be allowed in both directions. |
| 12 | Parameter problem (problem with a packet header). | Should usually be allowed in both directions. |
22.4.4. Summary of Recommendations for ICMP
- Allow ICMP echo requests outbound but limit incoming ICMP echo requests to those that are coming from machines with a legitimate need to probe your network (such as your network service provider's network operations center) and are bound to hosts known to have hardened network stacks. Allow ICMP echo responses either way, but only if they match recent requests.
- Allow traceroute outbound, but limit incoming traceroute requests to those coming from machines with a legitimate need to probe your network and limit the port range used.
- Look for a router that will allow you to sanity-check ICMP packets, and reject obviously malformed or malicious packets regardless of their source and destination.
- Allow only safe ICMP message types, as described previously.
|  | |
| 22.3. Protocols for Booting and Boot-Time Configuration |  | 22.5. Network Time Protocol |
