5 ms·

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?

jeroenhd 3y ago
Not through iptables, and probably not through nftables (though I can't find much documentation on nftables). 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 https://github.com/Asphaltt/iptables-bpf
- anfractuosity 3y ago
  Thanks a lot, will have a look at your link.
- ilyt 3y ago
  ebtables can, it inspects ethernet frames.
ilyt 3y ago
You could probably via ebtables as they inspect ethernet frames directly. That can be used for example to not allow VMs on host to spoof mac addresses. 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.
tenebrisalietum 3y ago
DHCP relies on Ethernet broadcasts to function - meaning DHCP messages are received by every NIC on the subnet. So ... already not private. 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.
- justsomehnguy 3y ago
  > are received by every NIC on the subnet On the brodcast segment, usually L2 VLAN. /nitpick
yrro 3y ago
The netdev and bridge tables' hooks run early enough I think?
- lathiat 3y ago
  Right: https://wiki.nftables.org/wiki-nftables/index.php/Nftables_families https://wiki.nftables.org/wiki-nftables/index.php/Nftables_f... "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."
globular-toast 3y ago
What does it even mean to block DHCP? A firewall sits between networks and filters what gets passed between them. Linux can absolutely block DHCP packets being passed between networks. But it has to see them itself, obviously. So you don't want other processes being able to see them too? Well don't run those processes. Why on earth would you run a DHCP server that you hope can never receive any requests?!
- lathiat 3y ago
  Whether or not it's sensible is not quite the point. It's surprising and noteworthy to understand. And by understanding helps understand the internals of this aspect of linux networking. 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)
- timost 3y ago
  This DHCP behaviour also happens on the client side

jeroenhd 3y ago

Not through iptables, and probably not through nftables (though I can't find much documentation on nftables). 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 https://github.com/Asphaltt/iptables-bpf

anfractuosity 3y ago
Thanks a lot, will have a look at your link.
ilyt 3y ago
ebtables can, it inspects ethernet frames.

ilyt 3y ago

You could probably via ebtables as they inspect ethernet frames directly. That can be used for example to not allow VMs on host to spoof mac addresses. 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.

tenebrisalietum 3y ago

DHCP relies on Ethernet broadcasts to function - meaning DHCP messages are received by every NIC on the subnet. So ... already not private. 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.

justsomehnguy 3y ago
> are received by every NIC on the subnet On the brodcast segment, usually L2 VLAN. /nitpick

yrro 3y ago

The netdev and bridge tables' hooks run early enough I think?

lathiat 3y ago
Right: https://wiki.nftables.org/wiki-nftables/index.php/Nftables_families https://wiki.nftables.org/wiki-nftables/index.php/Nftables_f... "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."

globular-toast 3y ago

What does it even mean to block DHCP? A firewall sits between networks and filters what gets passed between them. Linux can absolutely block DHCP packets being passed between networks. But it has to see them itself, obviously. So you don't want other processes being able to see them too? Well don't run those processes. Why on earth would you run a DHCP server that you hope can never receive any requests?!

lathiat 3y ago
Whether or not it's sensible is not quite the point. It's surprising and noteworthy to understand. And by understanding helps understand the internals of this aspect of linux networking. 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)
timost 3y ago
This DHCP behaviour also happens on the client side