Hardening Linux servers: where to actually start
A practical guide to hardening Linux servers — no copying hundred-item checklists, with an emphasis on the highest-impact actions.
Hardening Linux is often associated with long checklists copied from the internet and ticked off without understanding. That approach gives a false sense of security. It’s better to focus on a limited number of actions that genuinely reduce the attack surface. Below is the order we use in practice.
Start with minimisation
The simplest security principle: what isn’t there can’t be attacked. A server should have only the packages necessary for its role installed. Every extra service, compiler or tool is a potential attack vector and another component to keep updated.
Check which services are listening on ports (ss -tulpn) and disable everything you don’t need. A database server should not be running a web server “just in case”.
SSH access — the most common target
SSH is the gateway to the server and the first target of automated attacks. Three changes have the biggest impact here:
- Disable password login, enforce keys. Public-key authentication eliminates dictionary attacks. In
sshd_config:PasswordAuthentication no. - Block direct root login.
PermitRootLogin no. Administrators log in to their own account and elevate viasudo, which provides accountability. - Restrict access. Where possible, limit SSH to trusted addresses or hide it behind a VPN. Mechanisms like fail2ban further limit brute-force attempts.
Updates and automating them
An unpatched system is the most common cause of breaches. Most successful attacks exploit known vulnerabilities for which a patch existed for months. Configure automatic installation of security updates (e.g. unattended-upgrades on Debian/Ubuntu) and set a process for updates that require a reboot.
Automation is key here — manually patching dozens of servers will always stall somewhere.
The principle of least privilege
Accounts and processes should run with the lowest possible privileges. Run services under dedicated system accounts, never as root unless absolutely necessary. Grant sudo rights by name and precisely, instead of adding users en masse to the admin group.
It’s also worth reviewing files with the SUID bit — a classic privilege-escalation path that an attacker checks first.
A firewall with default deny
The firewall should work on the principle of “deny by default, allow explicitly”. Only the ports of genuinely needed services should be open. Whether you use nftables, ufw or cloud security groups, the rule is the same: incoming traffic denied by default, exceptions deliberate and documented.
Logging and change detection
Hardening is not only about closing doors but also about being able to notice that someone tried to force them. Centralise logs off the server (an attacker clears local logs after a breach), monitor logins and sudo operations, and control the integrity of critical files with tools like AIDE. Kernel auditing (auditd) lets you record security-relevant events.
Build on standards, but with understanding
Rather than inventing your own list, it’s worth using the CIS Benchmarks — detailed, proven guidelines for specific distributions. The key phrase is “with understanding”: each recommendation should be assessed in the context of the server’s role, not applied blindly, as some settings can disrupt applications.
Summary
Effective Linux hardening is not a thousand small settings, but a handful of high-impact decisions: minimising services, securing SSH, automatic updates, least privilege, a restrictive firewall and centralised logging. If you’d like us to review your servers’ configuration against the CIS Benchmarks, book a hardening engagement.
