Originally published at fatihsennik.com

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.