How to Audit the Ports Exposed by Your Own VPS

A server can accumulate listeners as software is installed, tested, and retired. Some are intentionally public, some belong only on loopback, and some should accept traffic from a small set of private peers. A port audit compares that intended design with the current machine. Keep the audit limited to systems and addresses you own or are explicitly authorized to assess.

Begin with the local listener inventory

On Linux, ss -lnt lists listening TCP sockets and ss -lnu lists UDP sockets. Record the local bind address and port for each relevant service. Process attribution can require appropriate administrative permission; use it to identify the owner rather than guessing from a familiar port number.

A loopback listener is different from one bound to all interfaces. Also inspect container port mappings and service managers because the process that handles traffic may sit behind forwarding rules. Record both the application listener and any published host port. A container dashboard showing a port is not enough to determine its public exposure.

Compare listeners with documented purpose

Create three columns: service owner, intended audience, and observed bind or mapping. For a typical application, the reverse proxy may be public, the upstream application may be local, and the database may be local or restricted to private peers. Ask why every other listener exists. Temporary development servers and old metrics exporters are common items to investigate.

Do not stop an unfamiliar process merely because its name is obscure. Identify its package, service unit, and dependencies first. An orderly audit produces evidence and a specific remediation plan; abruptly removing a service can disrupt monitoring or administration before you understand what it does.

Check policy and reachability separately

Review platform firewall rules, guest policy, guest routing, and any proxy in front of the service. Then perform narrow external connection checks to the documented ports on your own address. Test from an allowed source and, where relevant, a source that should be denied. Local visibility, configured policy, and observed reachability are related but are not interchangeable evidence.

For example, a database may listen on all guest interfaces yet currently be blocked publicly by the platform firewall. Narrowing its bind address can provide a clearer design, but first confirm that legitimate private clients will still work. Conversely, a database bound locally should not need a broad public port allowance left behind from an old deployment.

Close findings and repeat after changes

Assign each finding an owner, a planned correction, and a verification step. Preserve access before modifying administrative listeners. After remediation, repeat the original check and confirm that intended users still succeed. Save a compact baseline and review it after major installs or network changes; the difference from that baseline is often more useful than a long unannotated port list.

The ss reference documents listener inspection. For an example of keeping an application behind a proxy, see our MicroBin guide, and use LayerOne documentation for platform access controls.