1

I'm using ufw.

I want to block pings for IPv4 and IPv6. I've read guides by ubuntu as well as hosting companies I use, and answers on StackExchange sites.

Advice is always to edit /etc/ufw/before.rules and DROP these types of icmp requests:

- destination-unreachable
- time-exceeded
- parameter-problem
- echo-request

These are exactly the types in my config file.

For IPv6 the same guides say to edit /etc/ufw/before6.rules and DROP:

- destination-unreachable
- packet-too-big
- time-exceeded
- parameter-problem
- echo-request

However in my environment - Ubuntu 18.10, ufw 0.36 - there are more types:

- router-solicitation
- router-advertisement
- neighbor-solicitation
- neighbor-advertisement

I'm not sure whether to DROP them too.

Basically, I want to block ICMP traffic for pings only. Some ICMP types are unrelated to pings, so I don't want to block them. Which types do I need to DROP for IPv4 and which for IPv6?

lonix
  • 896
  • 10
  • 23

1 Answers1

3

RFC4890 addresses solely this issue.

Specifically Section 4 answers all your questions.

With ICMPv6 you basically have the two cases: Transit Traffic and Local Configuration Traffic

Of course this is a complete RFC, so lot's of text and quite detailed, but I thought it should be listed as an answer.

I'll list the messages of the sections (and cut out the informative passages, it's adivsable to read them, though):

4.3 Recommendations for ICMPv6 Transit Traffic

4.3.1. Traffic That Must Not Be Dropped

  • Destination Unreachable (Type 1) - All codes

  • Packet Too Big (Type 2)

  • Time Exceeded (Type 3) - Code 0 only

  • Parameter Problem (Type 4) - Codes 1 and 2 only

  • Echo Request (Type 128)

  • Echo Response (Type 129)

4.3.2. Traffic That Normally Should Not Be Dropped

  • Time Exceeded (Type 3) - Code 1

  • Parameter Problem (Type 4) - Code 0

  • Home Agent Address Discovery Request (Type 144)

  • Home Agent Address Discovery Reply (Type 145)

  • Mobile Prefix Solicitation (Type 146)

  • Mobile Prefix Advertisement (Type 147)

4.3.3. Traffic That Will Be Dropped Anyway -- No Special Attention Needed

  • Router Solicitation (Type 133)

  • Router Advertisement (Type 134)

  • Neighbor Solicitation (Type 135)

  • Neighbor Advertisement (Type 136)

  • Redirect (Type 137)

  • Inverse Neighbor Discovery Solicitation (Type 141)

  • Inverse Neighbor Discovery Advertisement (Type 142)

  • Listener Query (Type 130)

  • Listener Report (Type 131)

  • Listener Done (Type 132)

  • Listener Report v2 (Type 143)

  • Certificate Path Solicitation (Type 148)

  • Certificate Path Advertisement (Type 149)

  • Multicast Router Advertisement (Type 151)

  • Multicast Router Solicitation (Type 152)

  • Multicast Router Termination (Type 153)

4.3.4. Traffic for Which a Policy Should Be Defined

  • Seamoby Experimental (Type 150)

  • Unallocated Error messages (Types 5-99 inclusive and 102-126 inclusive)

  • Unallocated Informational messages (Types 154-199 inclusive and 202-254 inclusive).

4.3.5. Traffic That Should Be Dropped Unless a Good Case Can Be Made

  • Node Information Query (Type 139)

  • Node Information Response (Type 140)

  • Router Renumbering (Type 138)

  • Types 100, 101, 200, and 201.

  • Types 127 and 255.

4.4. Recommendations for ICMPv6 Local Configuration Traffic

4.4.1. Traffic That Must Not Be Dropped

  • Destination Unreachable (Type 1) - All codes

  • Packet Too Big (Type 2)

  • Time Exceeded (Type 3) - Code 0 only

  • Parameter Problem (Type 4) - Codes 1 and 2 only

  • Echo Request (Type 128)

  • Echo Response (Type 129)

  • Router Solicitation (Type 133)

  • Router Advertisement (Type 134)

  • Neighbor Solicitation (Type 135)

  • Neighbor Advertisement (Type 136)

  • Inverse Neighbor Discovery Solicitation (Type 141)

  • Inverse Neighbor Discovery Advertisement (Type 142)

  • Listener Query (Type 130)

  • Listener Report (Type 131)

  • Listener Done (Type 132)

  • Listener Report v2 (Type 143)

  • Certificate Path Solicitation (Type 148)

  • Certificate Path Advertisement (Type 149)

  • Multicast Router Advertisement (Type 151)

  • Multicast Router Solicitation (Type 152)

  • Multicast Router Termination (Type 153)

4.4.2. Traffic That Normally Should Not Be Dropped

  • Time Exceeded (Type 3) - Code 1
  • Parameter Problem (Type 4) - Code 0

4.4.3. Traffic That Will Be Dropped Anyway -- No Special Attention Needed

  • Router Renumbering (Type 138)

  • Home Agent Address Discovery Request (Type 144)

  • Home Agent Address Discovery Reply (Type 145)

  • Mobile Prefix Solicitation (Type 146)

  • Mobile Prefix Advertisement (Type 147)

  • Seamoby Experimental (Type 150)

4.4.4. Traffic for Which a Policy Should Be Defined

  • Redirect (Type 137)

  • Node Information Query (Type 139)

  • Node Information Response (Type 140)

  • Unallocated Error messages (Types 5-99 inclusive and 102-126 inclusive)

4.4.5. Traffic That Should Be Dropped Unless a Good Case Can Be Made

  • Types 100, 101, 200, and 201.

  • Types 127 and 255.

  • Types 154-199 inclusive and 202-254 inclusive.

Community
  • 1
Lenniey
  • 5,220
  • 2
  • 18
  • 29
  • Thanks. However I was hoping for something simpler than reading the RFCs. For a run of the mill vps hosting some websites and nginx, etc., and one which I want to lock down from bad guys, all the icmp traffic i listed above is typically recommended to be blocked, despite what the RFC says. Do you think I should also block those other types (which are not typically mentioned)? – lonix Sep 02 '19 at 12:52
  • Like I said, this answer is more for completeness sake. Could you add a link to your guides? – Lenniey Sep 02 '19 at 12:59
  • What do you hope to achieve by blocking ping? – bodgit Sep 02 '19 at 13:36
  • 2
    @lonix Blocking "ping" is mostly useless as a "security" measure. It will, however, cause you a lot of grief later when you try to ping your own server and cannot! – Michael Hampton Sep 02 '19 at 17:42
  • Yeah I've read those arguments but I still want to do it. I appreciate your advice though! – lonix Sep 02 '19 at 17:45
  • Do you know if there is a similar guide for ICMPv4? – lonix Sep 14 '19 at 13:46
  • Sorry for this noob question, but how do I tell `ip6tables` to ACCEPT `Destination Unreachable (Type 1) - All codes` and DROP everything else? – Houman Mar 13 '21 at 10:49
  • As a noob on ICMPv6 topic, I was interested by the question, but after reading the RFC, I understand the question is ill-defined: 1/ the ICMPv6 “ping” (type 128) is only one way to detect host presence amongst all other types and has minor security properties (see RFC section 3.2) but major usability issues (no Teredo connectivity); 2/ a precise question on this topic should mention what the host does (firewall, server…); 3/ the linked guide recommends e.g. to block type 4 (Parameter Problem) but it could lead to malfunctioning in case of unrecognised IPv6 option (code 2) (see RFC). – Seb35 Oct 29 '21 at 18:10