Harden Ubuntu Server Against the CIS Benchmark, Step by Step

Hardening a server "by feel" produces inconsistent results: every admin has a different mental checklist, and nobody can say what "done" means. The CIS Benchmarks solve this by providing a community-consensus, versioned specification of what a hardened system looks like — hundreds of specific, testable settings covering the filesystem, kernel, services, network stack, logging, and access control. For Ubuntu Server, the benchmark turns hardening from an art into a measurable engineering task: scan, remediate, re-scan, and track the score.

Understand the structure first

• Level 1 is the practical baseline: security improvements with minimal operational risk. This is the target for general-purpose servers and the scope of this guide.
• Level 2 is defense-in-depth for high-security environments — some settings break functionality and demand per-system evaluation. Treat it as an opt-in extension, not the default goal.
• Every recommendation includes a rationale, an audit command, and a remediation procedure — read the rationale before applying anything blindly.

Scan before you change anything

• Establish the baseline with an automated scanner: OpenSCAP with the Ubuntu SCAP content, the CIS-CAT tool (free Lite version, or Pro with CIS membership), or Ubuntu's own Ubuntu Security Guide (usg) tool available with Ubuntu Pro, which audits and remediates directly against the CIS profile.
• The first scan on an untouched server typically lands around 40–60% compliance — this is normal. The score's purpose is trend, not shame.
• Export the failed checks into a worklist and classify each: safe to apply everywhere, needs testing, or documented exception (some checks genuinely conflict with legitimate workloads).

Remediate in themed batches

• Filesystem: separate partitions with nodev, nosuid, noexec options for /tmp, /var/tmp, /dev/shm; disable unused filesystem kernel modules (cramfs, squashfs where unneeded, usb-storage on servers).
• Services: remove or mask everything not required — a hardened server runs the minimum service set. systemctl list-unit-files --state=enabled is the audit; every enabled unit needs a justification.
• Network/kernel: apply the sysctl set — disable IP forwarding and ICMP redirects, enable reverse-path filtering and SYN cookies, log martian packets — via a drop-in under /etc/sysctl.d/.
• Access control: password quality (pam_pwquality), account lockout (pam_faillock), sudo logging with a dedicated log file, restrictive umask, and su restricted to a wheel-equivalent group. The SSH section overlaps heavily with the dedicated SSH item on this site.
• Auditing/logging: install and configure auditd with the benchmark rule set (identity changes, privileged command execution, login records), ensure log file permissions, and forward logs off-host — local-only logs disappear with the compromised machine.
• Apply each batch to a test system first, run the workload's smoke tests, then roll to production in waves. Firewall configuration (ufw/nftables) deserves its own change window.

Automate for fleets and keep it enforced

• Hand-hardening does not scale past a handful of servers. Use the official CIS Build Kits, community Ansible roles (ansible-lockdown's UBUNTU24-CIS and similar), or usg fix with a tailoring file — always with your exceptions codified, not remembered.
• Bake the baseline into your golden image or cloud-init so new servers are born compliant instead of remediated later.
• Schedule recurring scans and feed results into your monitoring — compliance drifts as packages update and admins troubleshoot. A score that was 95% in January and 78% in June is telling you something.

Expect the journey from baseline to a stable 90%+ Level 1 score to take a few focused days for a single server, or a few weeks for a fleet with proper testing. Document every exception with a reason and an owner — auditors accept justified exceptions readily, and undocumented gaps poorly.