I have a server with a number of Linux bridge devices for use with groups of virtual machines - some internet-routed, some intentionally unrouted. I have stateful firewalling in place for traffic traversing across and between those bridges. Excerpt:
ip6tables -A FORWARD -m conntrack --ctstate ESTABLISHED -j ACCEPT
ip6tables -A FORWARD -m conntrack ! --ctstate NEW -j DROP
ip6tables -A FORWARD -i br21 -o br21 -m physdev --physdev-out vm21a -m tcp --dport 22 -j ACCEPT
ip6tables -A FORWARD -j DROP
Practically, this works. All connections that should work do work, non-spoofed connections are allowed or dropped in accordance with my port-based firewall rules. See this Q&A in Unix&Linux SE that for practical requisites & implications of using iptables on bridges in the first place.
On the security side of things, I may have overlooked important side-effects.
- Untrusted users can execute privileged code on virtual machines attached to some of my bridges.
- Goal: Untrusted users should not be able to learn about or interfere with connections on different bridges.
I suspect they can, because my fragment reassembly & conntrack table.. looks like one big table, no zones, no segmentation. Is this a real risk in my setup? If so, can I meaningfully mitigate it, by any means short of distributing the VMs to different hosts?
I am looking for answers that clearly spell out which subsystem(s) above which kernel version allow the suggested assertion or solution (but potentially referring back to U&L/SF for technical details). Clearly things have changed a lot over the years; One quote that predates among other work, the ability to create net namespaces:
conntrack is inherently a security hole when used as part of bridging, because it ignores the Ethernet header so two unrelated connections can be tracked as one.
