Why Docker bypasses UFW and how to actually lock it down

I exposed a Postgres container to the public internet. Again. Same mistake, third time in maybe two years. The firewall was on, ufw status looked clean, and I still woke up to a flood of login attempts from IPs I'd never heard of.

If you've ever run ufw deny 5432 and assumed your database was safe behind a Docker container, this post is for you. I'm writing it mostly so future-me stops repeating the same mistake.

The setup that bit me

Here's the classic scenario. You've got a VPS. You install UFW because that's what every tutorial tells you to do:

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable

Then you spin up a database container with a published port for "local development access":

docker run -d \
  --name pg \
  -p 5432:5432 \
  -e POSTGRES_PASSWORD=changeme \
  postgres:16

You check ufw status. Port 5432 isn't allowed. You feel safe. You shouldn't.

From another machine, run nmap -p 5432 your.server.ip and watch port 5432 happily report back as open. Your firewall did nothing.

The root cause: Docker plays with iptables directly

UFW is not a firewall. It's a friendly wrapper around iptables (or nftables on newer systems). When you ufw allow or ufw deny, it writes rules into specific iptables chains, mostly INPUT and ufw-user-input.

Docker is also not asking UFW for permission. When you publish a port with -p, the Docker daemon writes its own iptables rules — directly into the DOCKER chain, hooked off the FORWARD and PREROUTING chains. It uses DNAT to forward packets straight to the container's internal IP on the docker0 bridge.

This is the key bit that took me embarrassingly long to internalize: packets destined for a published container port never traverse the INPUT chain. They get DNAT'd in PREROUTING and then forwarded. UFW's rules live in INPUT. The two systems are operating on entirely different parts of the packet path.

You can see it yourself:

sudo iptables -L DOCKER -n -v
sudo iptables -t nat -L DOCKER -n -v

You'll see ACCEPT rules for whatever ports your containers published, and DNAT rules in the nat table forwarding traffic to container IPs like 172.17.0.2:5432. UFW never gets a say.

This is documented behavior, by the way — the Docker docs have a page literally called "Docker and iptables" that explains it. I just didn't read it carefully enough the first three times.

Fix 1: Bind to localhost (the easiest one)

If the service only needs to be reachable from the host itself, bind the published port to 127.0.0.1 instead of the default 0.0.0.0:

docker run -d \
  --name pg \
  -p 127.0.0.1:5432:5432 \
  -e POSTGRES_PASSWORD=changeme \
  postgres:16

Or in compose:

services:
  db:
    image: postgres:16
    ports:
      # Bind explicitly to loopback — not reachable from the network
      - "127.0.0.1:5432:5432"
    environment:
      POSTGRES_PASSWORD: changeme

This is what I should have done from day one. Docker still adds its NAT rule, but the rule only matches on the loopback interface. External traffic gets dropped at the kernel level before any of this matters.

This is by far the fix I reach for most often now. If you don't need a port to be reachable from outside the host, don't make it reachable from outside the host.

Fix 2: Don't publish the port at all

If two containers need to talk to each other, they don't need a published port. Put them on the same Docker network and use the service name:

services:
  db:
    image: postgres:16
    # No ports section at all
    environment:
      POSTGRES_PASSWORD: changeme

  api:
    image: my-api
    depends_on:
      - db
    environment:
      # Resolves via Docker's internal DNS
      DATABASE_URL: postgres://postgres:changeme@db:5432/postgres

No ports: means no DNAT, means no iptables surprise. The database is reachable from the API container and nowhere else.

I now treat every ports: entry as something I have to justify out loud. "Why does this need to be reachable from outside Docker's network?" If I can't answer, it doesn't get published.

Fix 3: The DOCKER-USER chain

Sometimes you actually need a port published — say, a reverse proxy in front of your apps — but you want UFW-style rules to apply. Docker reserves a chain called DOCKER-USER that runs before its own rules. Anything you put there will be respected.

Here's a minimal example that blocks all external traffic to container ports except from a specific source IP:

# Block everything coming in on the public interface first
sudo iptables -I DOCKER-USER -i eth0 -j DROP

# Then explicitly allow established connections back
sudo iptables -I DOCKER-USER -i eth0 -m conntrack \
  --ctstate ESTABLISHED,RELATED -j ACCEPT

# Allow your office IP
sudo iptables -I DOCKER-USER -i eth0 -s 203.0.113.42 -j ACCEPT

Rules in DOCKER-USER survive container restarts but not host reboots unless you persist them. On Debian-likes, iptables-persistent handles that. There are also community-maintained scripts that bridge UFW config into the DOCKER-USER chain — they work, but inspect them carefully before you trust them with your production firewall.

Prevention: a checklist I now actually follow

Here's the list I tape to my monitor (figuratively):

• Default to not publishing ports. If services only talk to each other, use a Docker network.
• If you must publish, bind to 127.0.0.1 unless you have a specific reason not to.
• For anything truly public (80, 443), put it behind a reverse proxy in its own container, and let that be the only thing with a 0.0.0.0 binding.
• After deploying anything, run nmap or ss -tlnp from outside the box. Don't trust ufw status. Trust what the network actually sees.
• Never run a database with the default password. I know. I know. Yet here we are.

The deeper lesson, which I keep relearning: UFW gives you a feeling of security that is decoupled from the actual security posture of your host. It's a UI over one specific set of iptables chains. Anything else writing to iptables — Docker, Kubernetes' kube-proxy, libvirt, Tailscale — can and will route around it. Verify externally, every time.

Anyway. Filing this one under "things I've now written a 1200-word post about so I'll finally remember." Ask me again in six months.