Network Ports and Services: A Linux Developer's Guide

Previously in this course, we covered Network Interfaces Overview: Managing Linux Connectivity, where we learned how to identify our server's physical and virtual hardware. Now that we can see our interfaces, we need to understand what is actually running on them.

In the world of Linux networking, a "port" is a virtual endpoint that allows specific applications to communicate over the network. If your server is a building, the IP address is the street address, and the ports are the individual room numbers where specific departments (services) live.

Understanding Listening Ports

When a process—like a web server or an SSH daemon—is "listening" on a port, it is essentially waiting for incoming data packets addressed to that specific number. If a port is open, anyone who knows your server's IP address can attempt to talk to the service bound to that port.

For security, your goal is to have the minimum number of ports open. Every open port is a potential entry point for traffic.

Identifying Ports with ss

The modern tool for investigating sockets is ss (socket statistics). It is faster and provides more detailed information than the older, deprecated netstat utility.

To see all listening ports, run: ss -tuln

The flags break down as follows:

• -t: Show TCP sockets.
• -u: Show UDP sockets.
• -l: Show only listening sockets (those waiting for connections).
• -n: Do not resolve service names (show port numbers like 80 instead of http).

Mapping Ports to Processes

Knowing a port is open is only half the battle; you need to know what is using it. To see which process owns a specific port, you need to run the command with elevated privileges using sudo.

Bash
sudo ss -tulnp

The added -p flag displays the process ID (PID) and the name of the program listening on that port. You will see output similar to this:

Here, sshd (the SSH service) is listening on port 22, and mysqld (the database) is listening on port 3306, but only on the local loopback address (127.0.0.1), meaning it is not accessible from the outside internet.

Using netstat

While ss is the successor, you will still encounter netstat on legacy systems. It functions similarly:

Bash
sudo netstat -tulnp

If your system says "command not found," you may need to install the net-tools package, though I highly recommend sticking with ss for modern workflows. As we discussed in Linux Network Troubleshooting: Mastering ss, netstat, and tcpdump, mastering these tools is the difference between guessing why a connection failed and knowing exactly which service is failing to bind to a port.

Hands-on Exercise

1. Run sudo ss -tulnp on your server.
2. Identify which process is currently listening on port 22.
3. Determine if any services are listening on addresses other than 0.0.0.0 (like 127.0.0.1).
4. Note down the PIDs of these services. Can you find these PIDs in the top output you learned about in previous lessons?

Common Pitfalls

• Ignoring Loopback: Many services bind to 127.0.0.1 by default for security. Do not confuse these "local-only" services with services exposed to the public internet.
• Forgetting sudo: If you run ss -tulnp without sudo, the Process column will be empty for services owned by other users (like system services). Always use sudo when auditing.
• Confusing TCP and UDP: Remember that ss -t only shows TCP. If your service uses UDP (like some DNS or streaming services), you won't see it unless you include the -u flag.

FAQ

Q: What if I see a port open that I don't recognize? A: Use the PID from the ss output to inspect the process using ps -fp <PID>. This will show you the exact command that started the service.

Q: Is it safe to leave ports open? A: Only if the service is intended to be public. Always favor "least privilege"—if a service doesn't need to be accessed remotely, it should be bound to 127.0.0.1 or blocked by a firewall.

Recap

We've moved from simply checking connectivity to auditing the internal service state of our server. By using ss -tulnp, you can now verify that your web server is listening on the correct ports and confirm which processes are responsible for that traffic. This is a vital step in preparing your machine to act as a secure web server.

Up next: We will apply these skills to open specific ports for our web server and verify they are reachable.