iptables | Types of ICMP: which ones are (potentially) harmful?

Question

I read that certain types¹ of ICMP packets can be harmful. Questions:

• Which ones and why?
• How should I layout an iptables ruleset to handle each type of ICMP packet?
• Should I rate-limit any of these types of ICMP packets? And how?

[¹] The types I read about: Redirect (5), Timestamp (13) and Address Mask Request (17). Please don't consider just these on your answer.

More info
It's a web server on a VPS with Ubuntu Server.

The goal
I'm trying to make the system safer, mitigate the risk of some D/DoS attacks and general abuse.

Related
Is my linux firewall secure?
Why not block ICMP?

Solution 1

It sounds like you are falling victim to the "ICMP IS EVIL" mantra.
ICMP is NOT evil, merely misunderstood. The sad reality is that many admins fear what they do not understand, and so they cast ICMP out of their network universe, shunning it at the edge firewall level and preventing it from taking its right and proper place for the benefit of their network.

Having said that, let me address your questions:

---

Which types of ICMP messages can be harmful, and why?
Pretty much all of them.

• Echo packets can be used to disrupt services (especially for systems with badly implemented IP stacks); Used legitimately they can give information about your network.

• Destination Unreachable can be maliciously injected ; Used legitimately they can give information about * your firewall/routing structure, or about a specific machine on your network.

• Source Quench can be maliciously sent to make your server effectively sit in a corner and suck its thumb.

• redirect can be used as the name implies.

• router advertisement and router solicitation requests can be used to create "interesting" traffic topologies (and facilitate MITM attacks) if your hosts actually pay attention to them.

• traceroute is designed to give network topology information.

…etc...

The names of the various ICMP messages pretty much detail what they are capable of doing. Exercise your innate paranoia in dreaming up nightmare scenarios :-)

---

How should I layout an iptables ruleset to handle each type of ICMP packet?
Absent a good reason to mess with ICMP traffic, leave it the hell alone!
Mucking about with ICMP traffic prevents the appropriate uses of ICMP messages (traffic management and troubleshooting) - it will be more frustrating than helpful.

---

Should I rate-limit any of these types of ICMP packets? And how?
This may be the only legit exception to the "leave it the hell alone" philosophy -- rate- or bandwidth-limiting ICMP messages can be useful in helping you evade illegitimate uses of the ICMP messages. FreeBSD ships with ICMP Bandwidth / Rate Limiting by default, and I assume Linux has similar functionality.

Rate/Bandwidth limiting is far preferable to a blanket firewall rule dropping ICMP traffic: It still allows ICMP to serve its purpose on the network, and also partially mitigates attempts to abuse your server.

---

The above represents the opinions of one sysadmin, who for his part is FREAKIN' TIRED OF HAVING TO TROUBLESHOOT NETWORKS WHERE ALL ICMP TRAFFIC IS DROPPED -- It's annoying, frustrating, and makes it take longer to find and fix problems. :-)

Solution 2

It is not as much about types than possible attack vectors. There has been a rather effective DoS attack vector using the ICMP source quench packet in many common internet host's TCP/IP stacks for years - and yet it does not mean that source-quench ICMP messages need to be filtered in general. As with everything in network security, weigh the benefit of a certain protocol or service against the possible attack surface based on your personal priorities. If you have hosts in your networks which are susceptible to an attack vector through ICMP, you can't fix them and you do not need the specific features, you certainly should consider filtering it.

For my administered v4 networks I've found it both safe and convenient to allow ICMP types 0, 8 (echo request / reply), 11 (TTL expired), 3 (destination unreachable) and 12 (IP header error) and to drop all the rest.

Comments

[ravi yarlagadda]

But.. but.. the Ping of Death is to be feared, to irrational levels! (is it bad that I could tell who wrote this answer after the first paragraph?)

[ML--]

Indeed, ICMP is useful. If I was a victim of "ICMP is evil", I would rather block all and not open this question :) All I want is some help to make an informed decision. You can be sure that I'm not going to block them all :)

[ML--]

@Shane Madden: Will --state INVALID drop Ping of Death?

[ravi yarlagadda]

@ML-- Please don't worry about the ping of death. No OS from this millennium is vulnerable.

[voretaq7]

@ShaneMadden It took you a whole paragraph? :-)

[voretaq7]

@ML-- The one vector I'd be worried about is Source Quench, and you can block that with relative impunity (TCP will eventually figure it out for itself). Ping & Traceroute are definitely information leaks, but in practice I don't think it adds too much real security to your environment. Your mileage (and required level of paranoia) may vary (depending on the sensitivity of your data/environment).