Score:4

Server

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

Houman

3/28/23, 4:14 PM

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.

962

0 + 0

internet

iptables

ipv6

rfc

ipv4

Ron Maupin

3/28/23, 4:33 PM

NDP is a link-local protocol, so it will never be routed.

Paul

3/28/23, 5:29 PM

Does this answer your question? [Why not block ICMP?](https://serverfault.com/questions/84963/why-not-block-icmp?rq=1)

Houman

3/28/23, 7:05 PM

Yes, I changed my mind. I won't block it after all.

Houman

3/28/23, 7:06 PM

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

Bergi

3/29/23, 6:49 AM

[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

3/29/23, 10:22 AM

@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

4/2/23, 4:46 AM

"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?

Houman

4/2/23, 11:57 AM

@JosephSible-ReinstateMonica See the answer.

Score:10

Server

John Mahowald

3/28/23, 7:47 PM

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.

0 + 0

Houman

3/29/23, 8:13 PM

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?