Why 224.0.0.1 traffic is filtered by Linux hosts?

Solution 1:

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).

Solution 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.