Linux Server Hardening That Actually Matters

Hardening guides run to hundreds of items. About eight of them account for nearly all the real-world benefit. Here they are.

8 April 2026 3 min read

Comprehensive hardening benchmarks are valuable and enormous. If you are running a handful of servers, the following short list delivers most of the protection for a fraction of the effort.

1. Key-only SSH

The single highest-value change. In sshd_config:

PasswordAuthentication no — brute force becomes irrelevant.
PermitRootLogin no — the account every scanner tries first is unavailable.
PubkeyAuthentication yes.
Optionally AllowUsers to restrict who can connect at all.

Verify a new session works before closing your existing one. Every lockout story starts with skipping that.

2. Firewall at both levels

Use the provider’s cloud firewall as the outer layer — it filters before packets reach the machine — and ufw or firewalld on the host as the inner one. Default deny inbound, allow only what the service needs.

Cover IPv6 explicitly. Most providers assign an IPv6 address by default, and rules written only for IPv4 leave it open.

3. Automatic security updates

Unpatched software is the most common route into a server that was otherwise configured correctly. On Debian and Ubuntu, unattended-upgrades with security updates enabled. On RHEL family, dnf-automatic.

Automatic security patching with occasional reboots beats a manual process that slips. Schedule the reboot window rather than avoiding it.

4. Do not run as root

Create a normal user with sudo for administration.
Run each service as its own unprivileged user.
Never run an application server as root “for now”.
Use systemd hardening directives — NoNewPrivileges, ProtectSystem=strict, PrivateTmp — which cost one line each.

5. Reduce what is listening

Run ss -tulpn and account for every listening socket. Anything you cannot explain should be disabled.

Bind services that do not need public access to 127.0.0.1 or a private interface. A database listening on 0.0.0.0 behind a firewall is one rule change away from being exposed; a database listening on localhost is not.

6. Backups you have restored

Ransomware and mistakes both end at the same question: can you restore? Enable provider backups, keep at least one copy outside the account, and restore one to a fresh instance at least once so you know the procedure works.

A backup that has never been restored is a hypothesis.

7. Know when something changes

Signal	Tool	Why
Failed logins	fail2ban, journald	Noise level and targeting
File integrity	AIDE or Tripwire	Detects modified binaries
Disk filling	Provider monitoring or node_exporter	The most common self-inflicted outage
Unexpected processes	auditd or process monitoring	Crypto-mining is the usual finding
Outbound traffic spikes	Provider metrics	Exfiltration and abuse both show here

8. Encrypt what travels and what rests

TLS on every public endpoint, with automatic renewal. Certbot or a reverse proxy that handles it.
TLS between services where they cross a network boundary, including to managed databases.
Encrypted volumes where the provider offers it at no cost, which most now do.
Encrypted backups, particularly anything leaving the provider.

What to skip unless you have a reason

Changing the SSH port reduces log noise, not risk. Disabling ICMP breaks diagnostics for no security gain. SELinux and AppArmor are genuinely valuable but need real time to configure without breaking things — do them deliberately, not as an afterthought.

Common questions

Do I need fail2ban with key-only SSH?

Not for protection, since password attempts cannot succeed. It keeps logs readable and reduces wasted connections, which is a reasonable reason on its own.

Is a host firewall redundant behind a cloud firewall?

It is defence in depth. If a cloud rule is widened by mistake, the host firewall still holds. The cost is a few minutes.

How often should I patch?

Security updates automatically, as soon as they are available. Feature and kernel updates on a schedule with a reboot window you control.

Should I use a bastion host?

Once you have more than a few servers, yes. One hardened entry point is easier to monitor and lock down than SSH exposed on every machine.

Where to go next

Start with the first hour on a new cloud server, then set up backups that survive a bad day.

DigitalOcean Hetzner Linode