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

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.