Basically, I have this doubt, I have some self hosted services in docker where I add the ports like this:
host_port:container_port, so I don’t specify the interface, so by default, it is 0.0.0.0.
Somebody recently told me that this is dangerous and that I expose my services to the public internet by doing this. I don’t want to do that since I am the only one accessing them so I just use a vpn to access them. So, to try this out, I typed in my browser my public ip alongside the host port I used for one of my services but I cannot access it. This has me puzzled. How’s the deal? Am I exposing it? Should I change it?
What are your thoughts? Thanks!
You’re not exposing anything unless your router/firewall explicitly allows it.
0.0.0.0 just means “all addresses on this host”. So binding to 0.0.0.0:80 means “listen on every IP address, TCP port 80”
So say you have a Linux box, and it has 4 network interfaces: 127.0.0.1 (localhost), 192.168.1.101 (main local network), 192.168.1.201 (second local network), and 172.16.10.1 (docker network).
If you run a service on the Linux box, and specify that it listens on 0.0.0.0:80, that service will bind to all of those addresses, and be accessible via 127.0.0.1:80, both 192 addresses, and the docker network address.
Now, if you run that same configuration in a docker container without the “-p host:container”, it will bind to the address given it in the docker network and only that address.
If you run that same container with the -p host:container, it will bind to and listen on all network addresses.
I hope that’s understandable, I’m kinda out of it today so I hope I’m not too incoherent!
A few things, in no particular order:
- Docker interferes with user-defined firewall rules on the host. You need to expend a lot of effort to make your rules persist above docker. This functionally means that, if you are running a public-facing VPS/dedicated server and bind services to 0.0.0.0, even if you set up a firewall on the same machine, it won’t work and your services will be publicly accessible
- If you have access to a second firewall device — whether it is your router at home, or your hosting provider’s firewall (Hetzner, OVH both like to provide firewall controls external to your server) — this is not the biggest concern.
- There is no reason to bind your containers to 0.0.0.0. You will usually access most of your containers from a certain IP address, so just bind them to that IP address. My preference is to bind to any address in the 127.0.0.0/8 subnet (yes, that entire subnet is loopback) and then use a reverse proxy. Alternatively, look into the ‘macvlan’ and ‘ipvlan’ docker network drivers.
Good luck
Hey! Thanks a lot for your reply! I just have two other questions. First of all, the address is regarding the host right? And that ip should be the static ip of the computer or the 127…?And also, is there a way to put that same ip for all services in the docker compose file or I have to do it for everyone manually? Thanks again!
0.0.0.0 means it binds to every available address on your docker host. If your host has a directly available public IP, then i can understand the concern.
if your box is behind your network firewall, then you would have to port forward to have the service reachable from the internet.
You’re welcome to bind to a specific IP on your host, I do this over plain 0.0.0.0. Looks cleaner that way IMO.
i use static IPs and it’s been fine for me for months-years now.
But why do you have UPnP enabled?
I never put a host ip in my compose files.
Although… In portainer… I set my IP in some setting so that the container links wouldn’t just show up as 0.0.0.0:xxxx
