4

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.

Houman
  • 1,325
  • 3
  • 18
  • 30
  • 2
    NDP is a link-local protocol, so it will never be routed. – Ron Maupin Nov 28 '21 at 16:33
  • 4
    Does this answer your question? [Why not block ICMP?](https://serverfault.com/questions/84963/why-not-block-icmp?rq=1) – Paul Nov 28 '21 at 17:29
  • 3
    Yes, I changed my mind. I won't block it after all. – Houman Nov 28 '21 at 19:05
  • 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 – Houman Nov 28 '21 at 19:06
  • 1
    [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. – Bergi Nov 29 '21 at 06:49
  • 1
    @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. – iBug Nov 29 '21 at 10:22
  • "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? – Joseph Sible-Reinstate Monica Dec 02 '21 at 04:46
  • @JosephSible-ReinstateMonica See the answer. – Houman Dec 02 '21 at 11:57

1 Answers1

10

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.

John Mahowald
  • 30,009
  • 1
  • 17
  • 32
  • 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? – Houman Nov 29 '21 at 20:13