Check Docker Port Exposure Beyond UFW

A Linux host can appear to allow only SSH and HTTPS in UFW while a container has published a database or administration port. Docker's networking rules and the host firewall need to be reviewed as one system.

Start with the services that should be reachable. For each container, identify whether access should come from the public internet, a trusted network, the host itself or another container. Then compare that requirement with the deployed port mapping and routing.

Understand the firewall interaction

Docker's packet-filtering documentation explains that published container traffic can be diverted before the UFW rules in the usual host INPUT and OUTPUT paths. A reassuring ufw status therefore does not prove the container port is blocked.

Do not respond by disabling Docker's firewall management without a replacement design. The required rules also support container connectivity, and changing them blindly can break the service or create different exposure. Use the documentation for the actual Docker firewall backend and network mode.

Include upstream controls in the review: a cloud firewall, router access list or VPN boundary may affect reachability. Record those controls as separate dependencies and verify them rather than assuming the host's policy is the only relevant layer.

Inspect what is deployed

These read-only commands show running containers and a selected container's port mappings:

docker ps
docker port example-service

Use the actual container name and an appropriately authorised account. Compare the result with the Compose file or deployment definition that created the container. A local configuration file can differ from the running deployment.

Look for bindings on all interfaces, unexpected high-numbered ports, UDP services and IPv6 exposure. Check the Docker network mode as well. A container using host networking requires a different assessment from an ordinary bridge-network container with published ports.

Docker's port-publishing guide documents default binding, explicit host addresses and routing modes. It also records an important historical limitation: releases older than 28.0.0 could expose localhost-published ports to hosts on the same layer-two network. Check the installed version before relying on localhost behaviour.

Remove publishing that the service does not need

If only another container needs to reach a backend, consider the supported internal network arrangement without publishing that backend on the host. Confirm the actual application dependency before changing it.

For a service intended only for a host-local reverse proxy, an illustrative Compose mapping is:

ports:
  - "127.0.0.1:8080:80"

The Compose service reference defines host and container port mapping. This example binds the host side to IPv4 loopback; it is not a complete Compose service or a statement about every possible network route.

Check whether the proxy runs on the host or in another container. A proxy container's own loopback address does not refer to the host's loopback service. Choose the appropriate supported connection rather than broadening the published address simply to make the first test pass.

Keep the previous deployment definition and plan the container recreation or service interruption required by the change. For public access, make the intended interface, port and upstream access policy explicit.

Test from the networks that matter

Validate authorised reachability from a separate machine on each relevant path: public internet, office network, VPN and any adjacent server segment. Use a harmless connection check against your own service. Test both the ports that should work and those that should be refused.

Include IPv6 where it is enabled, and account for direct routing to container or host addresses. A test from inside the host can bypass the route you are trying to assess. Conversely, a blocked public test may merely show that an upstream firewall currently protects a still-exposed internal port.

Verify application authentication as well as network access. A deliberately published admin interface still needs its own access controls. Keep the test results with the address, network location and timestamp so the scope is clear.

Make exposure review part of deployment

Review new ports entries during application changes and compare expected mappings with the running estate. Alert on unexpected publishing where your tooling supports it. Repeat the relevant external checks after changes to Docker, firewall backends, cloud networking or VPN routes.

The final record should name each published service, its intended callers and the evidence that other paths are restricted. That makes an exposed port a deliberate operating decision rather than an accidental side effect of a deployment example.

References

• Docker, Packet filtering and firewalls. Accessed 17 October 2026.
• Docker, Port publishing and mapping. Accessed 17 October 2026.
• Docker, Compose services: ports. Accessed 17 October 2026.