Block ICMP?

[killabee]

As it pertains to internal firewalled servers/networks, how do you guys handle ICMP traffic? Do you implicitly block it, explicitly permit it, or what do you do?

It seems like the "security" rules for handling ICMP traffic has changed, and I've seen several comments on the Internet that suggest that blocking ICMP nowadays is either a bad idea, a dumb idea, or
just not needed.  I want to hear your take on it.  My take is that...they're right.  From my limited security knowledge, blocking ICMP does very little considering what the attack surfaces and methods are nowadays.  If anything, blocking ICMP hinders troubleshooting and problem resolution, and prevents certain network functions from working (e.g. PMTUD, etc when the appropriate ICMP codes/types aren't permitted).

What's your take?

[Fred]

It's a good question.

Blocking inbound ICMP from the Internet seems like a nobrainer. I allow it to my edge routers, but no further.

Blocking outbound ICMP to the Internet. I used to be an advocate of leaving this open for the reasons you cited, but seeing some recent attacks that tunnel over ICMP echos, I've changed my stance.

But purely internal traffic? I'm still on the side of leaving it open.

[icecream-guy]

Blocking ICMP tends to break things.   ICMP has many message types, some are good, some not so.  with a blanket statement to block or no block ICMP  does not justify.  you need to consider the message types, and allow certain ICMP messages  (i.e. 0,8,11) to make things work.


I used to work for a (security) company where ICMP was denied across the network by policy.  made troubleshooting a nightmare.

[NetworkGroover]

Blocking ICMP tends to break things.   ICMP has many message types, some are good, some not so.  with a blanket statement to block or no block ICMP  does not justify.  you need to consider the message types, and allow certain ICMP messages  (i.e. 0,8,11) to make things work.


I used to work for a (security) company where ICMP was denied across the network by policy.  made troubleshooting a nightmare.

That would make me a sad panda. 

[Otanx]

As ristau said ICMP is made up of multiple types. Asking should we block ICMP? is about the same as asking should we block TCP? Treat ICMP just like all other protocols. Anywhere you are filtering TCP/UDP you should also be filtering ICMP. Just completely blocking ICMP breaks a lot of stuff that are expected to work. Type 3 Code 4 is important if you want path MTU discovery to work. Not allowing this can cause some weird failures that take a long time to troubleshoot. Blocking host unreachable ICMP messages can cause systems to take excessive time to fail over to a secondary host as it waits for time outs. To start I think Type 0, 3, 8, and 11 are the important ones to allow. Under Type 3 you could limit what codes you want to allow if you want to get granular.

-Otanx

[Reggle]

I've worked with companies where all ICMP is blocked by default. Works fairly well in environments with the same MTU.
Despite it, I'm currently in favor of allowing certain types: echo, MTU, TTL expired. Also, I tend to allow it one-way only for echo: from infrastructure and servers towards all, not from clients towards servers.
So yes, like TCP & UDP firewall rules.

[wintermute000]

IPv6 breaks horrifically if PMTUD is broken
Also uses ICMP for core parts of the protocol like neighbor discovery

I tend to take the view that as long as echo / traceroute is blocked ingress from external that's good enough but Im a router guy and I just want things to work

[deanwebb]

Hello. I'm a security guy.

BLOCK IT!!!! AIIIEEEE!!!!

Well, actually, there can be legit uses for it, but I can take down a manufacturing system with a well-designed ICMP attack. One shot to a sensitive device and down it goes. The well-designed attack? A ping of doom: basically, an ICMP type 8 packet that is big enough to be fragmented. Most modern devices are immune, but there are enough legacy systems that can't be patched in manufacturing environments that are still susceptible. Also, that Internet of Things? How many of those internet-enabled doodads are built with a fortified OS that will be resistant to a ping of doom?

We security guys want things to work, too, but after they've been made safe. 

[dlots]

we permit echo requests and responses, but block things like type 3 code 3 or anything else saying it can't be reached.

[Fred]

I'm not convinced that PMTUD works reliably enough right now with IPv4 to be counted upon, and I don't expect this to change. Right now, it's on the client side to work around it when it's broken, which is almost always.

I've heard that it breaks IPv6, but I've not seen compelling evidence that the situation will be reversed. Anybody have more information on this?

[wintermute000]

it definitely breaks IPv6. There is no fragmentation on layer 3 devices, only hosts may fragment.

[killabee]

I'm not convinced that PMTUD works reliably enough right now with IPv4 to be counted upon, and I don't expect this to change. Right now, it's on the client side to work around it when it's broken, which is almost always.

Exactly! I too have heard the same about PMTUD. 

[Network2501]

I'm not convinced that PMTUD works reliably enough right now with IPv4 to be counted upon, and I don't expect this to change. Right now, it's on the client side to work around it when it's broken, which is almost always.

I've heard that it breaks IPv6, but I've not seen compelling evidence that the situation will be reversed. Anybody have more information on this?

Do you think it's not reliable because existing networks don't support it well? whether that's firewalls or other factors.

[Otanx]

Mainly firewalls, and poor security policies that don't allow it to pass. It leads to a lot of weird issues. One I remember recently was a SQL server that would work with some queries, but not others. It turned out the queries that worked all returned only one or two rows. The ones that didn't returned larger results. As long as the query response was under the lowest MTU on the path it worked. Once the return went above I think it was 1320 bytes it stopped working. The users thought the problem was with their SQL statements, and it took awhile before they started looking in other places.

-Otanx

[killabee]

I'm not convinced that PMTUD works reliably enough right now with IPv4 to be counted upon, and I don't expect this to change. Right now, it's on the client side to work around it when it's broken, which is almost always.

I've heard that it breaks IPv6, but I've not seen compelling evidence that the situation will be reversed. Anybody have more information on this?

Do you think it's not reliable because existing networks don't support it well? whether that's firewalls or other factors.

All of the above.  I had to read Darren's (mellowd) MTU posts for a refresher.