Saved in this browser and reused when you open other posts.
You were running your own servers. You thought you understood firewalls such as UFW rules, iptables, Cloudflare in front of everything. You'd done the reading. You knew what you were doing.
Then you set up Docker on a new server and watched it silently undo all of it.
This isn't a hypothetical. I found this the hard way, on a friend's server, after something was already listening on a port that had no business being open.
How It Started
The server was a fresh Ubuntu VPS. My friend had a Laravel application, a MySQL instance, a Redis cache, and a private admin panel they definitely did not want public. Standard setup. He had configured UFW before installing anything:
ufw default deny incoming ufw allow ssh ufw allow 80 ufw allow 443 ufw enable
Clean. Only ports 80, 443, and SSH open. He checked with `ufw status` and it looked exactly right. He ran `nmap` from my local machine against the server IP and the output confirmed it, three ports, nothing else.
Then He installed Docker, deployed the stack with Docker Compose, and moved on.
Three weeks later, a routine audit on their side flagged something in network logs. Traffic was hitting their server on port 6379. From an IP address in Romania. ⚠️
Redis. The cache that's supposed to be internal-only. Completely exposed to the internet. 😱
What Docker Does to Your Firewall
This is the thing that trips up a lot of people who come from a traditional server background. Docker doesn't treat nicely with UFW. It doesn't go through UFW. It goes around it.
When you map a port in Docker such as ports: 6379:6379 in your Compose file. Docker modifies iptables directly. It inserts its own rules into the DOCKER chain, which gets evaluated before the INPUT chain where UFW rules live. Your UFW deny incoming rule never gets a chance to fire.
The result: UFW says the port is blocked. `ufw status` says the port is blocked. But the port is actually open and accepting connections from anywhere.
You can verify this by running:
# UFW thinks everything is fine ufw status verbose # But iptables tells the real story iptables -L DOCKER -n
You'll see entries like:
ACCEPT tcp -- 0.0.0.0/0 172.17.0.2 tcp dpt:6379
That's Docker accepting connections from *anywhere* (`0.0.0.0/0`) and forwarding them to the Redis container. UFW knows nothing about it.
This behavior is documented. Docker's official docs mention it. But it's buried, and most tutorials don't bring it up at all. So you follow a guide, set up UFW, feel secure, and then publish Redis or MySQL or your admin panel to the entire internet without realizing it.
What an Attacker Finds
Redis with no authentication which was the default for a long time, and still is if you don't configure it is one of the most exploited services on the internet. Shodan lists hundreds of thousands of exposed Redis instances at any given moment.
What can someone do with access to an unauthenticated Redis? More than you'd expect.
If it's a Laravel app, the session data is probably in Redis. Someone with read access to Redis can steal sessions and log in as any authenticated user by including your admin accounts without knowing a single password.
Worse: if the Redis instance has write access and the server is running as root or a privileged user, there are known techniques to write SSH keys into the authorized_keys file via Redis. At that point it's full server compromise, not just a data breach.
In my friend's case, the logs showed connection attempts and some key enumeration. We couldn't confirm with certainty whether sessions were read. We had to assume they were, force-logout every active user, rotate all credentials, and notify the affected accounts. Not a fun conversation to have.
The Fix: Bind to localhost, Not the World
The cleanest solution is to stop publishing internal services to `0.0.0.0` in the first place.
In your `docker-compose.yml`, any service that doesn't need to be publicly accessible should bind only to localhost:
services: redis: image: redis:7-alpine ports: - "127.0.0.1:6379:6379" # localhost only — not 0.0.0.0 command: redis-server --requirepass your_strong_password_here mysql: image: mysql:8 ports: - "127.0.0.1:3306:3306" # same principle environment: MYSQL_ROOT_PASSWORD: your_root_password
The `127.0.0.1:` prefix tells Docker to bind the host-side port only to the loopback interface. Docker still creates its iptables rules, but they only accept connections from localhost not from external IPs.
For services that don't need to be exposed on the host at all (Redis accessed only by other containers in the same Compose stack), just remove the `ports` mapping entirely and use Docker's internal networking:
services: app: image: your-app depends_on: - redis - mysql # No ports needed here for internal communication redis: image: redis:7-alpine # No ports: mapping — only accessible within Docker network command: redis-server --requirepass your_strong_password_here mysql: image: mysql:8 # No ports: mapping
Containers in the same Compose project can reach each other by service name (`redis:6379`, `mysql:3306`) without any host port mapping. There's nothing to expose.
Fixing Docker's iptables Behavior at the Engine Level
If you want UFW to actually control Docker traffic, there's a configuration option in the Docker daemon that stops it from touching iptables directly:
Create or edit `/etc/docker/daemon.json`:
{
"iptables": false
}
Then restart Docker:
systemctl restart docker
The problem with this approach: now Docker's internal container-to-container networking can break too, because Docker relies on its own iptables rules for routing between containers and for NAT. You'd need to manage that routing manually with your own iptables or nftables rules. For most people this creates more problems than it solves. So please ingore it.
The Audit You Should Run Right Now
If you have Docker running on any server, check what's actually exposed at the iptables level, not just what UFW thinks is exposed:
# See all open ports on the host (Docker and non-Docker) ss -tlnp # See specifically what Docker has added to iptables iptables -L DOCKER -n --line-numbers # Or just scan yourself from outside nmap -p 1-65535 your.server.ip
That last one is the most honest. Run it from a machine outside your network and see what actually responds. If you see ports you didn't intentionally open, you have the same problem I found on that my friend's server.
Also check your Compose files for any service with a `ports:` mapping that uses only a port number or `0.0.0.0`:
# Find potentially dangerous port mappings in your Compose files grep -r '"[0-9]*:[0-9]*"' /path/to/your/compose/files grep -r "'[0-9]*:[0-9]*'" /path/to/your/compose/files
One More Thing That Makes This Worse
The default Docker network (`172.17.0.0/16`) is also reachable from other containers, even across different Compose projects on the same host. If you're running multiple client applications on one server, a compromised container in one project can potentially reach services in another project if they're all on the default bridge network.
Use named networks and keep projects isolated:
networks: internal: driver: bridge services: app: networks: - internal redis: networks: - internal
This won't stop everything, but it reduces the blast radius significantly if something does get compromised.
What I Changed After This
On every server where I deploy Docker now, my checklist before going live:
1. Run `nmap -p 1-65535` against the public IP from an external machine
2. Verify every `ports:` mapping in every Compose file has `127.0.0.1:` prefix or is removed entirely
3. Redis and MySQL never have host port mappings unless there's an explicit reason
4. All services that only talk to each other get put on a named internal network with no host exposure
5. Redis always runs with `--requirepass` even on internal networks
Most of this takes five minutes to get right. The problem is that most Docker tutorials skip it entirely, they show you `ports: "6379:6379"` and move on, and nobody mentions that you just published your cache server to the planet.
Run the nmap scan. Not later, now. It takes thirty seconds and you might not like what you find.