Test published Docker ports beyond the host ufw rule list

An apparently restrictive ufw policy may not describe the path taken by container traffic.

Source facts

Docker documents that published container traffic is diverted through its networking rules before reaching the INPUT and OUTPUT chains used by ufw. Consequently, ufw rules can be effectively bypassed for that path. Docker also warns against disabling its rule management without suitable replacement, because container networking relies on those rules.

Source: Docker documentation — Packet filtering and firewalls.

Applicability

Review Docker-published traffic through the Linux packet-filtering path described in the ufw guidance.

DSE recommendation

DSE recommends inventorying published addresses and ports and testing reachability from the relevant external network. Keep host-service exposure and container-published exposure as separate review items. Use the supported Docker filtering mechanism for the installed backend rather than assuming an ordinary host rule automatically protects every published listener. Do not disable Docker networking controls as a quick hardening step without a complete replacement design. Record the expected allowed and denied paths with the application owner before changing a production port mapping.

Verification

On an approved test host, compare a host listener and a published container port from both allowed and denied source locations. Inspect the effective forwarding path without disrupting unrelated rules. Confirm the final policy is enforced by observed reachability, not solely by the appearance of a ufw status display. Retain the published bind address, protocol and source location with every observation. Have the network owner reconcile an unexpectedly reachable port with the actual forwarding rules before approving the final exposure inventory.

Official reference

Docker documentation — Packet filtering and firewalls. Reviewed October 20, 2026.