Linux Hardening: Best Practices to Maximize Server Security

The core philosophy of hardening revolves around the "Attack Surface"—the sum of all potential vulnerabilities and entry points an attacker could exploit. Every running service, open network port, installed application, and user account adds to this surface. The primary goal of Linux hardening is to systematically shrink this surface to the absolute minimum required for the server to function.

If a server's sole purpose is to run a web application, it does not need an FTP server, a mail server, or graphic interface components installed. By removing these, you eliminate the possibility of an attacker exploiting vulnerabilities within them.

The front door to any Linux server is typically SSH (Secure Shell). Securing how users access the system is paramount.

Securing SSH

The default SSH configuration is often too permissive. Modifying /etc/ssh/sshd_config is a mandatory hardening step:

• Disable Root Login: Never allow the root user to log in directly via SSH. Set PermitRootLogin no. Administrators should log in as a standard user and use sudo to escalate privileges. This forces an attacker to guess both a valid username and the password/key.
• Disable Password Authentication: Passwords can be brute-forced. Switch entirely to cryptographic keys for authentication by setting PasswordAuthentication no.
• Change Default Port: While changing the SSH port from 22 to a non-standard port (e.g., 2222) won't stop a determined attacker, it drastically reduces the noise from automated script-kiddie scanners.
• Implement Fail2Ban: Install an Intrusion Prevention System like Fail2Ban. It monitors log files for repeated failed login attempts and automatically updates firewall rules to block the offending IP address.

User Access and Least Privilege

• The Principle of Least Privilege: Users and applications should only have the minimum permissions necessary to perform their tasks. Do not give a web developer full root access if they only need to deploy code to a specific directory.
• Strict sudo Configuration: Configure the /etc/sudoers file carefully. Instead of granting blanket root access, specify exactly which commands a user is allowed to run with elevated privileges.
• Lock Inactive Accounts: Regularly audit user accounts. If an employee leaves or a service is deprecated, immediately lock or delete the associated account.

Controlling the traffic that enters and exits your server is critical for containing threats.

Configuring the Firewall

Every hardened Linux server must have an active firewall dropping unrequested traffic.

• UFW or iptables/nftables: Use Uncomplicated Firewall (UFW) on Debian/Ubuntu systems or firewalld on RHEL/CentOS systems to easily manage rules.
• Default Deny Policy: The foundational rule of any firewall should be to drop all incoming traffic by default. You then explicitly allow only the necessary ports. For a web server, you would allow inbound traffic only on ports 80 (HTTP), 443 (HTTPS), and your custom SSH port.
• Egress Filtering: Often overlooked, egress filtering restricts outbound traffic. If your web server only needs to communicate with an internal database and serve external web traffic, it should not be allowed to initiate outbound connections to arbitrary IP addresses on the internet. This prevents compromised servers from establishing Command and Control (C2) connections or participating in DDoS attacks.

Disabling IPv6

If your network infrastructure does not actively use IPv6, disable it on the server. Keeping it enabled creates a secondary, often unmonitored network stack that attackers can exploit to bypass IPv4 firewall rules.

A hardened server runs the bare minimum software required.

• Remove Unnecessary Packages: Do not install "Desktop" or GUI environments on servers. Use package managers to uninstall any service you are not explicitly using (e.g., apt purge apache2 if you are using Nginx).
• Disable Unused Network Services: Ensure that services like Telnet, FTP, or unencrypted POP3 are disabled and removed. Use systemctl disable <service> and systemctl stop <service> to ensure they do not run on boot.
• Regular Patching and Updates: The most critical hardening step is maintaining a rigorous patching schedule. Enable automated security updates (e.g., using unattended-upgrades on Ubuntu) to ensure critical vulnerabilities are patched immediately without requiring manual intervention.

Protecting the underlying file system and kernel prevents attackers from establishing deep persistence or escalating privileges if they manage to compromise an application.

File Permissions and Mount Options

• Restrict File Permissions: Regularly audit file permissions, especially for critical system files in /etc. Ensure sensitive files are not world-readable or world-writable.
• Find and Remove SUID/SGID: Search for unnecessary files with SUID or SGID bits set. These files execute with the privileges of the file owner (often root) and are prime targets for privilege escalation exploits.
• Secure Mount Points: Edit /etc/fstab to mount shared memory space (/run/shm or /dev/shm) and temporary directories (/tmp, /var/tmp) with the noexec, nosuid, and nodev options. This prevents attackers from downloading and executing malicious binaries in these commonly writable locations.

Mandatory Access Control (MAC)

Standard Linux Discretionary Access Control (DAC) relies on user and group permissions. Mandatory Access Control systems, such as AppArmor or SELinux, provide a much stronger layer of defense.

• AppArmor / SELinux: These systems confine applications to specific profiles. Even if a web server running as the www-data user is compromised by a zero-day exploit, a strict SELinux profile will prevent the attacker from accessing files or executing commands outside of the web server's explicit operational boundaries. Never disable SELinux or AppArmor; instead, learn to configure their profiles correctly.

Hardening is not complete without visibility. You must be able to detect if your defenses are being tested or breached.

• Centralized Logging: Do not rely solely on local logs stored in /var/log. If an attacker gains root access, their first action will be to wipe the logs to cover their tracks. Configure rsyslog or a dedicated agent to ship logs continuously to an external, secure logging server or SIEM.
• Auditd Configuration: Install and configure the Linux Auditing System (auditd). Unlike standard system logs, auditd operates at the kernel level. You can configure it to monitor critical files (like /etc/shadow or /etc/passwd) and trigger immediate alerts if they are read or modified by any user, including root.