Prevent existing iptables rules from opening ports to docker containers

Newbie here. I run a server from home, and just installed docker to get some services going that aren’t available otherwise, or are a pita to set up outside docker (radarr, vaultwarden, etc).

My iptables firewall is highly locked down, but unfortunately docker seems to carry over ports opened for non-docker services. EG: ssh, various ports for owncloud, etc. These ports do not need to be available to the docker containers, and as I’m using the docker services from outside my network, I’d like to prevent some of the carried over ports from being exposed.

Let’s use ssh for instance. I’m not unfamiliar with iptables, so if anyone could help me figure out how to stop the ssh port from being carried over, but still open to the host server itself, I can work out the others.

Help us to help you: how does your exact setup look like, what commands did you use to create it and publish your port (and whatever is necceresary to get the full picture).

Up to this day I never experience that services from the host leak inside a container. Though from every container, you can reach services on the host that are bound to 0.0.0.0 (=all ips) using the docker0 (defaults to the ip 172.17.0.1) and/or docker_gwbridge (defaults to the ip 172.18.0.1) interface or the hosts’s hostname or ip itself.

Additionaly it commonly known that docker punches published ports into the hosts firewall (iptables, ufw, firewalld) on some host os’es.

Ah, it’s the docker0 ip that’s got the additional ports open, but it appears the containers aren’t pulling them.

Is there a way to limit those ports on docker0?

Nmap output:

Starting Nmap 7.80 ( https://nmap.org ) at 2021-07-04 12:26 CDT
Nmap scan report for main (172.17.0.1)
Host is up (0.0000050s latency).
Not shown: 65522 closed ports
PORT STATE SERVICE
22/tcp open ssh
80/tcp open http
139/tcp open netbios-ssn
443/tcp open https
445/tcp open microsoft-ds
3012/tcp filtered twsdss
8000/tcp filtered http-alt
8080/tcp filtered http-proxy
8989/tcp open sunwebadmins
9000/tcp open cslistener
9003/tcp open unknown
9050/tcp filtered tor-socks
32400/tcp open plex

22, 8989, 9000, 9003, and 32400 should not be used by docker or containers currently. I’ve figured out that the filtered ports are ones specifically in use by docker/containers

By default docker adds two network interfaces to your host docker0 used by the default bridge network and docker_gwbridge used by custom bridge (+overlay for swarm) networks.

If you bind your service to 0.0.0.0 they will obviously bind to these two interfaces as well. A container will have its own ip and acts like a dedicated device in the used docker network. It just use the docker0/docker_gwbridge interface as gateway, thus appart of what you feel it does, it does not bind any host services to the container itself.

A container is always able to reach other devices that the host’s network can reach, unless there is no routing or you prevent it with a firewall. Though, I am not sure how reaching the very same service from the host, using the host’s lan ip is any different than accessing the very same services using the docker networks gateway ip?

The only situation where services from the host would “breach” into a container is, if you run the container in --network host mode, which lets the container run in the hosts network namespace and therefore act network-wise act like any other native process on the host. In this scenario even a firewall won’t help you.