People tend to have ICMP unreachables disabled (“no ip unreachables” under the interface configuration on Cisco IOS boxes) in their security templates. I would like to explain why this is not needed (anymore) and what disadvantages this can bring.
Denial of Service attacks are common these days, but ICMP unreachables are about smurf attacks, explained at cisco.com:
A DoS attack occurs when a stream of ICMP echo requests (pings) are broadcast to a destination subnet. The source addresses of these requests are falsified to be the source address of the target. For each request sent by the attacker, many hosts on the subnet will respond flooding the target and wasting bandwidth. The most common DoS attack is called a “smurf” attack, named after an executable program and is in the category of network-level attacks against hosts. DoS attacks can be easily detected when error-message logging of the ICMP Unreachable Destination Counters feature is enabled.
However, we have 2009 now and smurf attacks mostly disappeared from the internet. Cisco introduced the no ip directed-broadcast command in IOS version 10.0, defaulting it in 12.0, like proposed in RFC2644 (back in 1999!). This prevents the network from taking part in a Smurf attack. “no ip unreachbles” prevents the router from sending ICMP replays for not existing hosts in the subnet, which can be a good thing. However, ICMP rate-limiting is even better and IOS does ICMP rate limiting by default (one ICMP Packet every 500ms per interface). This should be enough to prevent the router from hugging CPU or flooding other (spoofed) hosts because of ICMP packets (both ICMP unreachables and standard replays).
I hope the security concerns are gone now.
So here comes the bad thing about disabling ICMP unreachables:
- Troubleshooting of routing problems can become a nightmare when routers doesn’t throw unreachables.
- You will break PathMTU, because a ICMP fragmentation needed (type 3, code 4) packet belongs to ICMP unreachbles (type 3). Check this article. Breaking PathMTU is a bad thing.
Final Words
Disabling ICMP unreachables won’t bring you any security benefits; it will just break several techniques depending on it, like traceroutes and PathMTU.
Update: My colleague kindly made me aware that the last statement isn’t entirely true. Disabling ICMP unreachables can increase security:
- An attacker could gather information’s about your network when scanning it, like unused IP’s and networks.
- When working with (interface-) Access-Lists, a deny statement triggers an ICMP Type 3 Code 9/10 message (Network/Host is Administratively Prohibited). When disabling ICMP unreachables on the interface where the ACL is applied, the deny statement acts like a ‘drop’ and does not reply.
We all know that security through obscurity is a bad thing (or at least heart of the saying), but personally, I don’t like my deny statements to be propagated over the Internet. This would be the case when configuring ACL’s on the Internet-facing interface on a VPN/NAT Router.
Even though your article may have been fully correct in 2009, some developments happened that may require a minor adaptation.
Indeed SMURF attacks are not something that we worry about much anymore, however other forms of DDoS are on the rise.
Letting your router return ‘icmp unreachable’ messages, will inform an attacker about hosts in your network and at the same time it let’s an attacker know that your router is spending CPU cycles on him.
One of the focus fields of DDoS attackers is DDoS on infrastructure. They can either flood your pipes, but they could also exhaust your routers’ CPU resources by sending a lot of (potentially spoofed) packets to non-existent hosts in your network. If you don’t send back ‘icmp unreachables’ for non-existent hosts, then you are keeping an attacker “in the dark” as to whether his attack is being succesful and he might move on.
Breaking path mtu discovery is not nice, so you could work around that particular issue by controlling which particular icmp unreachables should go unanswered.
On Brocade you can control the types of messages on the global or interface level:
! don’t send back info on non-existent hosts
no ip unreachables host
! do send back a message when fragmentation is needed (path mtu discovery will continue working)
ip unreachable fragmentation-needed
! enable or disable other ip unreachable messages per your own needs
On Cisco you cannot control the specific type of message on the interface level (yet). ip unreachables are configured as on or off. You can however limit what gets sent back to the source by applying extended ACL’s:
! don’t break path mtu discovery
access-list 100 permit icmp any any packet-too-big
! drop the rest
access-list 100 deny icmp any any net-unreachable
access-list 100 deny icmp any any port-unreachable
access-list 100 deny icmp any any host-unreachable
(…)
Frans
A Cisco router does not block packets it originates. To stop a Cisco router from sending responses outbound you need to use Output CoPP (control plane policing). Your router needs to support outbound CoPP. You can be pretty granular with IOS zone based firewall using the “self” zone too. The ACL method won’t work for the router the ACL is applied on.