Controlled container communication

Return to Sender

Docker enables the configuration of virtual networks and, for its part, makes extensive use of iptables on Linux to configure network communication between the containers, the host system, and remote computers. However, if you want to secure running containers, it is not enough to just look at the host's INPUT chain and filter incoming traffic.

As a firewall administrator, you might know the feeling when you have added a filter rule to your ruleset and realize afterward that it does not serve the intended purpose. Iptables as a packet filter is still the tool of choice on Linux systems. However, automatically added rules (e.g., those created by the Docker daemon) always lead to side effects in manually or semi-automatically created rulesets. The bigger security problem, however, arises when a rule is supposed to filter incoming packets, but it is not taken into account when packets for Docker containers are received.

Tables and Chains

The basic organization of filter rules in iptables is easy to explain. The three best-known tables are filter , mangle , and NAT . The filter table is used mainly to create those rules that make up a packet filter. The mangle table lets you specifically manipulate the fields of the IP header and mark the packets in the kernel to identify them in other rules when passing through the iptables chains.

Within the NAT table, you define rules to perform address translation for the packets during packet forwarding. On your home router, for example, you can use the NAT table to send packets from your private network area to the Internet and to reassign received packets to the corresponding computers on your private network.

The raw and security tables are used far less frequently and provide functionality to prevent connection tracking or to mark packets in SELinux contexts.

Each of the five tables have different

... comments powered by Disqus