Security risk of allowing ICMP "destination unreachable" packets on AWS

Question

If I configure an Amazon AWS VPC, should I explicitly allow ICMP "destination unreachable" packets inbound? I am wanting the VPC firewall to block everything by default, however does this mean this (potentially) breaks things for DSL traffic? Does the stateful firewall let these packets back in, whereas the ACLs used on VPC subnets, because it is stateless, does not?

I suppose my main question is why isn't this a default rule if it is safe? - Mark's current answer says ICMPTX is not a real threat on a network that you have control of.

In Thomas Pornin's answer on Security risk of PING he states:

Some ICMP packet types MUST NOT be blocked, in particular the "destination unreachable" ICMP message, because blocking that one breaks path MTU discovery, symptoms being that DSL users (behind a PPPoE layer which restricts MTU to 1492 bytes) cannot access Web sites which block those packets (unless they use the Web proxy provided by their ISP).

How likely are the default rules to break things if blocking ICMP "destination unreachable" as Thomas points out? Should time and effort be spent to explicitly allow these on each VPC and subnet firewall and ACL rule?

I found this interesting article on the topic:

There are a few common causes for not being able to get the ICMP replies necessary for PMTUD [Path MTU Discovery] to work. Overzealous network administrators will configure their firewalls to drop all ICMP since certain ICMP messages are considered security threats. Routers are sometimes (mis) configured with PMTUD disabled and so will simply drop the packet without sending the required ICMP message.

If ICMP blocking is so common on AWS and other cloud and non cloud hosting providers, why do we not see more black hole problems? If it is not a widespread problem, and many people are on DSL using PPoE it seems sensible to leave it blocked as the default.

Answer 1

There are no reasonable implications for DSL users with blocking INBOUND ICMP messages (of any kind, really) for your services hosted in an Amazon cloud instance. The reason there's no issue for you to block them is because the Amazon infrastructure outside your private cloud will handle that for you... after all, the MTU within your private cloud cannot exceed the minimum MTU of the route path between your prospective clients and your servers.

The only time an ICMP unreachable inbound to you should occur is if your server(s) are trying to reach a destination address for some reason and a device in the path that is authoritative for routing to that destination address decides it cannot reach it. If your server is responding to a prospective client and you receive an ICMP destination unreachable then the "client" is likely malicious and is spoofing their source address. This should be apparent because if it were a legitimate address that was routed to you there is almost assuredly a path back!

Be cautious with a default BLOCK-ALL policy on AWS instances. I put an explicit allow-my-management-IP on SSH and block everything else once - and I bricked my instance! This is because there are certain DHCP and "Amazon"-related communications that your device must support in order to be able to communicate. The same is likely in a virtual private cloud instance.

I non-concur with munkeyoto's assertion that there is "no risk" to allowing outbound destination unreachable messages. Mainly for the reasons outlined by Mark and Jim. Attackers will use whatever you give them... If they only need to leak a password they can do so through flags and capitalization of ICMP message data so only a few of these messages would be necessary (assuming they didn't use a blast-out-all-data-at-once approach).

Answer 2

"ICMPTX" is a very, very minor risk in most real-world situations. It's basically a way for two cooperating programs to sneak data past a firewall that's only looking for data exfiltration over traditional protocols (TCP, UDP, etc.). Unless your AWS VPC is infested with malware and your firewall is inspecting packets for attempted data exfiltration, I wouldn't worry about it.

Answer 3

The general "risk" of ping is worrying about someone using the icmp protocol to either exfiltrate data or control malware. I think many times it was disabled as an "I don't know why I need it so I'll disable it mentality". This is why it became the default rule. While these are both real valid concerns if you are still in the "I have a perimeter" mentality (as opposed to "I have data security, so identity is my perimeter"), those same concerns apply to every port/protocol that can go in and out. ICMP got picked on in IPV4 because while it was a nice to have, not having it mostly only annoyed network admins.

In IPV6 allowing ICMP is not only the default but required for several reasons such as fragmentation only happening at the source (with icmp sending a type 2 message back to the host), SLAAC and NDP are ICMP messages as well.

Answer 4

There is no risk associated with disabling OUTBOUND destination unreachable packets. Let's have a look at why: Your machine makes a determination that something cannot be reached FROM your machine: "What is the significance of what you are explicitly blocking?" Cisco suggests blocking destination unreachables, because an attacker can cause your machine to repeatedly send out messages which can overwhelm your equipment. Consider the following attack:

Attacker (2.3.4.5) --> (spoofs 8.8.8.8) --> your server (N amount of times)
Your server --> destination unreachable --> 8.8.8.8

On the OUTBOUND side of the equation, what purpose does this VPC serve? For example, if the VPC has a specific connection: Point A <--> VPC what difference does it make if all else is blocked. This is something only you can answer for. It all begins with what is the purpose of the VPC, who, and how does it need to connect (to and from).

Generally you want to avoid creating too many rules, it becomes cumbersome to manage, so a more appropriate rule would be something like:

allow -- icmp messages (all) -- from.my.trusted.blocks
deny -- icmp messages -- all

This ensures that any connections you specify will be able to receive messages for possible troubleshooting, while denying everything else. Two rules versus dozens|hundreds.