Map Open Ports to Services Before Enabling UFW

A firewall rule should reflect a service that is meant to be reachable. Before enabling UFW, inventory listening sockets and map each one to its owner and intended clients. A listening port is not automatically exposed to the internet, and a port that is not listening may still be opened at another network layer.

List sockets and processes

sudo ss -lntup
sudo ufw status numbered

ss shows listening TCP and UDP sockets; elevated access may be needed to see process details for all services. Note the local address: a service bound to loopback is different from one listening on every interface. UFW status shows host rules, not a cloud firewall or provider ACL.

Build a small access table

For each listener, record the service, owner, protocol, expected source network and whether it is needed. Confirm service ports with the application configuration rather than guessing from a familiar number. Check IPv4 and IPv6 separately where both are enabled.

Do not open a port solely because a scanner found it. Find whether the service needs external clients, and whether private access or a proxy is intended. A database port exposed to a public interface should trigger a review of both binding and network policy.

Apply the rules in a safe order

On a remote server, preserve the actual SSH path and a recovery route before enabling restrictive defaults. Apply a small set of required rules, then test from the expected source. Check both the host and upstream firewall layers.

Ubuntu's UFW guide covers status and source-restricted rules. Keep the inventory with the server documentation and revisit it when a service is added or removed.