Server hardening in 2026: the minimum viable security for a production Linux box

[Aior]

Most "hardening" docs are 90 % noise​

You can find a 200-line "Linux hardening checklist" with one search. Most of it is dated, low-value, or actively wrong (disabling IPv6, sysctl tweaks for "security" that haven't mattered since 2010). The list below is what actually matters in 2026.

Authentication[/HEADING>

• No password SSH login. Public key only. Set PasswordAuthentication no in /etc/ssh/sshd_config.
• No root SSH login. Set PermitRootLogin no.
• Restrict SSH to a non-default port if you must, but don't rely on it for security — it's hygiene against bot scanning, not a control.
• Use SSH certificates for fleets larger than ~10 servers. Per-server keys don't scale.
• Hardware-backed keys (YubiKey, ed25519-sk) for human users.

Patching[/HEADING>

• Unattended security upgrades enabled (unattended-upgrades on Debian/Ubuntu, dnf-automatic on RHEL-family).
• Reboot policy — kernel upgrades require reboot. Schedule it. Don't skip it for months.
• Track CVE advisories that affect your stack. Subscribe to the relevant security mailing lists.

The unpatched server is the one that will be compromised. Most of the dramatic incidents in the news started with a patch that was 6+ months overdue.

Firewall[/HEADING>

• Default-deny inbound. Open only what's needed.
• nftables (or ufw / firewalld frontends) on the host even if there's a cloud security group. Defence in depth.
• Outbound — restrict where possible. Most servers don't need to make arbitrary outbound connections.
• On-host firewall rules in source control.

Logging and audit[/HEADING>

• Centralise logs. A compromised host can edit local logs. A central log server is your forensic record.
• auditd enabled with rules for important events (privilege escalation, config edits, etc.).
• Log retention policy — at least 90 days for routine logs, 1 year for security-relevant.
• Alert on anomalous patterns: brute-force SSH (fail2ban or similar), sudden process creation rates, unexpected outbound connections.

The principle of least privilege[/HEADING>

• Service accounts per service, no shared accounts.
• Sudo rules narrowed to specific commands per role, not blanket ALL=(ALL) ALL.
• Application processes run as non-root unless they have a specific reason to need root.
• Filesystem permissions enforced — config files world-readable only when they have to be.

Process and file integrity[/HEADING>

• AppArmor (Ubuntu/Debian) or SELinux (RHEL-family) enabled. Don't disable in production.
• Application-specific seccomp / capabilities profiles where applicable (especially for containerised workloads).
• File integrity monitoring (AIDE, Tripwire, or equivalent) on critical paths.

Disk encryption[/HEADING>

• LUKS for any host that might walk away — laptops, branch-office servers, anything in a non-controlled physical environment.
• Cloud disk encryption is on by default at most providers; verify, don't assume.
• Backup encryption — separate from disk encryption.

Containers — adjust the model[/HEADING>
For containerised workloads, host hardening is necessary but not sufficient. Add:

• Read-only filesystem in containers where possible
• Drop unnecessary capabilities
• No privileged containers unless the use case requires it (and document why)
• Image scanning at build + at registry pull
• Runtime security tooling (Falco, Tetragon, others) for behaviour-based detection

Secrets management[/HEADING>

• No secrets in source code, environment variables in repos, or /etc config files in plaintext
• A secrets manager (Vault, AWS Secrets Manager, GCP Secret Manager) is the source of truth
• Per-service credentials, rotated on a schedule
• Audit log on secret access

Backups[/HEADING>
Already covered in the backup article — but security context: backups must be encrypted, stored off-host, and immutable for a retention period (so ransomware can't encrypt them too).

The honest summary[/HEADING>
Most servers we audit have most of this list partially done. The two consistent gaps:

• Audit logging that goes nowhere — running auditd but not centralising the logs
• Patch cadence — unattended-upgrades configured but not actually rebooting

Fix those two on every server, and you're meaningfully ahead of typical posture.

One pattern we'd warn about[/HEADING>
Running a "hardening script" downloaded from the internet against a production server. Read what it does, accept the changes, version-control the result. Mystery hardening leaves you with a server you don't understand.

One pattern that always pays off[/HEADING>
A documented baseline: the configuration every production server has, validated by an automated check. Drift from baseline is the alert. The baseline lives in version control and changes via PR review, not by running ad-hoc commands.

What's your baseline? And — for the compliance folks — has CIS Benchmark adoption been worth the operational overhead in your environment?​

​​​​​​​​​​​​