Intriguing, so there's no way to block DHCP from Linux at all as all firewalls such as ufw/nftables/iptables, would use netfilter behind the scenes?
But easiest way is just don't allow app to run with permission to access raw socket. That's it.
The problem is really that there is no way to get UDP interface that also gives you mac address of the packet so raw sockets are only way to do it.
Similarly there is no interface to send ICMP packets other than raw sockets.
eBPF should still work, though. You can also configure iptables to filter based on a bpf program, combining the two. Here's an example: https://github.com/Asphaltt/iptables-bpf
PF_PACKET is needed to look at those broadcasts because the system might not have an IP, so it can't use TCP or UDP sockets.
PF_PACKET on Linux evidently ignores iptables.
Good news: PF_PACKET requires root to use (more precisely, CAP_NET_RAW capability).
So root processes can totally ignore your firewall. This doesn't matter because:
- a firewall is really for managing external communications. If you have stuff running on localhost sending or receiving unwanted stuff, and you don't trust it, why is it running on your machine then?
- root can already simply disable the firewall by removing iptables rules or adding ones.
You can always move to IPv6 which uses multi-cast and self-generated link-local addresses, meaning PF_PACKET isn't necessary.
On the brodcast segment, usually L2 VLAN.
/nitpick
"The netdev family is different from the others in that it is used to create base chains attached to a single network interface. Such base chains see all network traffic on the specified interface, with no assumptions about L2 or L3 protocols. Therefore you can filter ARP traffic from here. There is no legacy x_tables equivalent to the netdev family."
I ran into exactly this problem a few months ago. But it was a lab scenario rather than a real production one.
In my lab at work I had only a single VLAN (and couldn't get a new one added fast enough for the tight 2 day timeline of the case I was working on, though I have since done so). So I had "MAAS" (Metal As a Service) which PXE boot installs the servers plus OpenStack Virtual Machines connected to the same VLAN. Both run a DHCP service.
MAAS (using ISC DHCP Server currently) responds to any DHCP requests while OpenStack only responds to IP/MAC combinations it knows from it's configuration database and ignores others. So OpenStack wasn't impacting MAAS but sometimes MAAS was responding faster than OpenStack giving the wrong IP to VMs. As a temporary workaround I (tried) to add a firewall rule to the MAAS server to block DHCP from the specific MAC addresses of the test VMs but it didn't work.
Investigating that is when I learnt about this surprise behaviour, which was particularly surprising as I am far more knowledgable than average of many aspects of linux networking including some (but by no means extensive) kernel/netfilter internals and can write most iptables rules in my sleep from memory... despite all of that, this one was new to me :)
(As a side note, when using ovn/ovs networking, Openstack will filter external DHCP requests to VMs, which also solves this, but in this case I was specifically testing SR-IOV where the VMs are directly attached to a virtual function on the physical network card, where such filtering is not configured and may or may not be possible depending on the card)