Hacker News Reader

Comment by TekMol | Hacker News Reader

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?

View on HN

> 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.

> Also - shouldn't the web be full off vurnurable database servers then?

No, the docker bridge network is not on a routable subnet.

Does it have to? The attack looks like it would also work over the internet:

    2. [ATTACKER] Route all packets destined for 172.16.0.0/12 through the victim's machine.

    ip route add 172.16.0.0/12 via 192.168.0.100

Here, "192.168.0.100" could be exchange for any ip address I guess?

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.

If that's true, you can then send packets to it, but not receive replies. That's still a problem.

Except you would have to be on the same layer 2 network as the "victim" for this to work.

> Also - shouldn't the web be full off vurnurable database servers then?

It already was, but yes.

> "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.

Have you ever heard of https://www.shodan.io/?

It seems to be some kind of search engine. How is it related to the topic at hand?

Sorry, should have been more clear. It was a reply to this part of your comment:

> Also - shouldn't the web be full off vurnurable database servers then?

You can search for open database servers there, which should answer your question.

It exposes/let's you search for unsecured IoT, IP cams etc, I assume OP implied searching for unsecured containers would be kind of similar.

It lets users search for misconfigured database instances that it has scraped - very relevant to the topic.

For a home style Wi-Fi yes. Hopefully you can’t reach Wi-Fi peers for Starbucks and it’s ilk.

Even if not - the wifi operator could still access your docker containers.

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

https://help.ubuntu.com/community/IptablesHowTo https://wiki.debian.org/iptables https://wiki.alpinelinux.org/wiki/Configure_Networking#Firew... https://wiki.archlinux.org/title/Iptables#Configuration_and_... [1] https://docs.docker.com/network/iptables/

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.

edit: changed from FORWARD to DOCKER-USER table

If you are going that far why not just:

    iptables -t filter -I FORWARD -j DROP

and while you are at it:

    sysctl -w net.ipv4.conf.all.forwarding=0
    sysctl -w net.ipv6.conf.all.forwarding=0

....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.

Docker creates its own iptables rules when its daemon runs, so unfortunately whatever firewall you setup will be ignored by exceptions it creates.

But isn't the point of TFA that regular docker (which runs with privileges) negates these rules effectively punching holes?

Reply on news.ycombinator.com