Linux Hardening: 15-Point Checklist for Production (2026)

Fifteen minutes. That’s all it takes to secure a newly installed Linux server, if you know what to do. In most cases, nothing is done. I’ve seen it happen dozens of times across different environments, and each time the risk is the same: an exposed server means a potential entry point for attackers. A Linux server is a robust machine, but default configurations, designed for maximum compatibility and ease of use, are almost never suitable for a production environment. Ignoring hardening means leaving the door open, turning a valuable asset into a critical vulnerability. According to the 2025 Verizon Data Breach Investigations Report (DBIR), 75% of attacks exploit known vulnerabilities for which a patch already existed. This guide provides an essential 15-point linux server hardening checklist production to fortify your server before it goes live.

Prerequisites / Test Environment

To test and apply this checklist, you will need a Linux server (preferably Ubuntu Server 24.04 LTS or CentOS Stream 9) with SSH access. All commands have been tested in these environments. Ensure you have a non-root user with sudo privileges configured and a working network connection.

Linux Server Hardening: Access Control

Access control is the first and most critical line of defense. Every user and every connection must be authenticated and authorized with the minimum necessary privilege.

1. Disable Direct Root SSH Login

Direct root access via SSH is one of the riskiest practices. If credentials are compromised, an attacker would immediately gain full system control. It’s best practice to create a standard user with sudo privileges and use that for access. To disable root access:

Edit the /etc/ssh/sshd_config file and set:

PermitRootLogin no

After modification, restart the SSH service:

systemctl restart sshd

2. Implement Public Key Authentication for SSH

Passwords, no matter how complex, are vulnerable to brute-force and dictionary attacks. Public key authentication offers a significantly higher level of security. Generate a public/private key pair on your local machine and copy the public key to the server. In the /etc/ssh/sshd_config file, ensure that:

PasswordAuthentication no
PubkeyAuthentication yes

and restart SSH.

3. Enable Multi-Factor Authentication (MFA)

For an additional layer of security, especially for users with sudo privileges, MFA is indispensable. Tools like libpam-google-authenticator can be easily integrated with SSH to require an OTP code. Microsoft (2023) reports that MFA blocks 99% of credential stuffing attacks.

Linux Server Hardening: Network

Controlling inbound and outbound network traffic is fundamental to limiting the attack surface.

4. Configure a Firewall (UFW or FirewallD)

A firewall is the first line of defense for your network. It blocks all inbound traffic not explicitly allowed. On Ubuntu, UFW (Uncomplicated Firewall) is easy to configure:

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow ssh
sudo ufw allow http
sudo ufw allow https
sudo ufw enable

On CentOS/RHEL, FirewallD is used. The goal is to expose only strictly necessary services. To check listening ports:

ss -tlnp

5. Disable Unnecessary Network Services

Every service listening on a network port represents a potential vulnerability. Remove or disable all services that are not strictly essential for the server’s function. Use systemctl list-unit-files --state=enabled to see services enabled at boot and disable superfluous ones with sudo systemctl disable .

6. Protect Against SYN Flood Attacks with sysctl

SYN Flood attacks can saturate server resources. You can mitigate this risk by configuring kernel parameters via sysctl. Add or modify these lines in /etc/sysctl.conf:

net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_max_syn_backlog = 2048
net.ipv4.tcp_synack_retries = 2

Apply changes with sudo sysctl -p.

Linux Server Hardening: System Configuration

Operating system configuration is crucial for overall resilience.

7. Keep the System and Kernel Updated

Security patches are your best defense against known vulnerabilities. Configure an automatic update system for security packages. On Debian/Ubuntu, you can use unattended-upgrades:

sudo apt install unattended-upgrades
sudo dpkg-reconfigure --priority=low unattended-upgrades

8. Remove Unnecessary Software and Packages

Every installed software adds complexity and potential attack vectors. Uninstall all non-essential packages. A minimal server is a more secure server.

9. Configure Kernel Settings with sysctl

Beyond syncookies, other sysctl parameters can enhance security. For example, prevent IP routing if the server is not a router:

net.ipv4.ip_forward = 0
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.default.send_redirects = 0

And to protect against IP spoofing:

net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.rp_filter = 1

Apply with sudo sysctl -p.

Linux Server Hardening: Monitoring and Auditing

It’s not enough to configure security; you must also actively monitor it.

10. Implement auditd for Security Event Logging

auditd provides detailed logs of system activities, essential for intrusion detection and forensic analysis. Configure it to track access to critical files, security configuration changes, and failed login attempts. For example, to monitor changes to /etc/passwd:

sudo auditctl -w /etc/passwd -p wa -k passwd_changes
sudo systemctl enable --now auditd

11. Install and Configure Fail2Ban

Fail2Ban analyzes system logs (like SSH logs) and automatically blocks IP addresses exhibiting suspicious behavior (e.g., failed login attempts). It’s an excellent tool for mitigating brute-force attacks. You can install and configure it for SSH:

sudo apt install fail2ban
# Create a local configuration file for SSH
sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
# Modify jail.local to enable sshd

12. Monitor Failed Login Attempts

Regularly check for failed login attempts. This can indicate ongoing attacks. You can use journalctl or grep on authentication logs. For instance, for the last 20 failed SSH attempts:

grep 'Failed password' /var/log/auth.log | tail -20

Linux Server Hardening: Backup and Final Verification

Security is not complete without a recovery plan and continuous verification.

13. Configure Regular and Verified Backups

Even the most fortified server can experience a disaster. Implement a 3-2-1 backup strategy (3 copies, 2 different media, 1 offsite) and regularly test restoration. An untested backup is a non-existent backup.

14. Verify System File Integrity (AIDE/Tripwire)

Tools like AIDE (Advanced Intrusion Detection Environment) or Tripwire monitor changes to critical system files. An unexpected change could indicate an intrusion. Install AIDE and initialize the database:

sudo apt install aide
sudo aide --init
sudo mv /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gz

Then, schedule regular checks with sudo aide --check.

15. Check Users with UID 0 (Root Only)

Ensure that only the root user has UID 0. Any other user with UID 0 is a high potential risk. You can verify this with:

awk -F: '($3==0){print}' /etc/passwd

How to Automate the Checklist with Ansible

Manually applying these 15 points can be laborious and error-prone, especially across an extensive server fleet. Automation with Ansible is the ideal solution. I’ve created Ansible playbooks that automatically apply these configurations, ensuring consistency and reducing hardening time from hours to minutes. This not only speeds up server rollout but also ensures every machine adheres to corporate security standards. For example, an Ansible task to disable PermitRootLogin:

- name: Disable root SSH access
  lineinfile:
    path: /etc/ssh/sshd_config
    regexp: '^PermitRootLogin'
    line: 'PermitRootLogin no'
  notify: restart sshd

Common Errors and Troubleshooting

One of the most common errors is accidentally locking yourself out via SSH. Always ensure you have a backup active SSH session or virtual console access before applying significant changes to /etc/ssh/sshd_config or firewall rules. Another mistake is not testing backups: an unverified backup offers no guarantee. Finally, do not underestimate the importance of monitoring logs: a secure but unmonitored system is a vulnerable system awaiting a problem.

Conclusions with Operational Takeaways

Hardening a Linux server is not an option, but a necessity. These 15 points represent a solid foundation for protecting your production systems. Remember: security is a continuous process, not an event. Automate where possible, monitor constantly, and stay updated on the latest threats. A well-protected server is a server that allows you to sleep more soundly.

Read also: SSH Hardening Linux: Complete Guide 2026 (10 Critical Settings)

Read also: Passwordless SSH Linux: Configure Keys in 5 Minutes (2026)

Read also: SIEM: Wazuh vs Splunk en 2026 (Análisis Completo)

Updated: May 2026

For further details on sysctl parameters and their security implications, refer to the official Linux kernel documentation: https://www.kernel.org/doc/Documentation/sysctl/