9

When sending an ICMPv4 echo request to a destination address like 224.0.0.1, it is ignored by Linux hosts receiving the request. The destination MAC address used is 01:00:5e:00:00:01.

The only way to have those Linux hosts answering is to set the Kernel parameter net.ipv4.icmp_echo_ignore_broadcasts to the value 0. Which will instruct the kernel to answer to both multicast and broadcast ICMPv4 requests and open the door to broadcast security threats.

Why is multicast traffic filtered by this parameter ? is there any attack justifying it ?

With ICMPv6 and equivalent destination address like ff02::1, the traffic is not filtered by Linux hosts. Is there a risk that it will be filtered too in the future ? Is there a threat with ICMPv4 that doesn't exist with ICMPv6 ?

Linux hosts:

  • Linux distribution: Ubuntu 20.04.1 LTS Focal
  • Linux kernel: 5.4.0
djoproject
  • 186

3 Answers3

8

I am understanding your question so that you would like to block processing of broadcasts, but not of multicasts, due to possible broadcast security threats.

That leads to the question why you consider broadcasts more dangerous than multicasts. After all, the multicast address 224.0.0.1 means "all hosts on this subnet" (reference). This is more or less the same as with broadcasts which also go to all hosts of a subnet.

Taking it further, you could even argue that multicast is more dangerous than broadcast, because it is routable. At least, parts of the multicast address ranges are routable (for an incomplete quick overview, see here), which means that somebody outside your subnet can send multicast traffic to all hosts in your subnet. (Note: Usually, only interested hosts in your subnet process such data, but this does not change the nature of the problem).

To avoid misunderstandings, the address 224.0.0.1 is not routable, so there is no danger from the outside. But it still addresses all hosts of the subnet.

Given that, it is not totally unreasonable that Linux at the kernel level does not provide separate parameters to ignore broadcasts and multicasts for IPv4.

For the reasons mentioned above, I let broadcast and multicast processing enabled at the kernel level, but I block multicast at the firewall level. I don't need it, and never will, and I am deeply mistrustful regarding that "zero-conf" nonsense which is based on it. As an off-topic side note, it is the same in Windows (I block it at the firewall level).

Binarus
  • 612
2

Other than timestamp requests (controlled witht the same flag, v4 icmp only), the difference is that the sysctls for v6 are more appropriately named for the groups of recipients IPv6 allows:

/proc/sys/net/ipv4/icmp_echo_ignore_broadcasts

works very similar to

/proc/sys/net/ipv6/icmp/echo_ignore_anycast
/proc/sys/net/ipv6/icmp/echo_ignore_multicast

The available controls are described in Documentation/networking/ip-sysctl

The attack is just traffic multiplication - you would not want to have a network saturated from responses to small packets. There is no general need to apply such a broad filter to traffic in IPv6, because, well, there is no broadcast in IPv6.

anx
  • 10,888
-1

Just a kind reminder: there is NO broadcast in IPv6, only multicast and unicast remain.

StndFish
  • 1