Allow ICMP type 11 on outside_in ???

[tr_onlinepos_dk]

Hi.

I get a lot of ICMP deny in our firewall log - Typically type 11,0 like this:

Deny icmp src outside:77.243.33.157 dst Support_Net:10.10.60.206 (type 11, code 0) by access-group "outside_access_in" [0x0, 0x0]

Q1) Should i allow these Time Exceeded messages ?

Q2) Are there any ICMP types that should be denied - For security reasons, like allowing external hosts to probe for topology, hosts or alike ?

I cant completely get my head around if any of the ICMP's can be fired/faked from outside and return something harmful, so i though I'd ask the pros.

[Rob Ingram]

Hi, at first glance I'd say that someone on 10.10.60.206 inside your network was tracerouting to 77.243.33.157 and the response is blocked, hence why you receive a ICMP Type 11.You may or may not want to permit this as this can aid troubleshooting. 

If you did want to allow outbound traceroute you could do "access-list OUTSIDE_IN permit icmp any any time-exceeded".

HTH

[Dennis Mink]

i would argue dont allow anything unless functionally necessary, so 80 and 443 for your webservers for instance. if its not funcvtional to your organisation; block it, including ping inbound.

[tr_onlinepos_dk]

I agree and that is also practice, but I'm still interested in why this shows up - Especially whether or not it is initialized by inside hosts.

I don't believe that users purposely use traceroute, since it has no meaning in there jobs, but you never know..

I will ask around

[James Leinweber · Accepted solution]

---

Q1) Should i allow these Time Exceeded messages ?

---

Probably; I do.

---

Q2) Are there any ICMP types that should be denied - For security reasons, like allowing external hosts to probe for topology, hosts or alike ?

---

For proper operation of your internet clients, some ICMP ought to be allowed. This is true of IPv4 and absolutely necessary for IPv6, where IPv4 ARP was replaced by IPv6 ICMP neighbor discovery, ICMP router advertisements are required on-link, and PTMU discovery Really Matters.  The difficulty is that lots of other ICMP should be blocked, and you may be receiving ICMP from hosts like routers that aren't the endpoints of the communication, which increases spoofing risks.  In general most firewalls aren't smart enough to block ICMP when there isn't a XLATE entry for communication by an inside host, which increases the spoofing risk still more.  Plus the answers differ slightly for IPv4 ICMP (protocol 1) and IPv6 ICMP (protocol 58).

What I allow is along the lines of:

object-group service OK-ICMP
 service-object icmp unreachable
 service-object icmp time-exceeded
 service-object icmp source-quench
 service-object icmp parameter-problem
object-group service OK-ICMP6
 service-object icmp6 unreachable
 service-object icmp6 time-exceeded
 service-object icmp6 parameter-problem
 service-object icmp6 packet-too-big
 service-object icmp6 echo

Obviously, it also helps to have a global service policy that is inspecting ICMP.  My ICMP echo-request/echo-reply policy on IPv4 is complicated depending on whether or not the sender is on the general internet, our campus, our wifi, or inside our organization. Basically only the deliberately exposed DMZ servers allow arbitrary inbound echo-request (ping).  Block all other ICMP from the general internet, particularly on IPv6, unless you are using it.  E.g. ICMPv6 type 138 router renumber is not something you should be believing from just anyone (the RFC notes it should be secured by IPsec if you are using it ...)

[tr_onlinepos_dk]

Thanks.

This was pretty mutch what i was looking for

Great example with the object groups