4

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?
Allan Lewis
  • 143
  • 1
  • 1
  • 3
  • Not an entire answer, but [this post](http://serverfault.com/questions/191390/iptables-and-dhcp-questions) might be relevant. – Reaces Jan 13 '15 at 12:24
  • 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. – Allan Lewis Jan 13 '15 at 14:00
  • 1
    `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). – pepoluan Jan 14 '15 at 10:15
  • @pepoluan is correct. `iptables` is the Layer 3/4 netfilter interface. `ebtables` is the Layer 2 netfilter interface. – suprjami Jan 14 '15 at 14:16
  • @AllanLewis, any reason to use the Linux box as a _bridge_ instead of a _gateway/router_? It will be much simpler to configure. – pepoluan Jan 14 '15 at 14:55
  • @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. – Allan Lewis Jan 14 '15 at 16:52
  • 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 Jan 14 '15 at 17:25
  • 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. – pepoluan Jan 14 '15 at 17:30

1 Answers1

6

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
Allan Lewis
  • 143
  • 1
  • 1
  • 3
suprjami
  • 3,476
  • 20
  • 29
  • 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!) – Allan Lewis Jan 15 '15 at 09:40
  • I've edited my answer to include full commands. You could combine the ports as you've done with `67:68`, good idea. – suprjami Jan 15 '15 at 09:59
  • 1
    You have to at least also specify the particular interface for which you want to DROP traffic. And you want to drop all traffic, not only UDP, except for those udp packets, that you want to let pass. – Kai Petzke Jan 15 '15 at 10:40
  • Excellent, many thanks for your edit to the answer too! – suprjami Jan 16 '15 at 11:21