Summary

Linux Security Checklist

A single actionable checklist consolidating every control in this foundation.

Every page in this foundation ends with guidance, but when you sit down to harden a real host you want one list, in a sensible order, that you can work through and tick off. This page is that list. Each item is a single actionable check, grouped by the foundation’s sections, with a pointer to the page that explains the why. The ordering within each group runs roughly from highest value for effort to more specialized, so a host that gets only halfway down is still meaningfully hardened.

Use it two ways: as a build sheet when standing up a new host, and as an audit template when reviewing an existing one. Copy it, work top to bottom, and record exceptions rather than skipping them silently.

How to use this checklist

Treat every unchecked box as either a task or a documented exception. An accepted exception (a control that would break your workload) is a legitimate outcome; an item you simply forgot is not. Re-run the checklist periodically, because configuration drifts and a box that was ticked last quarter may not be today.

System Hardening

  • unattended-upgrades enabled and scoped to the -security origin (Patch Management)
  • Reboot behavior set deliberately; needrestart shows no long-standing pending kernel (Patch Management)
  • pro security-status or an equivalent scanner reviewed for open CVEs (Patch Management)
  • Livepatch enabled on hosts that cannot reboot quickly (Patch Management)
  • Secure Boot enabled and a GRUB password set (Boot & Kernel Hardening)
  • Hardening sysctl set applied: kptr_restrict, dmesg_restrict, yama.ptrace_scope (Boot & Kernel Hardening)
  • unprivileged_userns_clone decision made and tested against the workload (Boot & Kernel Hardening)
  • Rare network and filesystem modules blacklisted with install ... /bin/false (Boot & Kernel Hardening)
  • Kernel lockdown active (integrity or confidentiality) where Secure Boot allows (Boot & Kernel Hardening)
  • Exposed services scored with systemd-analyze security (Systemd Hardening)
  • Custom and high-risk units hardened via drop-in overrides, not edited in place (Systemd Hardening)
  • NoNewPrivileges, ProtectSystem=strict, PrivateTmp, and scoped ReadWritePaths set on custom services (Systemd Hardening)
  • Capabilities and syscalls restricted with CapabilityBoundingSet= and SystemCallFilter= (Systemd Hardening)
  • Host audited with Lynis and a CIS profile in OpenSCAP (CIS Benchmark)
  • Benchmark warnings triaged first, findings ranked by attack-path impact (CIS Benchmark)
  • Accepted benchmark exceptions documented rather than left as silent fails (CIS Benchmark)

Logging & Auditing

  • Journal made persistent under /var/log/journal (System Logs)
  • journalctl filters practiced for fast incident querying (System Logs)
  • SSH set to key-only auth; fail2ban acting on brute-force bursts (System Logs)
  • Alert configured for a successful login following a burst of failures (System Logs)
  • Logs forwarded to a separate host or network in near real time (System Logs)
  • auditd installed and active (Auditd)
  • Starter ruleset loaded: identity files, root execve, module loading, time changes (Auditd)
  • Every audit rule tagged with a -k key; b64 and b32 variants present (Auditd)
  • Audit config made immutable with -e 2 (Auditd)
  • /var/log/audit/audit.log forwarded off-host and disk usage watched (Auditd)
  • AIDE database initialized on a clean host and stored read-only or off-host (Intrusion Detection)
  • Re-baseline scheduled after each patch cycle (Intrusion Detection)
  • No UID 0 accounts other than root; startup hooks and SSH keys reviewed (Intrusion Detection)
  • osquery deployed for fleet-wide behavioral queries where scale warrants (Intrusion Detection)
  • rkhunter or chkrootkit run, with results treated as weak evidence (Intrusion Detection)

Ongoing operations

  • Checklist re-run on a schedule to catch configuration drift
  • Exceptions reviewed to confirm they are still justified
  • Lab VM snapshots used to test every change before it reaches production

Practical Guidance

  1. Work top to bottom within each group, since items are ordered by value for effort and a partial pass still hardens the host meaningfully.
  2. Record every unchecked box as a task or a documented exception, never as a silent skip.
  3. Follow each item back to its source page when you are unsure why it matters, rather than applying it blindly.
  4. Test changes on a snapshotted lab VM first, especially the boot and kernel items most likely to break a host.
  5. Re-run the whole checklist on a schedule, because configuration and threats both drift over time.
  6. Keep the completed checklist as evidence, so an auditor or a future teammate can see what was done and what was consciously accepted.