Score:4

Which ICMP types (v4/v6) should not be blocked?

in flag

I have made a lot of research into this and have found that some references contradict each other.

IPV6 For example RFC4890 says the following types should be allowed for optimal functionality:

Type 1, 2, 3, 4, 128, 129 and for mobility assistance also 144, 145, 146 and 147.

However this source doesn't mention mobility assistance was required: (also type 1 and 4 are omitted)

Type 128, 129, 2, 3 and for NDP and SLAAC 133, 134, 135, 136 and 137

On the other hand the former reference said NDP and SLAAC don't need special attention, since they will be dropped anyway. So who is right? Is it best to allow all these mentioned by both sources to be on the safe side?

IPV4: Surpringly the reference doesn't have any recommendation for IPv4, but the other source says that types 8, 0, 3 and 11 are needed for IPv4. Are there any official reference that recommends which IPv4 ICMPs should be allowed?

UPDATE: While the answer is good, I find it too generic to accept it as a real solution to this. If blocking is not the answer, then rate limit must be the right way to provide a level of protection. I believe an answer with the correct code sample would be more assuring.

Ron Maupin avatar
us flag
NDP is a link-local protocol, so it will never be routed.
Paul avatar
cn flag
Does this answer your question? [Why not block ICMP?](https://serverfault.com/questions/84963/why-not-block-icmp?rq=1)
in flag
Yes, I changed my mind. I won't block it after all.
in flag
To allow everything, I need only `-A INPUT -p icmp -j ACCEPT` and `-A INPUT -p ipv6-icmp -j ACCEPT`, correct? `-m icmp` is not required? Thanks
cn flag
[RFC 5927 *ICMP Attacks against TCP*](https://www.rfc-editor.org/rfc/rfc5927.html) seems relevant. The mitigations should be implemented in the TCP stack however, not in the firewall, from what I understand.
iBug avatar
um flag
@Houman `-m icmp` is implied if you have `-p icmp`. The `-m` option is not a "matcher" itself, but pulls in the facilities for matching ICMP payload.
Joseph Sible-Reinstate Monica avatar
"If blocking is not the answer, then rate limit must be the right way to provide a level of protection." Why do you think that?
in flag
@JosephSible-ReinstateMonica See the answer.
Score:10
cn flag

All of ICMP should not be blocked. Not by default, this can be a deny list rather than an allow list.

Start by rate limiting, but not otherwise filtering, ICMP.

Read RFC 4890 section 3 on the security considerations expected. Notably redirect diverting packets, but the standard requires those to be local, on link. Denial of service at high volume, but often that can be mitigated with rate limits. Maybe discovery of hosts, but that doesn't reveal much. ICMP is not very dangerous.

in flag
Thanks. Would you be able to provide a rate limit example with iptables, please? I could probably do this for all ICMP, but I have a bad feeling that I might break something: `-A INPUT -p icmp -m limit --limit 10/sec -j ACCEPT`. My scenario is the following, the users can open our app, and tap on server status to see a list of all servers shown with their ping. Theoretically many users could do that at the same time. What number would be the right limit?
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.