It’s always interesting to see how new technologies alter the way we do things. Recently, I worked on firewalling for a KVM-based virtualization platform. From the outset it seems pretty straightforward. Set up iptables on the host and guest and move on. But it’s not that simple, and my google-fu initially failed me when searching for an answer.
The primary issue was that when iptables was enabled on the host, the guests became unavailable. If you enable logging, you can see the traffic being blocked by the host, thus never making it to the guest. So how do we do this? Well, if we start with a generic iptables setup, we have something that looks like this:
# Firewall configuration written by system-config-securitylevel
# Manual customization of this file is not recommended.
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:RH-Firewall-1-INPUT – [0:0]
-A INPUT -j RH-Firewall-1-INPUT
-A FORWARD -j RH-Firewall-1-INPUT
-A RH-Firewall-1-INPUT -i lo -j ACCEPT
-A RH-Firewall-1-INPUT -p icmp –icmp-type any -j ACCEPT
-A RH-Firewall-1-INPUT -m state –state ESTABLISHED,RELATED -j ACCEPT
-A RH-Firewall-1-INPUT -m state –state NEW -m tcp -p tcp –dport 22 -j ACCEPT
-A RH-Firewall-1-INPUT -j REJECT –reject-with icmp-host-prohibited
COMMIT
Adding logging to identify what’s going on is pretty straightforward. Add two logging lines, one for the INPUT chain and one for the FORWARD chain. Make sure these are added as the first rules in the chain, otherwise you’ll jump to the RH-Firewall-1-INPUT chain and never make it to the log.
-A INPUT -j LOG –log-prefix “Firewall INPUT: ”
-A FORWARD -j LOG –log-prefix “Firewall FORWARD: ”
Now, with this in place you can try sending traffic to the domU. If you tail /var/log/messages, you’ll see the blocking done by netfilter. It should look something like this:
Apr 18 12:00:00 example kernel: Firewall FORWARD: IN=br123 OUT=br123 PHYSIN=vnet0 PHYSOUT=eth1.123 SRC=192.168.1.2 DST=192.168.1.1 LEN=56 TOS=0x00 PREC=0x00 TTL=64 ID=18137 DF PROTO=UDP SPT=56712 DPT=53 LEN=36
There are a few things of note here. First, this occurs on the FORWARD chain only. The INPUT chain is bypassed completely. Second, the system recognizes that this is a bridged connection. This makes things a bit easier to fix.
My attempt at resolving this was to put in a rule that allowed traffic to pass for the bridged interface. I added the following:
-A FORWARD -i br123 -o br123 -j ACCEPT
This worked as expected and allowed the traffic through the FORWARD chain, making it to the domU unmolested. However, this method means I have to add a rule for every bridge interface I create. While explicitly adding rules for each interface should make this more secure, it means I may need to change iptables while the system is in production and running, not something I want to do.
A bit more googling led me to this post about KVM and iptables. In short it provides two additional methods for handling this situation. The first is a more generalized rule for bridged interfaces:
-A FORWARD -m physdev –physdev-is-bridged -j ACCEPT
Essentially, this rule tells netfilter to accept any traffic for bridged interfaces. This removes the need to add a new rule for each bridged interface you create making management a bit simpler. The second method is to completely remove bridged interfaces from netfilter. Set the following sysctl variables:
net.bridge.bridge-nf-call-ip6tables = 0
net.bridge.bridge-nf-call-iptables = 0
net.bridge.bridge-nf-call-arptables = 0
I’m a little worried about this method as it completely bypasses iptables on dom0. However, it appears that this is actually a more secure manner of handling bridged interfaces. According to this bugzilla report and this post, allowing bridged traffic to pass through netfilter on dom0 can result in a possible security vulnerability. I believe this is somewhat similar to cryptographic hash collision. Attackers can take advantage of netfilter entries with similar IP/port combinations and possibly modify traffic or access systems. By using the sysctl method above, the traffic completely bypasses netfilter on dom0 and these attacks are no longer possible.
More testing is required, but I believe the latter method of using sysctl is the way to go. In addition to the security considerations, bypassing netfilter has a positive impact on throughput. It seems like a win-win from all angles.