So every time you sit down in an internet cafe and connecting to the wifi, you are fucked because all the docker containers that run on your machine are open to everybody? Or - depending on the lan settings - at least to the wifi provider?
Also - shouldn't the web be full off vurnurable database servers then?
> So every time you sit down in an internet cafe and connecting to the wifi, you are fucked because all the docker containers that run on your machine are open to everybody?
Yes, if you're running docker on Linux. On Mac and Windows docker has to create a little linux VM so it's more isolated and not directly accessible without explicitly publishing ports.
Publishing ports to '*' is commonly done to allow Mac and Windows users to access containers through their browsers.
The macos firewall is able to block connections to these exposed sockets but:
1. The user has to explicitly turn on the firewall since it is off by default
2. The option "Automatically allow downloaded signed software to receive incoming connections" must be unchecked because Docker Desktop is signed by Apple.
I don't use a Mac, but all of the developers that use Macs at my company either did not have their firewall enabled or did not realize that connections to Docker Desktop were whitelisted.
Yep it's a good call out. Another good habit that you allude to is to publish ports to both an interface and port on the host system, not just a port (which assumes all interfaces, including external ones like wifi). The syntax slightly changes so you do command line option '-p "127.0.0.1:5000:5000"' which means on my host machine's localhost only (127.0.0.1) listen on port 5000 and forward it to port 5000 in the container. That way only a process running on my local machine can connect to my container and not someone else on the network if I forgot to turn on a firewall.
That will only work if you are on the same subnet.
When you craft a packet for that address, the stack will see that route and send an ARP "who has" request out whatever interface you assigned when you did that IP route rule (probably your default ethernet). If nobody responds than the packet dies in the stack.
172.16.0.0/12 is a private subnet. This means that it's addresses are relevant only within a local network, and never over the internet. If you try to send a packet to an address within that subnet, layer 3 devices (i.e. routers) on the internet will drop it.
> "shouldn't the web be full off vurnurable database servers then?"
It is. There are millions of servers out there with major security issues. Every few months there's another big story of a data breach from nothing more than a database left open.
Not if you have a firewall enabled on your machine, which everybody should.
edit: based on comments, added the FORWARD table, which supersedes Docker's rules and should block new connections forwarding from external interfaces.
edit 2: I'm wrong, this doesn't fix the bug. If you run `docker network create foobar`, it will move its rules up above the custom FORWARD rules. Ugh.
edit 3: Modified to add the rules to the DOCKER-USER table, which according to Docker[1], will always be evaluated first. So now it should actually fix the problem. They explain in the docs how to fix this situation, actually, and even how to prevent Docker from modifying iptables. Another example of why we should RTFM...
for tool in iptables ip6tables ; do
for intf in wlan+ eth+ ; do
for table in INPUT DOCKER-USER ; do
$tool -I $table 1 -i $intf -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
$tool -I $table 2 -i $intf -m conntrack --ctstate INVALID -j DROP
$tool -I $table 3 -i $intf -m conntrack --ctstate NEW -j DROP
done
done
iptables-save > /etc/iptables.rules
ip6tables-save > /etc/ip6tables.rules
As discussed extensively in https://github.com/moby/moby/issues/22054, which is linked from the OP: this doesn't actually help, because Docker (by default) bypasses your existing firewall rules.
Ah, forgot about forwarding table. These should fix that:
for tool in iptables ip6tables ; do
$tool -I DOCKER-USER 1 -i eth+ -m conntrack --ctstate NEW -j DROP
$tool -I DOCKER-USER 1 -i wlan+ -m conntrack --ctstate NEW -j DROP
done
If these are saved and loaded with the rest of networking, they will appear at the top of the FORWARD table before the DOCKER table jumps. Docker won't remove these rules, and they come first in the table, so they supersede Docker's rules. Any new connections forwarded from an external interface should drop.
....because then containers can't network at all to non-local networks, e.g. no internet access. for bridge networks at least (which is the default).
by specifying the drop for new connections incoming from the external interface, you stop connections to listening services from external networks, but established and related connections can continue implicitly, so forwarding still works for outbound connections.
if you really want to block all internet access for containers, and stop anything else on your system that might need to use forwarding, then your suggestion is correct.
Also - shouldn't the web be full off vurnurable database servers then?