Why not block ICMP?
Solution 1:
ICMP is way, way more than "traceroute" and "ping." It is used for feedback when you run a DNS server (port unreachable) which, in a modern DNS server, may actually help select a different machine to query faster.
ICMP is also, as was mentioned above, used for path MTU discovery. Chances are your OS sets "DF" (don't fragment) on TCP packets it sends. It is expecting to get an ICMP "fragmentation required" packet back if something along the path fails to handle that size of packet. If you block all ICMP, your machine will have to use other fallback mechanisms, which basically use a timeout to detect a PMTU "black hole" and will never optimize correctly.
Additionally, you should ask yourself why you want to block ICMP. What specifically are you attempting to prevent here? It's pretty clear you don't understand what ICMP is used for, which is rather common. I'd be extremely cautious in blocking something you don't fully understand.
To make it even harder to learn about this, many common firewall books say "block ICMP" -- it's clear their authors have never read an RFC or had to solve issues surrounding such advice. It's bad advice to block all ICMP.
Now, rate limiting it can also hurt. If your machine is busy, or even if it's not, you can get a good amount of ICMP traffic. My web server probably gets about 10-100 ICMP packets per minute, most of which is PMTU discovery. Even if someone chose to attack my server with ICMP packets of some type, it's really not that big of a deal. If your machine accepts even one TCP connection (ssh, http, mail, etc) chances are that's a bigger attack vector than misunderstood ICMP ever will be.
Solution 2:
ICMP is used for a range of diagnostic (eg ping, traceroute) and network control (eg PMTU discovery) functions. Indiscriminate blocking of ICMP causes other people all sorts of heartburn, and unless you know exactly what you're doing, you should leave it alone.
Solution 3:
I've never understood why people clock ICMP, as said above it only ever causes headaches to yourself and others. You can determine if a host is up easily enough and so long as it is limited enough as not to be used as a DOS then I've never heard any compelling reasons to block it. (If someone can come up with a reason please post)
Solution 4:
you could just try limit-ing icmp that way it can't be used as a DOS attack. but there are way too many troubleshooting tools like ping, mtr (I forget windows equivalent), traceroute (tracert), that use icmp. dropping them entirely is just foolish. It's a good way to check if your instance is up even though you can't telnet on any ports.
--limit 10/secondSolution 5:
Here's an alternate viewpoint, in the spirit of what security theory would suggest. Other posters are right that security practice is often overzealous, but there is a good basis to much of it.
The security theory is generally that you only enable WHAT YOU NEED. Other things (which could be useful - e.g., ping responses) can be used by an attacker to scope out your system, or possibly as an attack vector for some yet-to-be-discovered vulnerability.
So, looking at ICMP message types, what do you NEED for normal, proper operation of your system?
- echo reply (ping) - not so much
- destination unreachable - lots of useful information in here. Disable this and you will break access to your server for some clients.
- source quench - deprecated since 1995, and apparently removed from host implementations since (at the latest) 2005. tools.ietf.org/html/rfc6633#section-1.
- redirect - almost certainly not
- router advertisement & solicitation - no need if you statically configure your routes, and could be used for DoS. I'd block it unless you know you need it, and if you need it, perhaps code a rule to accept info from only the possible known routers.
- ttl exceeded - not just for traceroute, tells you your traffic isn't getting through to its destination
...and so on. If you really want to understand this, go learn about the various ICMP types and what they are for. The wikipedia article is a good starting point.
In practice, the really ugly one is redirect; if you want to just do something quick and useful, block that and allow the rest.
I would add that IPtables connection tracking will allow the appropriate return ICMP packets for active connections. So if you are running conntrack, you should be able to block most ICMP inbound, as long as you are accepting RELATED packets (before you block ICMP in your ruleset).