5 ms·
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
by TekMol 4y ago
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?
- R0b0t1 4y ago> Also - shouldn't the web be full off vurnurable database servers then? It already was, but yes.
- albatruss 4y ago> Also - shouldn't the web be full off vurnurable database servers then? No, the docker bridge network is not on a routable subnet.
- TekMol 4y agoDoes 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?
- gcbirzan 4y agoExcept you would have to be on the same layer 2 network as the "victim" for this to work.
- thedougd 4y agoIf that's true, you can then send packets to it, but not receive replies. That's still a problem.
- jandrese 4y agoThat 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.
- Plutoberth 4y ago172.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.
- 0xbadcafebee 4y agoNot 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://help.ubuntu.com/community/IptablesHowTo https://wiki.debian.org/iptables https://wiki.debian.org/iptables https://wiki.alpinelinux.org/wiki/Configure_Networking#Firewalling_with_iptables_and_ip6tables https://wiki.alpinelinux.org/wiki/Configure_Networking#Firew... https://wiki.archlinux.org/title/Iptables#Configuration_and_usage https://wiki.archlinux.org/title/Iptables#Configuration_and_... [1] https://docs.docker.com/network/iptables/ https://docs.docker.com/network/iptables/
- sigg3 4y agoBut isn't the point of TFA that regular docker (which runs with privileges) negates these rules effectively punching holes?
- deleted 4y ago[deleted]
- teraflop 4y agoAs discussed extensively in https://github.com/moby/moby/issues/22054 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.
- k8sToGo 4y agoHave you ever heard of https://www.shodan.io/ https://www.shodan.io/?
- TekMol 4y agoIt seems to be some kind of search engine. How is it related to the topic at hand?
- k8sToGo 4y agoSorry, 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.
- Matl 4y agoIt exposes/let's you search for unsecured IoT, IP cams etc, I assume OP implied searching for unsecured containers would be kind of similar.
- alexchantavy 4y agoIt lets users search for misconfigured database instances that it has scraped - very relevant to the topic.
- manigandham 4y ago> "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.
- bnjms 4y agoFor a home style Wi-Fi yes. Hopefully you can’t reach Wi-Fi peers for Starbucks and it’s ilk.
- TekMol 4y agoEven if not - the wifi operator could still access your docker containers.
- qbasic_forever 4y ago> 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.
- guns 4y agoPublishing 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.
- qbasic_forever 4y agoYep 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.