ebtables

  • 0 Replies
  • 1392 Views
*

Parsifal

  • Official Member
  • 36115
  • Bendy Light specialist
ebtables
« on: May 09, 2012, 06:14:20 PM »
Some of you may recall I mentioned my intention to firewall off some VMs (in particular, the one running Windows) from the outside world. My original intention was to do this using iptables, and have my Linux box acting as a NAT router in order to facilitate layer 3 filtering.

The obvious disadvantage to this is that virtual machines would not be addressable from any other host on my home LAN, as they would exist in a private address space behind a NAT. Initially, this was something I had thought I'd need to put up with.

Enter ebtables -- it's a layer 2 Ethernet frame filter with the capability to filter on layer 3 (e.g., IP addresses) and layer 4 (e.g., TCP ports) criteria. This enables me to configure an Ethernet bridge to attach my virtual machines directly to my home LAN, and then use ebtables to filter IP traffic passing across the bridge. This has the following advantages:

- Virtual machines obtain DHCP leases directly on my home LAN, and as such are addressable to all hosts on the LAN.
- There is less busywork involved for Linux in routing and NATing packets, since it only needs to filter and relay layer 2 frames, resulting in potentially better network performance.
- The filtering logic is applied on layer 2, meaning that I can filter based on each VM's statically assigned MAC address without having to care about whatever DHCP lease it happens to have obtained for the moment. While iptables does have source MAC address filtering capability, it is a layer 3 packet filter, making MAC addresses less central to its mode of operation and potentially ambiguous in some cases, which is probably why it only has source MAC address filtering (the source MAC address must always be well-defined when filtering packets that exist, since they had to have originated somewhere). ebtables doesn't suffer from this handicap.

Of course, there are disadvantages to this approach also. Notably, ebtables is much less flexible in terms of the number of filtering criteria it supports at layer 3 and above, simply because it is primarily a layer 2 filtering tool. However, it can filter based on source/destination IP address, and source/destination TCP/UDP ports, which is sufficient for most use cases.

Another disadvantage is that there is a lot of noise in terms of the wealth of layer 2 filtering options it does offer, when all I'm interested in is IP filtering. But who knows, it might come in handy one day.

To round off this tirade with an example, here's how I might permit my new Windows VM to access FES with ebtables (the default policy I've set up is DROP for IPv4 frames, ICMP excepted):

ebtables -I FORWARD -s 52:54:00:4f:16:f1 -p IPv4 --ip-dst 216.193.220.197 --ip-proto tcp --ip-dport 80 -j ACCEPT
ebtables -I FORWARD -d 52:54:00:4f:16:f1 -p IPv4 --ip-src 216.193.220.197 --ip-proto tcp --ip-sport 80 -j ACCEPT


Those of you familiar with Linux will notice that this syntax is very similar to iptables. The difference is, of course, that just as TCP is a high-level protocol to iptables, so is IP a high-level protocol to ebtables, and needs to be specified explicitly. Thus, -d refers to the destination MAC address, whereas --ip-dst refers to the destination IP address, and may only be used in conjunction with -p IPv4.

You'll notice I have two rules here with source and destination reversed. Unfortunately, I don't believe Linux (yet?) has state tracking on layer 2, so I can't just tell it to accept any frames matching an established connection -- there has to be an explicit rule for frames travelling in both directions.

Finally, the meaning of FORWARD in these rules highlights yet another great advantage to this method. FORWARD refers to packets that do not originate nor terminate on the bridge interface itself, but are rather forwarded across the bridge. Therefore, my local machine, who sends and receives packets on the bridge interface, is not subject to these rules and can still communicate freely with hosts on both sides of the bridge (i.e., my home LAN on one side, and my virtual machines on the other). These ebtables rules will only affect network traffic between my VMs and the outside world.

Hopefully someone else will find this as useful as I do.
« Last Edit: May 09, 2012, 06:17:01 PM by Parsifal »
I'm going to side with the white supremacists.