I am using the following simple iptables rule that accepts related packets:
-A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
I am letting ICMP echo-requests pass with this other rule:
-A INPUT -p icmp --icmp-type echo-request -j ACCEPT
Should I explicitly add anything to receive "useful" ICMP messages like destination-unreachable, time-exceeded and parameter-problem, or the RELATED clause will already accept them?
http://www.linuxtopia.org/Linux_Firewall_iptables/x1571.html
Another hugely important part of ICMP is the fact that it is used to tell the hosts what happened to specific UDP and TCP connections or connection attempts. For this simple reason, ICMP replies will very often be recognized as RELATED to original connections or connection attempts. A simple example would be the ICMP Host unreachable or ICMP Network unreachable. These should always be spawned back to our host if it attempts an unsuccessful connection to some other host, but the network or host in question could be down, and hence the last router trying to reach the site in question will reply with an ICMP message telling us about it. In this case, the ICMP reply is considered as a RELATED packet
The RELATED rule will take care of the associated ICMP messages by default. From iptables man page, in the section related to conntrack (http://linux.die.net/man/8/iptables):
RELATED meaning that the packet is starting a new connection, but is associated with an existing connection, such as an FTP data transfer, or an ICMP error.
Other states reported by conntrack are:
You can examine and manage the conntrack table using the conntrack package.
$ sudo conntrack -L
In general is a very bad idea to filter or block icmp, usually the only "valid" bit of icmp to filter is echo-request to "appear" down in a naïve scan.
But if you want to explicit allow parts of it you are missing at least two very important bits, fragmentation needed & Source Quench:
-A INPUT -p icmp --icmp-type fragmentation-needed -m state --state NEW -j ACCEPT
-A INPUT -p icmp --icmp-type source-quench -m state --state NEW -j ACCEPT
Let me tell you again that filtering icmp is a bad idea that will mask problems and make it difficult to discover.
That was the problem with DF (don't fragment) and fragmentation-needed which is needed for automatic PTMU discovery and caused sites to be inaccessible because intermediate firewalls/routers dropped the icmp packets advertising the endpoint to lower the MTU.
I'll add my own answer to provide my final configuration, inspired by other answers and the following sources:
an expired draft by IETF with a useful table which shows which ICMP types allow, deny or rate limit;
another page with the minimum lines for iptables and Cisco IOS;
a third resource which uses RELATED:
iptables -P INPUT DROP
iptables -A INPUT -p icmp --fragment -j DROP
iptables -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
iptables -A INPUT -p icmp --icmp-type fragmentation-needed -j ACCEPT
iptables -A INPUT -p icmp --icmp-type echo-request -j ACCEPT
ICMP is a very important connection protocol. The "echo-request" is the only important useful message that helps communication. Rest of them including "destination-unreachable" is safe to block specially if the application you're running receives a large number of unknown hits.
You're better off with something like this,
-A INPUT -p icmp --icmp-type echo-request -m recent --set
-A INPUT -p icmp --icmp-type echo-request -m recent --update --seconds 1 --hitcount 30 -j DROP
-A INPUT -p icmp --icmp-type echo-request -j ACCEPT
-A OUTPUT -p icmp --icmp-type echo-request -j ACCEPT
-A OUTPUT -p icmp --icmp-type destination-unreachable -j DROP
-A INPUT -p icmp -j DROP
This would not only accept "echo-request" but also block ping floods greater than 30 packets/s. Anything else you want to add has to explicitly be accepted because the RELATED clause will not receive them as long as the connection is established by letting it in.
