MYTHOSAI

Linux security / PRACTICAL GUIDE

Find listening ports on Linux with ss

Identify protocol, bind address and owning process using the built-in socket inspection tool.

Before you start

Linux with iproute2/ss; sudo for process details where necessary.

Start with listeners, not every connection

A listening socket waits for incoming traffic. Established connections are different. To review a server's inbound surface, begin with listeners and their bind addresses:

bash
sudo ss -lntup

The switches request listening sockets, numeric addresses, TCP, UDP and process information. UDP is connectionless, so its state labels differ from a TCP LISTEN entry.

Read each row

  1. Identify the protocol and local port.
  2. Read the local address. 127.0.0.1 is IPv4 loopback; 0.0.0.0 indicates all IPv4 interfaces. An IPv6 wildcard needs interpretation alongside the application's dual-stack behaviour.
  3. Check the owning process where available.
  4. Match it to an expected service and an owner. Do not assume the usual port name proves which software is actually running.

A web application bound to loopback can be suitable behind a local tunnel. A collector intended for other LAN computers needs a reachable LAN path. Changing everything to loopback can break that role.

Narrow the question

For a particular TCP port:

bash
sudo ss -lntp 'sport = :443'

For established TCP sessions:

bash
ss -nt state established

These queries are read-only. They do not open, close or scan ports on other computers.

Verify reachability separately

If a required service is absent, inspect its unit status, configuration and logs. If it is listening but a client cannot reach it, check the bind address, routing, local firewall and upstream firewall. Test from the intended client using the real protocol or a connection check.

Do not label a listener internet-exposed solely from this output. A router, cloud security rule, VPN or tunnel can change external reachability. Conversely, a local firewall rule is not the whole exposure model for container networking.

Common mistakes

Using netstat examples on a system without net-tools produces a missing-command error, not evidence of a broken network. Process details can be absent without sufficient privilege. A port can change ownership after a restart, so capture timestamps when documenting it.

Make the output useful

Keep an inventory of service, bind address, port, intended clients and authentication. Investigate unexplained entries with that inventory instead of killing processes by number. This converts a socket listing into a repeatable exposure check.

Official references

Consult the current vendor documentation if your version or screen differs.

Documentation-based draft. Commands have not all been executed against the named products in a lab. Validate configuration examples against your installed version before changing a working system.