Neutron security groups and OVS, part 2: security groups implementation

Security groups provide IP traffic filtering for your VM instances. You can specify ingress and egress rules and filter traffic based on port, source address, destination address, etc. Here’s a shot from my lab, with some basic security group rules assigned to my demo project (click to enlarge):

Under the hood, when using the iptables_hybrid firewall driver, these are all implemented as iptables rules on every compute node where an instance is running with this security group assigned.

These security groups use the tap interfaces we discussed in part 1 of this series – this is a natural choice, given these are the points of entry to and from the VM’s networking device. If we’re going to filter packets, this is the best place to do it.

Let’s take a look at a sample of iptables rules that currently exist on my compute node. I’ve stripped them right back because there’s a lot of them. Additionally, I’m only looking at the IPv4 rules here, but you can see the IPv6 equivalents using ip6tables -S:

[root@cop1 ~]# iptables -S | grep ie814
-N neutron-openvswi-ie814ad4e-2
-A neutron-openvswi-ie814ad4e-2 -m state --state RELATED,ESTABLISHED -m comment --comment "Direct packets associated with a known session to the RETURN chain." -j RETURN
-A neutron-openvswi-ie814ad4e-2 -d 192.168.0.22/32 -p udp -m udp --sport 67 --dport 68 -j RETURN
-A neutron-openvswi-ie814ad4e-2 -d 255.255.255.255/32 -p udp -m udp --sport 67 --dport 68 -j RETURN
-A neutron-openvswi-ie814ad4e-2 -m set --match-set NIPv4a1d17fde-c4f6-4de4-b3cc- src -j RETURN
-A neutron-openvswi-ie814ad4e-2 -p icmp -j RETURN
-A neutron-openvswi-ie814ad4e-2 -s 203.0.113.0/24 -p tcp -m tcp --dport 22 -j RETURN
-A neutron-openvswi-ie814ad4e-2 -m state --state INVALID -m comment --comment "Drop packets that appear related to an existing connection (e.g. TCP ACK/FIN) but do not have an entry in conntrack." -j DROP
-A neutron-openvswi-ie814ad4e-2 -m comment --comment "Send unmatched traffic to the fallback chain." -j neutron-openvswi-sg-fallback
-A neutron-openvswi-sg-chain -m physdev --physdev-out tape814ad4e-20 --physdev-is-bridged -m comment --comment "Jump to the VM specific chain." -j neutron-openvswi-ie814ad4e-2

[root@cop1 ~]

# iptables -S | grep oe814 -N neutron-openvswi-oe814ad4e-2 -A neutron-openvswi-INPUT -m physdev –physdev-in tape814ad4e-20 –physdev-is-bridged -m comment –comment “Direct incoming traffic from VM to the security group chain.” -j neutron-openvswi-oe814ad4e-2 -A neutron-openvswi-oe814ad4e-2 -s 0.0.0.0/32 -d 255.255.255.255/32 -p udp -m udp –sport 68 –dport 67 -m comment –comment “Allow DHCP client traffic.” -j RETURN -A neutron-openvswi-oe814ad4e-2 -j neutron-openvswi-se814ad4e-2 -A neutron-openvswi-oe814ad4e-2 -p udp -m udp –sport 68 –dport 67 -m comment –comment “Allow DHCP client traffic.” -j RETURN -A neutron-openvswi-oe814ad4e-2 -p udp -m udp –sport 67 –dport 68 -m comment –comment “Prevent DHCP Spoofing by VM.” -j DROP -A neutron-openvswi-oe814ad4e-2 -m state –state RELATED,ESTABLISHED -m comment –comment “Direct packets associated with a known session to the RETURN chain.” -j RETURN -A neutron-openvswi-oe814ad4e-2 -j RETURN -A neutron-openvswi-oe814ad4e-2 -m state –state INVALID -m comment –comment “Drop packets that appear related to an existing connection (e.g. TCP ACK/FIN) but do not have an entry in conntrack.” -j DROP -A neutron-openvswi-oe814ad4e-2 -m comment –comment “Send unmatched traffic to the fallback chain.” -j neutron-openvswi-sg-fallback -A neutron-openvswi-sg-chain -m physdev –physdev-in tape814ad4e-20 –physdev-is-bridged -m comment –comment “Jump to the VM specific chain.” -j neutron-openvswi-oe814ad4e-2

Let’s draw a few conclusions from this:

  1. The neutron-openvswi-sg-chain is where all traffic is first pushed through. We then jump to an input or output chain based on the physical device and the direction of the traffic:
    -A neutron-openvswi-sg-chain -m physdev --physdev-out tape814ad4e-20 --physdev-is-bridged -m comment --comment "Jump to the VM specific chain." -j neutron-openvswi-ie814ad4e-2

    The above sends all traffic that would go out via tape814ad4e-20 (e.g. to the VM) through the chain neutron-openvswi-ie814ad4e-2. There’s an equivalent jump rule for traffic coming in via the tap interface (e.g. from the VM).

  2. Note the e814ad43-2 that forms part of the name of the chains. This corresponds to the neutron port allocated to the VM, and in turn to the tap interface. The “i” prefix means these are for incoming packets, with respect to the VM. Similarly, an “o” prefix is for outgoing packets, with respect to the VM.
  3. We allow DHCP traffic to enter the VM. Note the rule for the IPv4 broadcast address and for the specific IP of the VM. Note that the VM is not allow to spoof itself as a DHCP server – outbound traffic from source port 67 UDP is disallowed.
  4. The --match-set parameter defines an ipset that contains all the VMs that form part of the security group, in this case the “default” security group. View the members of that set with ipset list NIPv4a1d17fde-c4f6-4de4-b3cc-
    [root@cop1 ~]# ipset list NIPv4a1d17fde-c4f6-4de4-b3cc-
    Name: NIPv4a1d17fde-c4f6-4de4-b3cc-
    Type: hash:net
    Revision: 6
    Header: family inet hashsize 1024 maxelem 65536
    Size in memory: 472
    References: 2
    Number of entries: 2
    Members:
    192.168.0.12
    192.168.0.22

    192.168.0.12 and 192.168.0.22 are two instances of the same project, both of which are in the default security group. This --match-set rule permits all traffic between hosts in the same security group, and those hosts are defined in an ipset.

  5. All incoming ICMP traffic is permitted; there’s an immediate RETURN jump, which returns to a default ACCEPT chain.
  6. All outbound traffic from the VM is allowed unless explicitly denied (-A neutron-openvswi-oe814ad4e-2 -j RETURN) – this makes sense, since our security group rules allowed egress traffic to anywhere.
  7. Incoming SSH traffic (TCP for dport 22) is allowed from hosts on the 203.0.113.0/24 subnet: -A neutron-openvswi-ie814ad4e-2 -s 203.0.113.0/24 -p tcp -m tcp --dport 22 -j RETURN
  8. Packets already part of an established connection are allowed by default. Invalid packets are dropped.
  9. Anything that doesn’t match for either input or output goes to the fallback chain. The fallback chain is a default DROP.

iptables is the userspace interface to the netfilter system within the kernel. netfilter provides all of the filtering of IPv4 and IPv6 packets entering, exiting or being routed through the system via any of the interfaces.

Crucially, netfilter only operates at the protocol layer (layer 3) of the kernel network stack. This will become an important point as we start to look at how OVS grabs packets from interfaces, in the next post.

Leave a Reply

Your email address will not be published. Required fields are marked *