Docker publishes ports straight past ufw, and most people never notice

If you run ufw default deny incoming, then start a container with -p 3306:3306, port 3306 is open to the internet. ufw says it is closed. ss -tlnp on the host shows it listening. Anyone can connect.

This is the single most common finding when adminxo scans a new server, and it is almost always a surprise to the person who set up the firewall.

What is happening

ufw manages the INPUT chain of iptables. Docker publishes ports by adding rules to the FORWARD chain and to its own DOCKER chain in the nat table, which run before and independently of INPUT. Traffic to a published port is translated and forwarded to the container without ever being evaluated by the rules ufw wrote. Both tools are working as designed; they just do not know about each other.

The usual advice is to bind published ports to localhost (-p 127.0.0.1:3306:3306) or to set "iptables": false in Docker’s daemon config and manage everything yourself. The first is correct and nobody remembers to do it. The second breaks networking between containers in ways that take an afternoon to debug.

What adminxo does about it

The agent reads the Docker socket and lists every published port with its bind address. Anything bound to 0.0.0.0 or :: on a port that ufw believes is closed is flagged as “published past the firewall”. The ports page shows these in their own group, separate from ordinary listening services, with the container name next to each one.

The one-click fix is the DOCKER-USER chain, which Docker provides for exactly this purpose and evaluates before its own rules. adminxo inserts a rule there that drops traffic to the port from anything other than the addresses you allow. It does not touch Docker’s config and does not restart the daemon, so containers keep talking to each other.

If the port is for a database, the fix also offers to move it to the server’s private network interface, which is what most people wanted in the first place.

The security score

This check is one line item in the 0 to 100 score adminxo gives each server. The others are the usual list: root login over SSH, password authentication, unattended upgrades, NOPASSWD in sudoers, fail2ban present and running, world-readable .env files in the home directory. None of them is exotic. The score exists because a list of twelve findings is easy to ignore and a number that went from 41 to 88 after four clicks is not.

A note on the agent

The agent needs root to read iptables and the Docker socket. It runs as a systemd service, connects outbound to the panel, and the firewall changes it makes are validated before they are applied: the SSH port is detected from sshd -T and never closed, and the sshd config is checked with sshd -t before a reload. We would rather the fix fail than lock you out.