Docker uses netfilter (the Linux firewall) rules to create its internal container network and port bindings to the host system.
These rules have precedence over regular rules and may make it harder to filter traffic to containers not to mention the risk of unexpected behavior on container traffic.
Podman works differently and poses different possible firewall issues. We'll probably release a similar article about Podman later.
Let's say you have a container running with a global port binding, for instance port TCP 22 for SSH.
You try blocking that port using a rule in the INPUT chain, e.g.:
iptables -A INPUT -p tcp -s !172.20.0.0/16 --dport 22 -j REJECT
It doesn't matter whether that rule is inserted before all the Docker rules or not, it won't block traffic and the port will still be fully accessible, which may be a security issue.
There's a warning on the Docker documentation page about installing Docker on Debian underlining this very issue:
They mention ufw and firewalld but the issue will happen with basic iptables as well unless you use a very specific iptables chain as described later in the article.
The Docker iptables chains
Docker creates several of its own iptables chains.
You can see it using:
Chain INPUT (policy ACCEPT) target prot opt source destination Chain FORWARD (policy ACCEPT) target prot opt source destination DOCKER-USER all -- 0.0.0.0/0 0.0.0.0/0 DOCKER-ISOLATION-STAGE-1 all -- 0.0.0.0/0 0.0.0.0/0 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 ctstate RELATED,ESTABLISHED DOCKER all -- 0.0.0.0/0 0.0.0.0/0 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 Chain OUTPUT (policy ACCEPT) target prot opt source destination Chain DOCKER (1 references) target prot opt source destination ACCEPT tcp -- 0.0.0.0/0 172.17.0.2 tcp dpt:5667 Chain DOCKER-ISOLATION-STAGE-1 (1 references) target prot opt source destination DOCKER-ISOLATION-STAGE-2 all -- 0.0.0.0/0 0.0.0.0/0 RETURN all -- 0.0.0.0/0 0.0.0.0/0 Chain DOCKER-ISOLATION-STAGE-2 (1 references) target prot opt source destination DROP all -- 0.0.0.0/0 0.0.0.0/0 RETURN all -- 0.0.0.0/0 0.0.0.0/0 Chain DOCKER-USER (1 references) target prot opt source destination RETURN all -- 0.0.0.0/0 0.0.0.0/0
In regular cases, the port bindings should appear in the DOCKER chain, as seen with the port 5667 in the example listing above.
Prerequisite: persistent firewall rules
Adding rules with iptables doesn't make them persistent. Rules are compiled as an in-memory set ready to use for the kernel.
There are multiple ways to persist firewall rules. As of today and for the Debian distribution, we believe the easiest way is to use a special package called iptables-persistent.
First you need to install "iptables" as the utility isn't present by default because Debian 11 uses nftables (with the utility nft) which we may dedicate a future blog article to.
After Docker is installed, you can install these packages:
apt install iptables iptables-persistent
The config wizard will ask you if you want to save the current firewall rules now and you should always say yes, unless, for instance, Docker isn't installed yet.
If you need to manually persist the rules, you can always use the iptables-save utility:
iptables-save > /etc/iptables/rules.v4
Obviously only for the ipv4 rules. Make sure to have full coverage of rulesets if you use ipv6 for public access as well.
Do note that you still have to manually save the iptables rules with the command shown above when you add, delete or edit rules or they wont be restored at the next system start.
The DOCKER-USER chain
The DOCKER-USER chain is meant to hold your own firewall rules that are processed before all of the other rules and especially before the other Docker-related chains.
However, using it to filter by source IP address or range, which is almost always what we'll want to do, isn't that easy.
It requires using kernel connection tracking which isn't the fastest thing in the world but will work for your basic needs.
Allow everyone but some source IP addresses/ranges
First we need to allow already established traffic or nothing will work, the following rule has to be added first, and only once (don't forget to persist your rules using iptables-save when relevant):
iptables -I DOCKER-USER -p tcp -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
Now if you want to allow everyone to connect to a specific port except for, let's say, IP range 192.168.0.0/24, you could just add the following rule:
iptables -I DOCKER-USER -p tcp -m conntrack --ctorigsrc 192.168.0.0/24 --ctorigdstport 80 -j DROP
And it'll work, except what we usually want to do is block everyone by default and only allow certain IP addresses or ranges.
Also, while we're at it, do note that we need to specify the protocol (tcp or udp) and you'll have to duplicate the rule when you need to support both.
Block everyone but some source IP addresses/ranges
A more classical use case is only allowing specific IP addresses or ranges to reach the exposed container port.
Since rules are processed from top to bottom with the first matching rule getting applied, we need some kind of DROP or REJECT rules for the port at the very end of the ruleset, order is very important.
The DOCKER-USER chain should already come with a RETURN rule that can stay there provided it's always the very last rule:
~# iptables -L DOCKER-USER Chain DOCKER-USER (1 references) target prot opt source destination RETURN all -- anywhere anywhere
To create the initial setup you can use the "-I" option of iptables (to insert) in that order so that the first rule will appear last (well, right before the initial RETURN rule):
iptables -I DOCKER-USER -p tcp -m conntrack --ctorigdstport 80 -j DROP iptables -I DOCKER-USER -p tcp -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT iptables -I DOCKER-USER -s 172.17.0.0/16 -j ACCEPT
Where the container port in this example is TCP 80, make sure to change it to your needs.
We're always allowing the whole 172.17.0.0/16 range because without that, the containers won't be able to use the blocked port (port 80 in this example) at all for any destination IP address in the outside and that's pretty much never desired.
172.17.0.0/16 is the Docker network range on that host, it can sometimes be set to something else. Check that it's correct by looking at the assigned IP address and network on interface docker0, for instance by issuing the command:
ip -c a
Now when we want to allow some IP address or range to reach that port, we can just insert a rule above like so:
iptables -I DOCKER-USER -s <IP_ADDRESS_OR_RANGE> -p tcp -m conntrack --ctorigdstport 80 -j ACCEPT
Ruleset for DOCKER-USER should now look like so:
~# iptables -L DOCKER-USER Chain DOCKER-USER (1 references) target prot opt source destination ACCEPT tcp -- 192.168.77.177 anywhere ctorigdstport 80 ACCEPT all -- 172.17.0.0/16 anywhere ACCEPT tcp -- anywhere anywhere ctstate RELATED,ESTABLISHED DROP tcp -- anywhere anywhere ctorigdstport 80 RETURN all -- anywhere anywhere
Where I allowed 192.168.77.177 to reach the Docker port 80 in this example.
Add more of these rules to allow more traffic to the ports you want.
Note: the Docker host should still be able to reach the port as its traffic doesn't seem to go through the DOCKER-USER chain. Please correct me in the comments if that's wrong.
You can find some more info about iptables filtering on the official documentation.
Conclusion & alternatives
There are alternatives to the solution presented here.
However, you probably now understand that Docker networking isn't that simple.
It's possible to use another dedicated bridge or even the "host" network for Docker container (the later is sometimes used for performance reasons) as well as more intricated firewall rules or userland forwarding / proxy programs, but that'll be a subject for another time.
In the meantime when you just want to bind a Docker container to a local port on the Docker host, you can specify 127.0.0.1 in the port bindings to make it only bind to the loopback interface.
E.g. for a simple Nginx container:
docker run -d --name nginx-server -p 127.0.0.1:80:80 nginx