Docker docs:
Docker routes container traffic in the nat table, which means that packets are diverted before it reaches the INPUT and OUTPUT chains that ufw uses. Packets are routed before the firewall rules can be applied, effectively ignoring your firewall configuration.
This was a large part of the reason I switched to rootless podman for everything
Explicitly binding certain ports to the container has a similar effect, no?
I still need to allow the ports in my firewall when using podman, even when I bind to 0.0.0.0.
Also when using a rootfull Podman socket?
I haven’t tried rootful since I haven’t had issues with rootless. I’ll have to check on that and get back to you.
When running as root, I did not need to add the firewall rule.
Thanks for checking
It’s better than nothing but I hate the additional logs that came from it constantly fighting firewalld.
This is the way.
It’s my understanding that docker uses a lot of fuckery and hackery to do what they do. And IME they don’t seem to care if it breaks things.
To be fair, the largest problem here is that it presents itself as the kind of isolation that would respect firewall rules, not that they don’t respect them.
People wouldn’t make the same mistake in NixOS, despite it doing exactly the same.
I don’t know how much hackery and fuckery there is with docker specifically. The majority of what docker does was already present in the Linux kernel namespaces, cgroups etc. Docker just made it easier to build and ship the isolated environments between systems.
If I had a nickel for every database I’ve lost because I let docker broadcast its port on 0.0.0.0 I’d have about 35¢
How though? A database in Docker generally doesn’t need any exposed ports, which means no ports open in UFW either.
I exposed them because I used the container for local development too. I just kept reseeding every time it got hacked before I figured I should actually look into security.
For local access you can use
127.0.0.1:80:80and it won’t put a hole in your firewall.Or if your database is access by another docker container, just put them on the same docker network and access via container name, and you don’t need any port mapping at all.
Yeah, I know that now lol, but good idea to spell it out. So what Docker does, which is so confusing when you first discover the behaviour, is it will bind your ports automatically to
0.0.0.0if all you specify is27017:27017as you port (without an IP address prefixing). AKA what the meme is about.
Where are you working that your local machine is regularly exposed to malicious traffic?
My use case was run a mongodb container on my local, while I run my FE+BE with fast live-reloading outside of a container. Then package it all up in services for docker compose on the remote.
Ok… but that doesn’t answer my question. Where are you physically when you’re working on this that people are attacking exposed ports? I’m either at home or in the office, and in either case there’s an external firewall between me and any assholes who want to exploit exposed ports. Are your roommates or coworkers those kinds of assholes? Or are you sitting in a coffee shop or something?
This was on a VPS (remote) where I didn’t realise Docker was even capable of punching through UFW. I assumed (incorrectly) that if a port wasn’t reversed proxied in my nginx config, then it would remain on localhost only.
Just run
docker run -p 27017:27017 mongo:lateston a VPS and check the default collections after a few hours and you’ll likely find they’re replaced with a ransom message.Ah, when you said local I assumed you meant your physical device
This post inspired me to try podman, after it pulled all the images it needed my Proxmox VM died, VM won’t boot cause disk is now full. It’s currently 10pm, tonight’s going to suck.
eh, booting into single user mod should work fine, uninstall podman and init 5
Okay so I’ve done some digging and got my VM to boot up! This is not Podman’s fault, I got lazy setting up Proxmox and never really learned LVM volume storage, while internally on the VM it shows 90Gb used of 325Gb Proxmox is claiming 377Gb is used on the LVM-Thin partition.
I’m backing up my files as we speak, thinking of purging it all and starting over.
Edit: before I do the sacrificial purge This seems promising.
This only happens if you essentially tell docker “I want this app to listen on 0.0.0.0:80”
If you don’t do that, then it doesn’t punch a hole through UFW either.
You’re forgetting the part where they had an option to disable this fuckery, and then proceeded to move it twice - exposing containers to everyone by default.
I had to clean up compromised services twice because of it.
This is why I install on bare metal, baby!
Nat is not security.
Keep that in mind.
It’s just a crutch ipv4 has to use because it’s not as powerful as the almighty ipv6
Somehow I think that’s on ufw not docker. A firewall shouldn’t depend on applications playing by their rules.
ufw just manages iptables rules, if docker overrides those it’s on them IMO
Feels weird that an application is allowed to override iptables though. I get that when it’s installed with root everything’s off the table, but still…
Linux lets you do whatever you want and that’s a side effect of it, there’s nothing preventing an app from messing with things it shouldn’t.
there’s nothing preventing an app from messing with things it shouldn’t.
that’s not exactly a linux specialty
Not really.
Both docker and ufw edit iptables rules.
If you instruct docker to expose a port, it will do so.
If you instruct ufw to block a port, it will only do so if you haven’t explicitly exposed that port in docker.
Its a common gotcha but it’s not really a shortcoming of docker.
iptables is deprecated for like a decade now, the fact that both still use it might be the source of the problem here.
On windows (coughing)
Wait, that’s illegal
Well yea ofc it works like that, the services are not on the same network, so the packets need to be sent onto another adapter. That means either nat or forwarding tables.
Now if that was a good design of docker is another question.
That caused issues with Docker containers being unable to communicate with eachother for me.
Did you allow the containers to talk to eachother with ufw after setting it up?
Yes, you can fix it by doing this
echo "Adding rules for Docker subnets to allow communication between containers..." for subnet in $(docker network inspect bridge -f '{{range .IPAM.Config}}{{.Subnet}} {{end}}'); sudo ufw allow from $subnet echo "Added rule for $subnet" done
