5

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
  • 147
  • 2
  • 7

2 Answers2

4

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
  • 519
  • 3
  • 15
  • Thanks for your detailed answers, you have confirmed what I though. If I have to summarize the biggest part of my misunderstanding: 1) IPv4 multicast and broadcast are behind the same setting part because of the "laziness" of kernel developpers to separate them and part because these addresses share common attacks. 2) IPv6 multicast has almost no chance to be blocked in the future because of its massive use by the different protocols working over IPv6 One last question. You are talking about firewall. where is it located ? on the hosts? on the router ? what/how do you filter exactly ? – djoproject Oct 12 '20 at 20:51
  • @djoproject The techniques the firewall are the same in each Linux distribution, because those techniques are integrated in the kernel (iptables / nftables). However, different distributions use different (GUI) programs to adjust the firewall rules. I don't know your distribution, so I can't tell more about it. To learn firewalls from scratch, you could read some articles about iptables / nftables and their userland command line tools. – Binarus Oct 13 '20 at 08:12
  • Regarding Windows: There is a reasonable GUI to configure the rules, e.g. in Windows 10: Control Panel -> Windows Defender Firewall -> Advanced Settings. Both in Windows or Linux, nobody can tell you what and how to filter, because that solely depends on your needs. That subject easily can fill a book, and if you ask 3 people about it, you will get 5 different answers :-). If you are interested in that subject, you should start with studying some tutorials to get a feeling and then implement what is appropriate for you. – Binarus Oct 13 '20 at 08:18
  • I am sorry my question was probably unclear, I know how firewalls work. I would like to know on what host you have put the firewall you talked about. On the router ? or on the normal hosts ? somewhere else ? And also what are the rules you defined into your firewall (a basic description is enough), what are you filtering exactly ? – djoproject Oct 13 '20 at 08:19
  • I see. I was talking about the firewalls on the hosts. But in general, the most reasonable thing is a mixture. It would be reasonable to block all traffic from the outside which you don't want to see in your subnet at the router level. The firewalls on the hosts on your subnet are a second line of defense and additionally protect against hostile traffic which originates from *within* your subnet, for example from a Windows PC which is infected by malware. – Binarus Oct 13 '20 at 08:22
  • Regarding the actual rules: In my case, they are several kB, and it wouldn't be appropriate to publish them here. But I can give one example: On some of my Windows 10 hosts, I block all inbound and outbound traffic to `224.0.0.0/4`. In contrast to some reports on the net whose authors claim that you can't block multicast traffic in Windows, that does what I want. I have monitored those hosts a full day (using Wireshark) and found no more multicast responses coming from them or multicast queries originating from them. It is the same with Linux. – Binarus Oct 13 '20 at 08:30
1

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
  • 6,875
  • 4
  • 22
  • 45