sockets

Overview

To see what a Linux host is actually doing on the network — which ports it is listening on and what connections are open — you inspect its sockets. This is one of the most valuable enumeration and investigation skills. This lesson covers sockets and how to view them.

Learning objectives

• Define a socket in the networking sense.
• Use ss to view listening ports and connections.
• Interpret socket states for investigation.

Core concept

A socket is an endpoint of a network connection — an IP address and port bound to a process. Two situations matter:

• Listening sockets — a service waiting for incoming connections on a port (e.g. a web server listening on 443).
• Established connections — active connections between a local and remote socket.

The modern tool is ss (socket statistics), replacing the older netstat. A common invocation is ss -tulpn (TCP/UDP listening sockets with process and numeric ports).

How it works

ss -tulpn lists which ports are listening and, with sufficient privilege, which process owns each — directly answering "what services are exposed on this host?" ss -tan shows TCP connections and their states (LISTEN, ESTABLISHED, TIME_WAIT, etc.). Mapping a listening port to its owning process links network exposure to a specific program, which is exactly what you need to understand or secure a host's footprint.

Practical example

$ ss -tulpn
Netid State  Local Address:Port  Process
tcp   LISTEN 0.0.0.0:22          users:(("sshd",pid=900))
tcp   LISTEN 127.0.0.1:5432      users:(("postgres",pid=1200))

SSH (sshd) listens on 0.0.0.0:22 — reachable from any interface — while PostgreSQL listens on 127.0.0.1:5432 — only locally. That distinction (all interfaces vs loopback-only) is a crucial security detail: the database is not exposed to the network, but SSH is.

Cybersecurity relevance

Socket inspection is central to both hardening and investigation. Listing listening ports reveals a host's exposed attack surface; spotting a service bound to 0.0.0.0 (all interfaces) that should be local-only is a common finding. During incident response, an unexpected listening port or a suspicious established connection (e.g. to an unknown external IP) can indicate a backdoor or active compromise. Tying a socket to its process (-p) identifies exactly what to investigate. This is the local counterpart to the port-scanning concepts from the networking path.

Common mistakes

• Using deprecated netstat instead of ss (though netstat may still be present).
• Ignoring the bind address — 0.0.0.0 (all interfaces) versus 127.0.0.1 (local-only) is a key exposure difference.
• Overlooking established connections to unexpected remote hosts during investigation.

Key takeaways

• A socket is a network endpoint (IP:port bound to a process); listening sockets await connections, established sockets are active connections.
• Use ss -tulpn to see listening ports and owning processes, and ss -tan for connection states (modern replacement for netstat).
• Socket inspection reveals exposed attack surface and suspicious connections — a bind to 0.0.0.0 vs 127.0.0.1 is a critical exposure distinction, and unexpected ports/connections signal compromise.

Check your understanding

• What is the security difference between a service listening on 0.0.0.0 versus 127.0.0.1?
• Which command lists listening ports along with the processes that own them, and why is that mapping useful?