Solved: Should I block icmp on my edge router or my firewall?

ttrevino1 · ‎10-09-2007

Originally, we were blocking icmp traffic on our edge router (2811), but recently we changed this to block on the firewall (ASA) instead. I've been told that blocking on the router would cause too much overhead on the router, since it's now having to inspect all traffic, and the firewall was better equipped for this.

What is industry standard? What does Cisco recommend?

mhellman · ‎10-09-2007

Something like this, although I would recommend posting this to the firewall forum for confirmation.

! deny non-initial ICMP Fragments

access-list 101 deny icmp any any fragments

! permit "dest unreachable" messages

access-list 101 permit icmp any any 3

! permit "Time exceeded" message

access-list 101 permit icmp any any 11

! permit "source quench" message

access-list 101 permit icmp any any 4

! permit "parameter problem" message

access-list 101 permit icmp any any 12

! permit "echo reply" messages

access-list 101 permit icmp any any 0

! deny all other icmp

access-list 101 deny icmp any any

You might consider tightening up the destination unreachables too. They would look something like this for each type and code you want to allow:

! permit "dest unreach - port unreach" messages

acccess-list 101 permit icmp any any 3 3

see here:

http://www.iana.org/assignments/icmp-parameters

View solution in original post

mhellman · ‎10-09-2007

There is no industry standard, however I would say that many companies do perform 'sanity' check ingress filtering at the edge. In any event, if blocking specific ICMP on the edge router really does cause too much overhead (I suspect you mean 'could' and not 'would') then what choice do you have short of getting a bigger router?

If your firewall is just the next hop in the network, blocking on the firewall might be acceptable. Your edge router can be protected against some attacks by simply having a hardened config (preventing ICMP redirects, etc).

ttrevino1 · ‎10-09-2007

I actually need to make a correction. I verified and we are currently allowing icmp to the outside interface of our firewall.

The router we have was just replaced Sunday, and is now the 2811 I mentioned. I haven't noticed any additional slowness either before or after the change, other than ping sweeps in the firewall logs.

So at a minimum, this type of traffic needs to be blocked on the firewall? There are 2 differing opinions here on where to block this traffic, such as router routes traffic, and shouldn't be used to block traffic, that's the firewalls job. Others, as you mentioned, say harden the outside as well, to minimize the amount of "malicious" traffic getting to the firewall. I don't want to overload the router, but do want to do what's best for the company.

Collin Clark · ‎10-09-2007

We are required by our security policy (and the DoD) to block certain incoming ICMP at the border router. All firewalls block/drop ICMP packets. When in doubt, we follow NIST standards. Check out http://iase.disa.mil/stigs/stig/index.html for more information.

HTH and please rate.

mhellman · ‎10-09-2007

We're speaking very broadly about traffic, ICMP in particular. ICMP is a required and useful network protocol. Do you mean ICMP echo requests specifically?

My point about ingress filtering is that it is not uncommon to do limited filtering at the edge anyway (drop RFC1918 sources, etc). If you have an ACL already, adding a couple entries for specific ICMP types should not add that much of a burden. If your firewall is the next hope in the path to your internal or DMZ networks, then doing this on the firewall instead of the edge router may also be acceptable. You'd just need to carefully configure and protect the router.

ttrevino1 · ‎10-09-2007

This is the portion of the acl that was related to icmp, aside from a couple of specific IPs being allowed to ping each other. The firewall is the next hop after the edge router, and I do plan on adding icmp blocking on there sometime soon.

access-list 101 deny icmp any any

access-list 101 deny icmp any any timestamp-request

access-list 101 deny icmp any any mask-request

mhellman · ‎10-09-2007

That's an interesting ACL;-)

You shouldn't need lines 2 and 3, since line 1 already denies any ICMP. But perhaps something was lost in the translation. You might consider allowing the following and then having a "deny icmp any any":

destination unreach (host,network,port,MTU) = type 3

time exceeded = type 11

source quench = type 4

parameter problem = type 12

echo replies (maybe) = type 0

ttrevino1 · ‎10-09-2007

Thanks for the advice, I did figure the top line covered the other 2, but am still getting used to acls. :)

How would you put your suggestion into an acl? In other words, what would the commands be for this? Thanks again, T

mhellman · ‎10-09-2007

Something like this, although I would recommend posting this to the firewall forum for confirmation.

! deny non-initial ICMP Fragments

access-list 101 deny icmp any any fragments

! permit "dest unreachable" messages

access-list 101 permit icmp any any 3

! permit "Time exceeded" message

access-list 101 permit icmp any any 11

! permit "source quench" message

access-list 101 permit icmp any any 4

! permit "parameter problem" message

access-list 101 permit icmp any any 12

! permit "echo reply" messages

access-list 101 permit icmp any any 0

! deny all other icmp

access-list 101 deny icmp any any

You might consider tightening up the destination unreachables too. They would look something like this for each type and code you want to allow:

! permit "dest unreach - port unreach" messages

acccess-list 101 permit icmp any any 3 3

see here:

http://www.iana.org/assignments/icmp-parameters

ttrevino1 · ‎10-09-2007

Thanks for the help, that really does make it more clear. I appreciate the help!