Security Auditing Basics: Hardening Linux Servers

Previously in this course, we learned how to manage system services with systemd. In this lesson, we shift our focus from configuration to verification: auditing your server to ensure that only intended services are running and listening for connections.

Security auditing is the practice of systematically evaluating your system to identify vulnerabilities. On a Linux server, this starts by answering two fundamental questions: "Who is listening on the network?" and "What are these processes actually doing?"

Identifying Open Network Sockets

Every service that communicates over the network "listens" on a specific port. If you have an insecure service exposed to the public internet, it becomes a target. We use the ss (socket statistics) command to audit these listeners.

To view all listening TCP ports, run:

Bash
sudo ss -tuln

• -t: Display TCP sockets.
• -u: Display UDP sockets.
• -l: Display listening sockets (those waiting for connections).
• -n: Show numerical port numbers (don't resolve service names, which is faster and safer).

Why this matters: If you see a port like 22 (SSH) or 80/443 (HTTP) open, that is expected for a web server. However, if you see an unknown service or a database port (like 3306 for MySQL) listening on 0.0.0.0 (all interfaces) instead of 127.0.0.1 (local only), you have found a potential security hole.

Mapping Processes to Sockets

Once you identify an open port, you need to know which process owns it. A common security risk is an unauthorized binary masquerading as a legitimate service.

Add the -p flag to your ss command to see the Process ID (PID) associated with each socket:

Bash
sudo ss -tulnp

The output will show a column labeled users. You might see something like: users:(("nginx",pid=1234,fd=6))

This tells you exactly which binary is responsible for that open port. If you see a suspicious process name or a PID that doesn't align with your known services, you should investigate it further using the process management techniques we covered in managing process lifecycle.

Hardening Through Process Inspection

Auditing isn't just about network ports; it’s about verifying the integrity of running tasks. Use ps to inspect the command-line arguments of suspicious processes:

Bash
ps auxww | grep [process_name]

The ww flag is critical here—it prevents the terminal from truncating long command lines, ensuring you see the full path and any sensitive arguments passed to the process (like database credentials or API keys, which should never be passed as command-line arguments).

Hands-on Exercise: The Security Audit

For our running project, let's verify our web server configuration.

1. Run sudo ss -tulnp | grep nginx to confirm that Nginx is only listening on ports 80 and 443.
2. If you see Nginx listening on any other ports, check your config files in /etc/nginx/sites-enabled/.
3. Use ps aux | grep nginx to verify the master process is owned by root and worker processes are owned by the expected non-privileged user (usually www-data or nginx).

Common Pitfalls

• Ignoring Localhost: Many developers assume that if a port is bound to 127.0.0.1, it is "safe." While better than 0.0.0.0, any local user on the system can still connect to that service. Always use proper file permissions to restrict access.
• Relying on Outdated Tools: You may see older guides recommending netstat. While netstat still works, it is deprecated in many modern distributions. Stick with ss for faster, more accurate results.
• Over-Privileged Processes: Running web servers as root is a major security risk. If a vulnerability is exploited in your web application, the attacker gains root-level access to your entire system.

FAQ

Q: What if I find a socket with no PID? A: This usually happens if the process has recently closed or if you are running the command without sudo. Always use sudo when auditing to ensure you have permission to view all process details.

Q: How do I know if a port should be open? A: Document your architecture. Use tools like AIDE to maintain a baseline of your system's state so you can easily spot deviations.

Recap

Security auditing is a continuous process of verification. By using ss -tulnp, you map network exposure to specific processes, and by using ps auxww, you inspect the behavior of those processes. These small, disciplined checks form the backbone of hardening your server.

Up next: We will discuss User Account Management to ensure that only authorized users have access to your hardened environment.