Host hardening

The baseline work every other guide on this site assumes you have done. Pick the right OS-family baseline for your stack, layer the SSH hardening on top, and the firewall / AppArmor / SELinux / auditd controls turn a fresh image into something defensible. Read in order if you are starting from a provider snapshot; jump to the piece relevant to your distro if you are auditing an existing host. Pairs with launch-readiness for the pre-go-live verification layer.

After this series: your host runs a hardened OS baseline (Ubuntu 24.04 or RHEL 9), SSH locked to key-auth only with modern algorithms, a default-deny firewall, an enforcing MAC layer (AppArmor or SELinux), and auditd forwarding logs off the box.

Hardened RHEL / AlmaLinux VPS Baseline

Tested on: AlmaLinux 9.4 (kernel 5.14.x). The same steps apply to Rocky Linux 9 and Red Hat Enterprise Linux 9.x — all three share the same package set, service names, and SELinux profile. Why this matters A fresh RHEL-family cloud image differs from Ubuntu’s defaults in two important ways: SELinux is in enforcing mode by default — which is good, until an operator hits a denied syscall, panics, and runs setenforce 0. The baseline below assumes you’ll keep SELinux on and learn to tune it. The default firewall is firewalld, not ufw — same idea, different vocabulary. Internal-API hosts often ship with firewalld enabled but permissive; never trust the defaults without inspecting. Otherwise the threat model and the order of operations match the Ubuntu baseline: create a non-root user, harden SSH, enforce a host firewall, enable automatic security updates, turn on auditing, fix time. This guide is the RHEL-family-specific translation. ...

Hardened Ubuntu VPS Baseline

Tested on: Ubuntu 24.04 LTS (Noble Numbat), kernel 6.8.x, on a Hetzner Cloud CX22 instance. Steps are valid on any cloud VPS image of the same Ubuntu version. Why this matters A fresh Ubuntu cloud image is fine for a tutorial and unsuitable for production. Out of the box: The root account often accepts SSH key auth. No host firewall is enforced (the cloud provider’s network firewall is not a substitute, especially for internal traffic). Security updates apply only if you manually run apt upgrade. Time can drift by minutes, breaking TLS verification and log correlation. Audit logging is not enabled, so post-incident investigation depends on whatever syslog happens to have captured. This baseline closes those gaps in an opinionated order that minimises the window during which the server is reachable but not yet hardened. Before running step 1, pick your processors and decide your logging posture — some of the choices below depend on it. ...

SSH Hardening

Tested on: Ubuntu 24.04 LTS and AlmaLinux 9.4, OpenSSH 9.6 / 8.7 respectively. Configuration paths and directive names below are identical across both. Why this matters SSH is the front door to every server on this site. Three classes of failure account for almost every real-world SSH compromise: Password authentication accepting credentials harvested elsewhere. The root account directly logged into over SSH. A key from a former employee, contractor, or compromised workstation still present in ~/.ssh/authorized_keys six months later. This guide closes those holes and adds the minimum useful operational controls. It does not recommend changing the SSH port, fail2ban, or port-knocking as primary controls — those are noise reducers, not the security boundary. See “Gotchas” for why. ...