Tools

Tools: Why Docker bypasses UFW and how to actually lock it down (2026)

2026-05-12 0 views admin
Tools: Why Docker bypasses UFW and how to actually lock it down (2026)

The setup that bit me

The root cause: Docker plays with iptables directly

Fix 1: Bind to localhost (the easiest one)

Fix 2: Don't publish the port at all

Fix 3: The DOCKER-USER chain

Prevention: a checklist I now actually follow 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. Here's the classic scenario. You've got a VPS. You install UFW because that's what every tutorial tells you to do: Then you spin up a database container with a published port for "local development access": 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. 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: 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. 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: 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. 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: 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. 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: 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. Here's the list I tape to my monitor (figuratively): 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. Templates let you quickly answer FAQs or store snippets for re-use. Hide child comments as well For further actions, you may consider blocking this person and/or reporting abuse

Command

Copy

$ -weight: 600;">sudo ufw default deny incoming -weight: 600;">sudo ufw default allow outgoing -weight: 600;">sudo ufw allow 22/tcp -weight: 600;">sudo ufw allow 80/tcp -weight: 600;">sudo ufw allow 443/tcp -weight: 600;">sudo ufw -weight: 500;">enable -weight: 600;">sudo ufw default deny incoming -weight: 600;">sudo ufw default allow outgoing -weight: 600;">sudo ufw allow 22/tcp -weight: 600;">sudo ufw allow 80/tcp -weight: 600;">sudo ufw allow 443/tcp -weight: 600;">sudo ufw -weight: 500;">enable -weight: 600;">sudo ufw default deny incoming -weight: 600;">sudo ufw default allow outgoing -weight: 600;">sudo ufw allow 22/tcp -weight: 600;">sudo ufw allow 80/tcp -weight: 600;">sudo ufw allow 443/tcp -weight: 600;">sudo ufw -weight: 500;">enable -weight: 500;">docker run -d \ --name pg \ -p 5432:5432 \ -e POSTGRES_PASSWORD=changeme \ postgres:16 -weight: 500;">docker run -d \ --name pg \ -p 5432:5432 \ -e POSTGRES_PASSWORD=changeme \ postgres:16 -weight: 500;">docker run -d \ --name pg \ -p 5432:5432 \ -e POSTGRES_PASSWORD=changeme \ postgres:16 -weight: 600;">sudo iptables -L DOCKER -n -v -weight: 600;">sudo iptables -t nat -L DOCKER -n -v -weight: 600;">sudo iptables -L DOCKER -n -v -weight: 600;">sudo iptables -t nat -L DOCKER -n -v -weight: 600;">sudo iptables -L DOCKER -n -v -weight: 600;">sudo iptables -t nat -L DOCKER -n -v -weight: 500;">docker run -d \ --name pg \ -p 127.0.0.1:5432:5432 \ -e POSTGRES_PASSWORD=changeme \ postgres:16 -weight: 500;">docker run -d \ --name pg \ -p 127.0.0.1:5432:5432 \ -e POSTGRES_PASSWORD=changeme \ postgres:16 -weight: 500;">docker run -d \ --name pg \ -p 127.0.0.1:5432:5432 \ -e POSTGRES_PASSWORD=changeme \ postgres:16 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 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 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 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 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 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 # Block everything coming in on the public interface first -weight: 600;">sudo iptables -I DOCKER-USER -i eth0 -j DROP # Then explicitly allow established connections back -weight: 600;">sudo iptables -I DOCKER-USER -i eth0 -m conntrack \ --ctstate ESTABLISHED,RELATED -j ACCEPT # Allow your office IP -weight: 600;">sudo iptables -I DOCKER-USER -i eth0 -s 203.0.113.42 -j ACCEPT # Block everything coming in on the public interface first -weight: 600;">sudo iptables -I DOCKER-USER -i eth0 -j DROP # Then explicitly allow established connections back -weight: 600;">sudo iptables -I DOCKER-USER -i eth0 -m conntrack \ --ctstate ESTABLISHED,RELATED -j ACCEPT # Allow your office IP -weight: 600;">sudo iptables -I DOCKER-USER -i eth0 -s 203.0.113.42 -j ACCEPT # Block everything coming in on the public interface first -weight: 600;">sudo iptables -I DOCKER-USER -i eth0 -j DROP # Then explicitly allow established connections back -weight: 600;">sudo iptables -I DOCKER-USER -i eth0 -m conntrack \ --ctstate ESTABLISHED,RELATED -j ACCEPT # Allow your office IP -weight: 600;">sudo iptables -I DOCKER-USER -i eth0 -s 203.0.113.42 -j ACCEPT - 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 -weight: 500;">status. Trust what the network actually sees. - Never run a database with the default password. I know. I know. Yet here we are.

🏷️ Tags

toolsutilitiessecurity toolsdockerbypassesactuallyiptablesdirectly

More from Tools

Tools: Complete Guide to Linux Essentials

Tools: Complete Guide to Linux Essentials

2026-05-12 0
Tools: Your AI Just Said “I Can’t do that Dave.” (2026)

Tools: Your AI Just Said “I Can’t do that Dave.” (2026)

2026-05-12 0
Tools: Stop Leaking API Keys: Managing Secrets in Kamal 2 (2026)

Tools: Stop Leaking API Keys: Managing Secrets in Kamal 2 (2026)

2026-05-12 0
Tools: Update: My fully offline AI-assisted Linux development machine

Tools: Update: My fully offline AI-assisted Linux development machine

2026-05-12 0

Trending

1

CVE-2025-61481: Critical Remote Code Execution Vulnerability in MikroTik RouterOS & SwitchOS

2025-10-27 • 189 views
2

CVE-2025-43939: Dell Unity OS Command Injection (High)

2025-10-30 • 148 views
3

Google disputes false claims of massive Gmail data breach

2025-10-30 • 130 views
4

Microsoft: DNS outage impacts Azure and Microsoft 365 services

2025-10-30 • 88 views
5

3.5B Accounts, 1 Critical Flaw: Meta Closes WhatsApp Data-Harvesting

2025-11-25 • 81 views