How can I block all traffic to/from an bridged interface while allowing DHCP?

Question

I have a PC (running Fedora 20) that is being used as a "software switch" to control the network connectivity of some external devices. There are eight such devices; the PC has two 4-port Ethernet cards in addition to its own Ethernet connection to the outside world. By default, the eight device interfaces are forwarded to the external interface with no filtering.

The desired functionality is the ability to block all traffic to and from a given device. Currently, we are doing this using bridge link set dev <device> state 0, which sets the bridge state of the device to "disabled". However, this appears to also block DHCP traffic from the device. The network's DHCP server is accessible via the external interface, so it seems like the bridge is blocking this traffic, meaning that if the device tries to renew its IP, this fails; this is problematic in terms of the tests I'm trying to perform on the device.

What I'd like to do is to block all traffic except DHCP across the bridge, for a given device. It seems like the bridge command can't do this, so I'd probably want to leave the bridge state as "forwarding" permanently. Having done some research, it seems like ebtables is the tool I need, but configuring it seems to need more knowledge of DHCP and networking than I have! From reading a few ebtables tutorials, I think I need to allow traffic on ports 67 and 68 (I believe these are the only ports used for DHCP?) and block all other traffic.

So my questions are:

1. Is it possible to configure ebtables to do what I want?
2. Is ebtables the best tool for the job and/or are there any abstraction layers on top of it that would make it easier to configure? (I'm thinking of ferm for iptables.)
3. Assuming I'm heading in the right direction, how would I configure ebtables to block all traffic bar DHCP?

Solution

Yes, you need ebtables to apply netfilter rules on a bridge.

The match rule is ip with parameters --ip-source-port and --ip-destination-port.

You'd configure ebtables to allow the traffic you want, then an explicit drop for any other traffic.

The DHCP client port is UDP 68, the DHCP server port is UDP 67.

I believe the correct command syntax and order would be:

ebtables -I INPUT -i eth0 -o eth0 -p ip -j DROP
ebtables -I INPUT -i eth0 -o eth0 -p ip --ip-protocol udp --ip-source-port 67 -j ACCEPT
ebtables -I INPUT -i eth0 -o eth0 -p ip --ip-protocol udp --ip-source-port 68 -j ACCEPT
ebtables -I INPUT -i eth0 -o eth0 -p ip --ip-protocol udp --ip-destination-port 67 -j ACCEPT
ebtables -I INPUT -i eth0 -o eth0 -p ip --ip-protocol udp --ip-destination-port 68 -j ACCEPT
ebtables-save

Comments

[Reaces]

Not an entire answer, but this post might be relevant.

[Allan Lewis]

Thanks @Reaces, but that question is precisely the one that prompted me to post this! Having said that, re-reading it made me notice that iptables apparently can't block DHCP traffic, so perhaps my solution is to block "all" (i.e. everything bar DHCP) traffic using iptables - I'll look into that.

[pepoluan]

iptables can't block DHCP server generated on the same host, but if you've configured your Linux box to act as a router, it can block DHCP packets. That said, since your Linux box works as a Layer 2 device, ebtables is your friend. (iptables is for Layer 3 and higher).

[suprjami]

@pepoluan is correct. iptables is the Layer 3/4 netfilter interface. ebtables is the Layer 2 netfilter interface.

[pepoluan]

@AllanLewis, any reason to use the Linux box as a bridge instead of a gateway/router? It will be much simpler to configure.

[Allan Lewis]

@pepoluan This is a system I've been given - I'm not at liberty to install new hardware. However, we are using the PC for various other tasks that a router can't do. (It runs several other services, for a start.) Also, in my experience routers need to be rebooted if you change things like bridging/filtering settings, whereas we need to be able to do this on-the-fly. If there are routers that are capable of this, I'd be interested to hear about them.

[pepoluan]

That's the first time ever I heard a Linux router needs to be rebooted to change the router's settings. The Linux router I had on a previous employer has been working nonstop for YEARS without needing a reboot. And through the years, it has seen countless configuration changes. Daily it updates itself to block access to dynamically-addressed sites, once even installing a compressed tunnel to optimize traffic to a subsidiary office, zero downtime.

[pepoluan]

Unless if what you're referring is changing its current function from a bridge into a router. Yes, there will be downtime, but not of the Linux box itself; rather, it was a downtime due to the need to change IP addresses of other connected devices. Anyways, if you can't even spare some time for that, there's a way to implement blocking. Let me check out my notes, and I'll get back to you.

[Allan Lewis]

Thanks @suprjami - I guess my rules would be ebtables --ip-source-port 67:68 --ip-destination-port 67:68 -j ACCEPT and ebtables -j DROP? (Sorry for the multiple edits - I didn't realise you can't do code blocks in comments!)

[suprjami]

I've edited my answer to include full commands. You could combine the ports as you've done with 67:68, good idea.

[suprjami]

Excellent, many thanks for your edit to the answer too!