Checking Listening Ports for Security Audit

Introduction

In server security, the "attack surface" is the total number of points where an unauthorized user can try to enter or extract data. A key part of reducing this attack surface is managing network ports.

Every open port is a potential entry point for an attacker. If a service is listening on a port, it is ready to receive data. If that service is vulnerable or should not be publicly accessible, your system is at risk.

A listening port does not automatically mean danger, but it does mean exposure. Security auditing starts by knowing which services are reachable and whether that exposure is intentional.

This is why port auditing is part of basic hardening. Good security is not only about patching software, but also about reducing unnecessary exposure.

In this lab, you will perform a basic security audit. You will:

List all listening TCP ports using the ss command.
Identify suspicious or non-standard ports.
Investigate the process and user responsible for opening a port.

List Listening TCP Ports

Your first task is to get a complete picture of the network state. We will use the ss (Socket Statistics) command, a modern and faster replacement for the older netstat tool.

To perform an audit, we want to focus on Listening TCP Ports and the Processes that opened them.

That process information is what turns a raw socket list into something actionable. A port number alone tells you little, but a port linked to a specific process and user gives you something you can evaluate and manage.

Run the following command:

sudo ss -lntp

Understanding the flags:

-l (listening): Show only sockets that are waiting for connections.
-n (numeric): Show IP addresses and port numbers instead of hostnames (faster and clearer).
-t (tcp): Show only TCP sockets.
-p (processes): Show the process name and PID (Process ID) using the socket.
- Note: sudo is required to see process information for services owned by other users.

You should see output similar to this:

State    Recv-Q   Send-Q     Local Address:Port      Peer Address:Port   Process
LISTEN   0        4096       127.0.0.1:8080          0.0.0.0:*           users:(("node",pid=123,fd=18))
LISTEN   0        5          0.0.0.0:9999            0.0.0.0:*           users:(("python3",pid=456,fd=3))
LISTEN   0        128        0.0.0.0:22              0.0.0.0:*           users:(("sshd",pid=789,fd=3))

The Local Address:Port column shows where the service is listening. The Process column identifies which program is responsible.

Another important clue is whether the address is 127.0.0.1 or 0.0.0.0. Localhost-only services are exposed only on the machine itself, while 0.0.0.0 usually means the service is listening on all network interfaces.

Identify Suspicious Ports

Now, analyze the output to identify anything unusual.

Standard services typically run on "Well-Known Ports" (0-1023). For example:

Port 22: SSH (Secure Shell)
Port 80: HTTP (Web Server)
Port 443: HTTPS (Secure Web Server)

In a security audit, look for non-standard ports or services you do not recognize.

The goal is not to panic at every unfamiliar port, but to verify purpose. A service may be legitimate, temporary, or accidental; auditing is the process of turning unknown exposure into known exposure.

Review your output from Step 1. You should see a service listening on port 9999. This is not a standard system port and warrants further investigation.

Isolate this entry using grep:

sudo ss -lntp | grep 9999

Example Output:

LISTEN 0      5            0.0.0.0:9999       0.0.0.0:*    users:(("python3",pid=289,fd=3))

This confirms a process is active on port 9999. Next, we will find out exactly what it is.

Investigate Process Ownership

Knowing a port is open is not enough. You must know who is running the service. A suspicious process running as root is a critical emergency, whereas one running as a limited user might be less severe (though still dangerous).

Find the PID: Look at the output from the previous command. In the users: section, locate the pid=... value.

Example: users:(("python3",pid=289,fd=3)) -> The PID is 289.
Note: Your PID will be different.

Inspect the Process: Use the ps command to list details for this specific PID. Replace <PID> with the actual number you found.

ps -f -p <PID>

Example (if PID is 289):

ps -f -p 289

Analyze the Output:

UID          PID    PPID  C STIME TTY          TIME CMD
labex        289    189   0 10:00 pts/0    00:00:00 python3 -m http.server 9999

UID: The user running the process (e.g., labex).
CMD: The exact command that started process (e.g., python3 -m http.server 9999).

This tells you that the user labex started a Python HTTP server clearly intended to listen on port 9999. In a real scenario, if you did not authorize this, you would terminate the process immediately.

This final step is attribution: not just "what port is open," but "which command, launched by which user, created that network exposure." That is what makes the audit useful for incident response and hardening.

Summary

In this lab, you successfully performed a security audit of the system's listening ports.

Key Takeaways:

Visibility: Use sudo ss -lntp to see exactly what services are listening for connections.
Identification: Recognize standard ports and flag non-standard ones (like 9999) for investigation.
Attribution: Use ps -f -p <PID> to determine which user and command are responsible for a suspicious socket.

Regular auditing helps you spot unauthorized services (like backdoors or miscellaneous web servers) and remove them before they can be exploited.