Linux Server Security Hardening Guide

Linux Server Security Hardening Guide

Hardening a Linux server means reducing its attack surface and adding layers of defense so that a single mistake does not lead to a full compromise. This guide covers the essential steps, from SSH and firewalls to updates and monitoring, that every production server should have.

Lock Down SSH Access

SSH is the most common entry point attackers probe, so securing it is the highest priority. Edit /etc/ssh/sshd_config and apply these changes:

  • Disable root login: Set PermitRootLogin no and use a normal user with sudo.
  • Use key-based authentication: Set PasswordAuthentication no after adding your SSH public key. This defeats password brute-force entirely.
  • Change the default port (optional): Moving off port 22 reduces automated scan noise, though it is not real security on its own.
  • Limit users: Use AllowUsers to whitelist exactly who can log in.

Restart the service with sudo systemctl restart sshd and test a new connection before closing your current session.

Configure a Firewall

Only expose the ports your services actually need. On Ubuntu and Debian, UFW makes this simple:

  • sudo ufw default deny incoming
  • sudo ufw default allow outgoing
  • sudo ufw allow 22/tcp (or your custom SSH port)
  • sudo ufw allow 443/tcp for HTTPS as needed
  • sudo ufw enable

On RHEL-based systems, use firewalld. The principle is identical: deny by default and open only what is required.

Keep the System Updated

Unpatched software is the leading cause of breaches. Apply updates promptly:

  • Debian/Ubuntu: sudo apt update && sudo apt upgrade
  • RHEL/Fedora: sudo dnf upgrade
  • Enable automatic security updates with unattended-upgrades on Debian-based systems so critical patches land without manual intervention.

Add Intrusion Prevention and Least Privilege

Fail2Ban

Install Fail2Ban to automatically ban IP addresses that show repeated failed logins. It monitors logs and updates firewall rules, blunting brute-force and credential-stuffing attacks against SSH and other services.

Principle of least privilege

  • Give users and services only the permissions they need, no more.
  • Run applications under dedicated, unprivileged accounts rather than root.
  • Audit sudo access and remove accounts that are no longer used.

Enable SELinux or AppArmor

These mandatory access control systems confine processes so that a compromised service cannot freely access the rest of the system. Keep SELinux in enforcing mode on RHEL, or AppArmor enabled on Ubuntu.

Monitor, Log, and Back Up

  • Centralize logs: Forward logs to a remote server so an attacker cannot simply erase them. Review /var/log/auth.log for suspicious logins.
  • Audit with tools: Run auditd for detailed system call logging and consider Lynis for a security audit baseline.
  • Back up regularly: Maintain off-server, encrypted backups and test restoration. Backups are your last line of defense against ransomware.
  • Remove unused software: Every installed package is potential attack surface. Uninstall services you do not use.

Frequently Asked Questions

Is changing the SSH port enough to secure my server?

No. Moving off port 22 reduces automated scan noise but is not real protection by itself. Combine it with key-only authentication, disabled root login, a firewall, and Fail2Ban for meaningful security.

Should I disable password authentication entirely?

Yes, once you have set up SSH key authentication and confirmed it works. Key-based login eliminates password brute-force attacks, which are among the most common threats against exposed servers.

Do I really need SELinux or AppArmor?

They add a valuable layer by confining processes, so a compromised service cannot roam freely. Many administrators disable them out of habit, but keeping them enforcing significantly limits the damage of a breach.

How often should I update a production server?

Apply security updates as soon as practical, ideally automatically for critical patches. Schedule fuller upgrades during maintenance windows, and always have a tested backup before major changes.

Similar Posts