3 ms·

> Even if you used ebtables to filter out containers talking to each others' MAC addresses, wouldn't they be able to send broadcast or multicast packets to comm

> Even if you used ebtables to filter out containers talking to each others' MAC addresses, wouldn't they be able to send broadcast or multicast packets to communicate with each other? I'm afraid my initiation to ebtables (and iptables) was yesterday, so feedback such as this is highly appreciated. I will explore this and add a test to the repo. > I guess it's not clear to me if the vulnerability/bug/whatever here is "two conspiring containers can establish a covert channel" or "a malicious container can send normal-looking traffic to a container, bypassing that container's firewall rules." In the context of a sandbox, I purport the vulnerability is that a malicious container can bypass the firewall. The covert channel is largely inevitable because ultimately the containers can modulate cpu usage to communicate via cpu timing (I read this in a security paper somewhere, not sure how actual implementation works). The impact of bypassing the firewall can be serious if the non-malicious container exposes any service without proper authentication (as is often done behind VPCs in the cloud). Given that a high number of official containers contain known vulnerabilities (according to dockerhub). This is a potential issue for a large number of docker users. > It does seem like the right answer is unique bridge networks per container. My thinking is along the same lines, although I'm wondering if a container can communicate with the host if L2 packets may be able to traverse the network bridges. If anyone has input here, it'd be greatly appreciated.

paulfurtado 9y ago
Re: bridge filtering You can use the iptables physdev extension to match based on a bridge port rather than a mac address. So to filter between containers, you can do: iptables -I FORWARD -m physdev --physdev-in vetha056126 -j DROP where vetha056126 is the name of the container's veth adapter's peer interface on the host.
- bthornbury 9y ago
  Perhaps I don't understand this rule properly, but isn't this dropping all traffic being forwarded from the interface?
  - paulfurtado 9y ago
    When the sysctl net.bridge.bridge-nf-call-iptables=1 is set, bridged packets will traverse iptables rules. I believe this is the default on modern Linux kernels, but may not be set by default on RHEL/CentOS systems. The iptables filter table has three chains: INPUT, OUTPUT, FORWARD. In a traditional non-bridge context: - INPUT means packets entering the host - OUTPUT means packets leaving the host - FORWARD means packets being forwarded through the host which are not destined for the host itself. In the context of a bridge, FORWARD means forwarding packets from one bridge port to another. You can test the simplest case of this with: iptables -I FORWARD -j DROP by adding that rule, two containers on the same host cannot communicate with each other despite the fact that their communication did not require any traditional routing from the host. This is because the bridge traffic also traversed iptables rules.

paulfurtado 9y ago

Re: bridge filtering You can use the iptables physdev extension to match based on a bridge port rather than a mac address. So to filter between containers, you can do: iptables -I FORWARD -m physdev --physdev-in vetha056126 -j DROP where vetha056126 is the name of the container's veth adapter's peer interface on the host.

bthornbury 9y ago
Perhaps I don't understand this rule properly, but isn't this dropping all traffic being forwarded from the interface?
- paulfurtado 9y ago
  When the sysctl net.bridge.bridge-nf-call-iptables=1 is set, bridged packets will traverse iptables rules. I believe this is the default on modern Linux kernels, but may not be set by default on RHEL/CentOS systems. The iptables filter table has three chains: INPUT, OUTPUT, FORWARD. In a traditional non-bridge context: - INPUT means packets entering the host - OUTPUT means packets leaving the host - FORWARD means packets being forwarded through the host which are not destined for the host itself. In the context of a bridge, FORWARD means forwarding packets from one bridge port to another. You can test the simplest case of this with: iptables -I FORWARD -j DROP by adding that rule, two containers on the same host cannot communicate with each other despite the fact that their communication did not require any traditional routing from the host. This is because the bridge traffic also traversed iptables rules.