Filter ICMP traffic in the Cisco IOS

While ICMP is required for IP network traffic redirection and pinging hosts on your LAN or WAN, ICMP can also pose a security concern. David Davis tells you about the basics of ICMP and how to filter it properly in the Cisco IOS.

The Internet Control Message Protocol (ICMP) is not TCP and it's not UDP. However, ICMP is critical to the functionality of any IP network, such as your corporate network or the Internet. While ICMP is required for IP network traffic redirection and pinging hosts on your LAN or WAN, ICMP can also pose a security concern. In this article, learn the basics of ICMP and how to filter it properly in the Cisco IOS.

What is ICMP?

The Internet Control Message Protocol (ICMP) is based on RFC 792 and is used to send IP network errors and diagnostic messages. I have heard of ICMP referred to as the management protocol for IP networks. That is basically true as ICMP is used to communicate things like "host unavailable" and other errors. ICMP is most well known as being used to ping a host on your network. Depending on the version of traceroute used, ICMP may or may not be used for traceroute as well.

While many of us just associate ICMP with "ping," there is actually a lot to know about it. In fact, there are 42 types of ICMP traffic (you can view each of them at the IANA ICMP parameters site). For example, for a ping to work, your host needs to be able to send an ICMP echo (type 8); the host you are pinging needs to be able to receive the echo; that host needs to be able to send an ICMP echo reply (type 0); and your host needs to be able to receive it for your ping program to be able to respond that the host is alive (and a round trip time for that ping). Like UDP, ICMP traffic is an unreliable protocol with no guaranteed delivery.

What are the security issues with ICMP traffic?

On the typical LAN with a "soft core," ICMP traffic is typically unrestricted. Depending on the level of internal network security that you require, you may want to filter ICMP traffic on your LAN between subnets (regardless of the Internet). As ICMP traffic from a malicious attacker can be used to bring down your network, ICMP traffic needs to be strictly filtered when coming in from the Internet and, perhaps, when going out to the Internet.

ICMP traffic can be used not only to discover hosts on your network but also to flood your network with traffic. By not restricting the type and flow of ICMP traffic from the Internet, you increase the potential for a denial of service (DoS) attack by allowing ICMP traffic to flood your network and affect service to all network traffic from the servers.

To prevent these types of attacks, there are various solutions. Commonly, ICMP traffic is filtered with a firewall. That firewall could be a Cisco PIX, ASA, or a Cisco IOS router. Now, let's take a look at how Cisco IOS ACLs can be used to filter ICMP traffic.

How do I filter ICMP traffic?

When creating Cisco IOS ACLs, many admins start out with either:

access-list 101 deny ip ...

or

access-list 101 deny tcp ...

While these may be the two most common ways to filter network traffic with Cisco IOS extended ACLs, neither of these will work to filter ICMP. Additionally, no standard access list will work for ICMP specifically.

To filter ICMP traffic, you need to use an extended access list and start with something like this:

Filtering ICMP inbound and outbound traffic both to your network and the Internet are important, but the most important of the two is to properly filter ICMP inbound to protect your network.

Protecting a network from attack isn't as simple as adding a few network access-lists. In fact, there are entire books you can buy (like Cisco Press's Network Security Technologies and Solutions); there are guides you can download (like the NSA Router Security Guide); and there are certifications you can pursue (like the Cisco CCSP). I say that because the following ICMP inbound filtering ACLs are examples of how to filter ICMP to block certain traffic - but not necessarily the only ones that will "secure your network."

In the following inbound ACL filtering example, we are filtering ICMP echo, redirect, and mask-requests, while allowing other types:

Router(config)# access-list 100 deny icmp any any echo log

Router (config)# access-list 100 deny icmp any any redirect log

Router (config)# access-list 100 deny icmp any any mask-request log

Router (config)# access-list 100 permit icmp any 1.1.1.0 0.0.0.255

Of course, the ACL must be applied to your interface in the "in" direction.

In this example, any ICMP echo or echo-reply traffic will be allowed until it exceeds 16K, at which point it will be dropped.

Be careful with ICMP

ICMP traffic is critical network traffic, but it can also cause security issues if used against your network by a malicious attacker. In this article, you learned what ICMP was, how it can help you, and how to filter ICMP to prevent security holes and DoS attacks.

I think this is an overly simplistic article (sorry to say like many of these articles from this author). Many people will start blocking icmp in panic, which will break MTU path discovery at the very least. Another key thing not mentioned was "ip directed broadcast" - if you don't know what this is and you manage a network, you're a liability, not an asset!

I must say that it is articles of this kind(general coverage of a subject + few practical examples) that help me learn new things. I in the very least follow the links in the article and usually continue with a few google searches - you can't expect somebody to address a public of hundreds and present everyone with the exact thing he wants.
p.s. (the pdf linked here is a really nice document on security!) Thanks

I for one look forward to this author's articles. Now, having said that, are they always an "all encompassing" thesis on the given subject? No, but I would imagine that they are meant to stimulate thought and give some direction as to the methods used to handle the issue at hand.
And, come on ?judging a network professional?s merit based on one data point! Well, I think the readers here, all on their own, can judge who is and isn?t an ass et.