ICMP Design Considerations
One way to spot inexperienced secure network design is to look for networks that completely block Internet Control Message Protocol (ICMP) traffic. As any operator of all but the smallest networks will tell you, troubleshooting a network without ping is very frustrating, bordering on impossible. That said, ICMP messages should not be enabled everywhere without reservation. Some security considerations must be understood, just like for any other protocol. This section assumes basic ICMP understanding. Refer to your favorite TCP/IP book for background or read RFC 792.
ICMP security can be a very lengthy discussion because lots of nasty things can be done with ICMP messages when scanning networks or trying to gain a covert channel. If you are interested in this sort of thing, Ofir Arkin's paper titled "ICMP Usage in Scanning" is available at http://www.sys-security.com/archive/papers/ICMP_Scanning_v2.5.pdf. Rob Thomas has some guidelines for ICMP filtering that are available here: http://www.cymru.com/Documents/icmp-messages.html.
The basics behind ICMP design considerations are to define how much ICMP traffic you should allow on your network and which messages types you should filter.
ICMP Rate Limiting
Because ICMP is a troubleshooting and error-reporting tool, there should be a limit to the amount of ICMP traffic you see on a given network. For example, on a 100 Mbps Ethernet link, you might block ICMP traffic that exceeds 500 Kbps. A technology called committed access rate (CAR) enables this sort of filtering and is discussed later in this chapter.
ICMP Message Type Filtering
As Chapter 2 discussed, your own security policies and threat models might be different from those assumed here. Deploying filters throughout your internal network to permit only the ICMP message types required would be difficult. As a first step, focus on possible boundaries of trust between two networks. Your network will have its own trust boundaries, but here are a few to get you started. Zones of trust are detailed more fully in Chapter 12, "Designing Your Security System."
Internet and internal network
Management network and production network
Critical applications and production network
An easy first step in ICMP filtering is to deny any ICMP message that is a fragment. First, the ICMP messages you must permit are generally small. Echo and echo reply, for example, default on BSD UNIX to 84 bytes: 20-byte IP header, 8-byte ICMP header, and 56 bytes of ICMP data. Other required ICMP messages are similarly small and come nowhere near the minimum link size on today's IP networks. Blocking ICMP fragments is easy using an ACL:
access-list 101 deny icmp any any fragments
WARNING
The fragments keyword in a Cisco ACL has some special use rules. For a detailed discussion of this, including flow charts and examples, check the paper at the following URL: http://www.cisco.com/warp/public/105/acl_wp.html.
As a quick summary of the paper, the fragments keyword applies only to noninitial fragments (fragment offset > 0), so in the preceding example, the first part of a fragmented ICMP packet will not match that entry, while all subsequent fragments will.
When filtering ICMP messages between trust boundaries, apply the security principle "Expressly permit, implicitly deny." Though your specific requirements may vary, the following ICMP types should be permitted in some form:
ICMP echo request and ICMP echo reply
ICMP destination unreachable—fragmentation needed but DF bit set
ICMP time exceeded
ICMP Echo Request and ICMP Echo Reply
ICMP echo request (Type 8 Code 0) and ICMP echo reply (Type 0 Code 0) are better known as the message types used by the ping command. The format of an ICMP echo message has the standard 8 bytes of ICMP header information and then allows for a variable-length data field that can contain any kind of data. Certain size ping packets caused system crashes on some older OSs. This attack was commonly called the Ping of Death. More information can be found here: http://www.insecure.org/sploits/ping-o-death.html. Permitting ICMP echo can lead to DoS attacks and buffer overflows as discussed in Chapter 3. It can also lead to a covert channel because information can be embedded into the data field in the ICMP echo message. An attacker that installs special software on a host internal to your network could communicate back and forth using only ICMP echo request or reply messages. Covert channels have been implemented in many different protocols, and they are impossible to completely eliminate. So, with these risks, it is understandable why a security engineer would want to stop ICMP echo messages. Unfortunately, troubleshooting would be far too difficult without it making your overall network less secure in most cases. With all that said, here are the best practices:
Permit ICMP echo request messages to leave your network destined for any network you have reason to communicate with.
Permit ICMP echo reply messages to your internal hosts from any network you have reason to communicate with.
Permit ICMP echo request messages from external hosts to servers they must access (public web servers, for example). As of this writing, a random sampling of top websites yielded several that block inbound pings to their servers and several more that permit them. As an organization, you must weigh the risks of allowing this traffic against the risks of denying this traffic and causing potential users troubleshooting difficulties.
Permit ICMP echo reply messages from any server system to the networks where that server's users reside. Echo replies from your public web server to the Internet at large is an example of this.
Deny every other ICMP echo message.
As an example, consider the very simplified Internet edge shown in Figure 6-15.
)
Figure
6-15 Simple Internet Edge
If you were writing ICMP echo access lists for router "police," the inbound Serial0 ACL would look like this:
! permit echo-request to Serial0 interface of the router access-list 101 permit icmp any host 192.0.2.2 echo ! permit echo-request to public server access-list 101 permit icmp any host 126.0.64.10 echo ! permit echo-reply from anywhere to the internal network and the public server access-list 101 permit icmp any 126.0.128.0 0.0.0.255 echo-reply access-list 101 permit icmp any host 126.0.64.10 echo-reply
The ACL on the inbound Ethernet0 interface would look like this:
! permit echo-request from the internal network to anywhere access-list 102 permit icmp 126.0.128.0 0.0.0.255 any echo
The ACL on the inbound Ethernet1 interface would look like this:
! permit echo-request from the public web server to anywhere access-list 103 permit icmp host 126.0.64.10 any echo ! permit echo-reply from the public web server to anywhere access-list 103 permit icmp host 126.0.64.10 any echo-reply
Based on these ACLs, internal users can ping the web server and the Internet, the Internet can ping the web server, and the web server can ping the Internet. Of special note is that the web server cannot ping internal hosts. Based on your security policies, you can permit this to aid in troubleshooting, but be aware that many organizations consider public servers to be not much more trusted than the Internet. To make the change, you would add this line to the Ethernet0 ACL:
access-list 102 permit icmp 192.0.128.0 0.0.0.255 host 192.0.64.10 echo-reply
NOTE
Cisco router ACLs can be applied inbound or outbound on a given interface. Security folks, myself included, tend to prefer inbound ACLs, but there are situations in which you must use both and situations in which an outbound ACL makes more sense. I prefer inbound because the packets are blocked before they cross the router. Outbound ACLs allow the packet to be routed by the router and then are blocked when they try to leave. This could leave the router open to certain attacks.
Another special note on Cisco ACLs is that ACLs never apply to traffic generated by the router. So, even if you have an inbound and an outbound ACL on a router denying all traffic, the router will still be able to send any packet it wants; the return packet, however, will be blocked as usual.
ICMP Destination Unreachable—Fragmentation Needed but DF Bit Set
ICMP destination unreachable messages (type 3 code 0–15) are a whole range of messages designed to alert the sending system that something is wrong with a particular message sent. This includes specific errors such as network unreachable (code 0), host unreachable (code 1), protocol unreachable (code 2), and port unreachable (code 3). These types of messages are generated by hosts and routers when a sending system tries to go somewhere that is unreachable for whatever reason. Many security administrators block most type 3 messages because the sending host will often figure out that the service is unavailable on its own without the benefit of the ICMP message (albeit more slowly). One message is required though: "fragmentation needed but DF bit set" (type 3 code 4). This message is required for path Maximum Transmission Unit (MTU) discovery to work. Path MTU discovery is the method most hosts use to determine the IP MTU size for their traffic. Without it functioning properly, large TCP segments could be dropped without a means to remedy the problem because the offending host never knows why the drop occurs.
Path MTU discovery has some interesting implications in IPsec and is discussed in more detail in Chapter 10, "IPsec VPN Design Considerations."
ICMP type 3 code 4 messages can be easily permitted by adding the following line to the ACLs built for Figure 6-15:
access-list 101 permit icmp any any packet-too-big
ICMP Time Exceeded
ICMP time exceeded: Time-to-Live (TTL) equals 0 during transit (type 11 code 0) is required because it is used by traceroute. To permit these messages, add the following line to the ICMP ACLs you have seen in this section:
access-list 101 permit icmp any any time-exceeded
ICMP Filtering Recommendations
As you can see, there was a reason that ICMP was created beyond as a playground for attackers. Although most of the 15 ICMP message types can be blocked, several are necessary to the healthy operation of a network. We can rebuild the previous ACLs to allow all the messages we discussed, to block fragments, and to deny any other ICMP messages. Those ACLs are as follows.
Router "police" Serial0 ACL, inbound:
! deny non-initial ICMP Fragments access-list 101 deny icmp any any fragments ! permit echo-request to Serial0 interface of the router access-list 101 permit icmp any host 192.0.2.2 echo ! permit echo-request to public server access-list 101 permit icmp any host 126.0.64.10 echo ! permit echo-reply from anywhere to the internal network and the public server access-list 101 permit icmp any 126.0.128.0 0.0.0.255 echo-reply access-list 101 permit icmp any host 126.0.64.10 echo-reply ! permit "fragmentation needed but DF bit set" message access-list 101 permit icmp any any packet-too-big ! permit "Time exceeded" message access-list 101 permit icmp any any time-exceeded ! deny any other ICMP message access-list 101 deny icmp any any ! from here you would continue with other non ICMP related ACL entries
Router "police" Ethernet0 ACL, inbound:
! deny non-initial ICMP Fragments access-list 102 deny icmp any any fragments ! permit echo-request from the internal network to anywhere access-list 102 permit icmp 126.0.128.0 0.0.0.255 any echo ! permit "fragmentation needed but DF bit set" message access-list 102 permit icmp any any packet-too-big ! permit "Time exceeded" message access-list 102 permit icmp any any time-exceeded ! deny any other ICMP message access-list 102 deny icmp any any ! from here you would continue with other non ICMP related ACL entries
Router "police" Ethernet1 ACL, inbound:
! deny non-initial ICMP Fragments access-list 103 deny icmp any any fragments ! permit echo-request from the public web server to anywhere access-list 103 permit icmp host 126.0.64.10 any echo ! permit echo-reply from the public web server to anywhere access-list 103 permit icmp host 126.0.64.10 any echo-reply ! permit "fragmentation needed but DF bit set" message access-list 103 permit icmp any any packet-too-big ! permit "Time exceeded" message access-list 103 permit icmp any any time-exceeded ! deny any other ICMP message access-list 103 deny icmp any any ! from here you would continue with other non ICMP related ACL entries
NOTE
If you want to get very picky, you could probably block the packet-too-big and time-exceeded messages from being generated by either the public server segment or the internal network, depending on the rest of your configuration. With protocols such as ICMP (which are often used in troubleshooting), you are probably better off following the KISS principle by making your ICMP filtering consistent as much as possible.