Verifying actual network exposure · Docker & Containers

docker ps shows what you intended to expose. It reads the container’s configuration back to you. So does the Compose file, so does docker inspect, and so does your firewall ruleset — all four are records of intent, written by you, reporting on themselves.

Only one check on a Docker host is capable of returning an answer you did not already put there: a connection attempt from a machine that is not this one.

Four sources, three of them describing intent

Source	What it actually tells you
`docker ps --format '{{.Ports}}'`	The port mapping recorded in the container config
`docker port "$CONTAINER"`	The same mapping, one container, machine-readable
`ss -tlnp`	Host sockets in LISTEN — and see below, this omits published ports on some hosts
`sudo iptables -t nat -S DOCKER`	The DNAT rules that actually implement publishing
`nc`/`nmap` from another host	Reachability. The only one that can contradict you.

Start with the first four to build the expectation. Finish with the fifth to test it.

The listener that is not there

This is the trap that makes ss untrustworthy on a Docker host.

Read-only / Safeuserland proxy enabled— Default configuration: userland-proxy is true, so a docker-proxy process holds a real socket.

$ docker run -d --name web -p 8080:80 nginx:1.27-alpine
sudo ss -tlnp | grep 8080

LISTEN 0  4096  0.0.0.0:8080  0.0.0.0:*  users:(("docker-proxy",pid=2841,fd=7))

Illustrative output

Now the same container on a host with "userland-proxy": false in daemon.json:

Read-only / Safeuserland proxy disabled

$ sudo ss -tlnp | grep 8080
echo "exit status: $?"
sudo iptables -t nat -S DOCKER | grep 8080

exit status: 1
-A DOCKER ! -i docker0 -p tcp -m tcp --dport 8080 -j DNAT --to-destination 172.17.0.2:80

Illustrative output

ss finds nothing. The port is fully open to the internet.

A published port is not always a socket on the host

There is no process listening on 8080 in the second case, because nothing on the host ever accepts that connection. The kernel rewrites the destination in PREROUTING and forwards the packet to the container, where the listening socket lives in a different network namespace.

ss, netstat, lsof -i and every audit script built on them enumerate sockets in the host’s network namespace. A DNAT rule is not a socket.

This is how an inventory script certifies a host as clean while it is serving an admin panel to the internet. Worse, the script is not obviously broken — it produces correct, complete output about the wrong thing, and it produced the right answer on the previous host where the userland proxy happened to be enabled.

Treat ss as an inventory of what the host serves. For what the host plus its containers serve, you need the nat table and an external probe.

The probe that can fail

Read-only / Safeprobe from elsewhere— Run from a second machine. Scan only hosts you are authorised to scan.

TARGET=203.0.113.10

# One port, quickly
nc -z -w 3 "$TARGET" 8080 && echo "OPEN" || echo "closed"

# The ports you believe are open, plus a sample of ones you do not
nmap -Pn -p 22,80,443,3306,5432,6379,8080,9090 "$TARGET"

# The honest version: every TCP port. Slow, and worth it once a quarter.
nmap -Pn -sT -p- "$TARGET"

Probing from the Docker host proves nothing

curl http://localhost:8080 on the Docker host will succeed whether or not the port is reachable from anywhere else, and it will succeed for reasons that have nothing to do with your firewall:

Loopback traffic to a published port is handled by docker-proxy, which is what the --userland-proxy option exists for — its documented description is “Use userland proxy for loopback traffic”. A local connect can succeed through the proxy on a host where the forward path is fully blocked.
Locally generated packets take the OUTPUT path, not PREROUTING followed by FORWARD. Your DOCKER-USER rules are not consulted.
iif lo accept is in essentially every input chain ever written.

So the local test is a test of the loopback path. It answers a question nobody asked. If the only machine you can probe from is the Docker host itself, you do not yet have a verification — you have a second opinion from the same source.

Reading the disagreement

When the external probe and your expectation differ, the next command tells you which mechanism decided.

Read-only / Safecorrelate— Run on the Docker host straight after the probe, while the counters are fresh.

# Did a DOCKER-USER rule participate at all? Zero packets means no.
sudo iptables -L DOCKER-USER -v -n --line-numbers

# What does Docker think is published?
sudo iptables -t nat -S DOCKER

# What does the container config say?
docker ps --format '{{.Names}}\t{{.Ports}}'

# What is the container actually listening on, inside its own namespace?
CONTAINER=web
docker exec "$CONTAINER" sh -c 'ss -tlnp 2>/dev/null || netstat -tlnp'

The four outputs resolve almost every case:

Probe OPEN, no rule in nat DOCKER — the port is not a published container port. It is a host daemon, or a --network host container. Look in ss -tlnp.
Probe OPEN, DOCKER-USER counter zero — your rule is not on the path. Appended after the trailing RETURN, or -i names the bridge instead of the external interface.
Probe closed, rule present in nat DOCKER — something upstream is filtering: a cloud security group, a router ACL, or a FORWARD policy of DROP that Docker did not set.
Probe closed, everything correct on the host — check what the container binds. A process listening on 127.0.0.1 inside the container is unreachable through DNAT, and docker ps will still cheerfully print 0.0.0.0:8080->80/tcp.

Why docker ps shows a mapping the container cannot serve

The Ports column is rendered from HostConfig.PortBindings — the argument you passed to -p, stored verbatim in the container’s config JSON at create time. Docker never checks whether anything inside the container is listening, and never re-checks afterwards.

So 0.0.0.0:8080->80/tcp means “a DNAT rule was installed sending 8080 to this container’s port 80”. It does not mean port 80 is open inside the container, that the application started, or that it bound to 0.0.0.0 rather than container loopback.

That is why the last command in the block above runs ss inside the container. LISTEN 0.0.0.0:80 is servable. LISTEN 127.0.0.1:80 is a service that will answer docker exec curl localhost and nothing else, and it produces the single most confusing symptom in Docker networking: a mapping that exists, a firewall that allows, and a connection that resets.

Tracing an unexpected port back to its owner

Read-only / Safewho owns this port— Two paths: DNAT rules for published container ports, host sockets for everything else.

PORT=8080

# Path 1: is it a published container port? Find the target address...
sudo iptables -t nat -S DOCKER | grep -- "--dport $PORT"

# ...then find which container holds that address.
docker ps -q | xargs -r docker inspect \
--format '{{.Name}} {{range .NetworkSettings.Networks}}{{.IPAddress}} {{end}}'

# Path 2: a host socket. Identify the process and, if it is containerised,
# the container it belongs to via its cgroup.
sudo ss -tlnp "sport = :$PORT"
PID=$(sudo ss -tlnpH "sport = :$PORT" | grep -oP 'pid=\K[0-9]+' | head -1)
if [ -n "$PID" ]; then
sudo readlink "/proc/$PID/exe"
tr '\0' ' ' < "/proc/$PID/cmdline"; echo
grep -o 'docker-[0-9a-f]\{12,\}' "/proc/$PID/cgroup" | head -1
fi

For a docker-proxy process, /proc/$PID/cmdline is the whole answer on its own — it carries the protocol, host IP, host port and container address as flags.

Making the audit routine

Read-only / Safeexposure snapshot— Record the expectation on the host, so the next audit compares against a baseline instead of against memory.

STAMP=$(date -u +%Y%m%dT%H%M%SZ)
OUT="/var/log/docker-exposure/$STAMP"
sudo mkdir -p "$OUT"

sudo iptables -t nat -S DOCKER | sudo tee "$OUT/dnat.txt" > /dev/null
sudo iptables -S DOCKER-USER   | sudo tee "$OUT/docker-user.txt" > /dev/null
sudo ss -tlnH                  | sudo tee "$OUT/host-listeners.txt" > /dev/null
docker ps --format '{{.Names}} {{.Image}} {{.Ports}}' \
| sudo tee "$OUT/published.txt" > /dev/null

# Diff against the previous snapshot; an empty diff is the pass condition.
PREV=$(sudo ls -1 /var/log/docker-exposure | sort | tail -2 | head -1)
[ -n "$PREV" ] && sudo diff -ru "/var/log/docker-exposure/$PREV" "$OUT" || true

The diff is what turns this from a report into a check. A new line in dnat.txt that nobody can explain is the finding.

What if the audit finds unexpected exposure?

The usual causes, in the order you will meet them:

A debug container started with -p 8080:80 months ago and never stopped.
A Compose file where a backing service kept ports: from the day someone needed to reach the database from a laptop. expose: was intended.
A --network host container binding a port nobody published, which is why it does not appear in docker ps output at all.
A monitoring exporter on 0.0.0.0:9100 that was fine when the host was on a private VLAN and is not fine now.

Do the containment before the root cause. In order:

Bind the publish to a specific address instead of removing it outright: -p 127.0.0.1:8080:80, or the management interface address. This keeps the service working for whoever legitimately depends on it.
If you cannot recreate the container immediately, insert a DOCKER-USER drop scoped to the external interface as a stopgap.
Then fix the Compose file, so the next docker compose up does not restore the exposure you just removed.

Step 3 is the one that gets skipped, and it is the reason the same finding appears in two consecutive audits.

Sanity check

You can state, for one chosen port, whether it is a published container port or a host socket — and you found out from iptables -t nat -S DOCKER, not from docker ps.
An nc -z from a second machine agrees with your inventory for every port in it.
For at least one port you expected to be closed, the probe confirmed it is closed — a verification that only ever passes is not a verification.
The snapshot from the previous audit exists and the diff is empty or explained.