That isn't just a docker thing, though a few notable accidents with docker have shone a light on the issue in recent times, and is one of the reasons I much prefer to keep my firewall away from where things are running, between them and the unwashed masses on the public network.

Even at home I have a separate small firewall box between the server that hosts things (and the rest of my network) instead of trusting that host to manage its own security in that way. If I run a service via docker or anything else on there, the outside world doesn't see it unless I open a way in elsewhere. For extra paranoia, the network leg that others can connect to (wireless AP & wired network ports in the guest room) is also separate and only sees parts of the server(s) I explicitly want it to (you can do this with vlans and such depending on your kit, I've actually just got an extra NIC on the router).

Never assume a process/service/container/etc is at all locked down, unless you have checked it out yourself or have it sufficiently wrapped in things you have locked off.

I accidentally opened up a Redis test-instance to the world like this.

So, if you're doing any filtering for internal network addresses == internal traffic, congratulations, now your inbound external IPV6 traffic is recognized as internal.

Assuming I add a rule via

`iptables -I INPUT -s 123.123.123.123 -p tcp --dport 8080 -j DROP`

and on interface:port 0.0.0.0:8080 of the host is a container listening which got run as

`docker run -d -p 0.0.0.0:8080:8080 some/server:latest`

Will that container still be accessible to 123.123.123.132?

I was bit by this once. Be very careful with docker. Do not rely blindly on your firewall of it runs on the same machine.

I'm not using --iptables=false but I'm not discounting the possibility that maybe I've configured this on a more global level somewhere.

I even follow this standard rule for pet projects