Audit Linux Hardening with Lynis, CIS & OpenSCAP

Hardening you cannot measure will drift. A baseline turns a vague goal ("make this server secure") into a concrete, repeatable target and produces evidence you can hand to an auditor. This domain ties every other one together: kernel, accounts, logging, services and patching all show up as scored controls in a benchmark. The workflow is always the same — pick a baseline, scan, read the score, remediate, re-scan.

Why measure, and which baseline

Three baselines dominate Linux work:

• CIS Benchmarks — consensus-driven, per-distribution guides split into Level 1 (a safe baseline that should not disrupt normal use) and Level 2 (defense-in-depth for high-security hosts, may break functionality). Best general-purpose starting point.
• DISA STIG — stricter US Department of Defense standard. Use it when a contract or framework mandates it.
• ANSSI-BP-028 — the French national recommendations for GNU/Linux, graded minimal / intermediate / reinforced / high. The right reference for French public sector and many EU regulated contexts.

Pick one baseline as the source of truth rather than mixing controls ad hoc. Map the other domains to it: kernel sysctl from kernel-hardening, sudo and password policy from accounts-privileges, auditd and journald from logging-auditing.

Quick wins with Lynis

Lynis is a fast, agentless audit. It does not change anything — it scores and advises.

sudo apt install lynis        # or dnf install lynis
sudo lynis audit system

Read the hardening index at the end (0–100). Then separate the two output classes: warnings are issues to fix soon; suggestions are improvements to evaluate. Drill into any control:

sudo lynis show details TEST-ID
sudo lynis show groups

Tune scope with a custom profile so you do not chase irrelevant findings (e.g. on a host where you intentionally run no firewall):

# /etc/lynis/custom.prf
skip-test=FIRE-4512

Track the hardening index over time — a rising number is your proof that remediation stuck.

OpenSCAP and the SCAP Security Guide

OpenSCAP evaluates a host against machine-readable CIS/STIG profiles shipped by the SCAP Security Guide (scap-security-guide package).

sudo dnf install openscap-scanner scap-security-guide
oscap info /usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml   # list profiles

sudo oscap xccdf eval \
  --profile xccdf_org.ssgproject.content_profile_cis \
  --results scan-results.xml \
  --report report.html \
  /usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml

Open report.html for a per-rule pass/fail breakdown with remediation text. Swap the profile id for a STIG or ANSSI profile and the distro datastream (ssg-ubuntu2404-ds.xml, ssg-debian12-ds.xml) to match your host.

Automating remediation responsibly

OpenSCAP can generate fixes from a results file instead of applying blind changes. Prefer the Ansible output so the change is reviewable and idempotent:

sudo oscap xccdf generate fix \
  --fix-type ansible \
  --profile xccdf_org.ssgproject.content_profile_cis \
  --result-id "" \
  scan-results.xml > remediate.yml

Never run remediation first on production. Apply it in staging, confirm services still start (especially anything touched in services-systemd and updates-packages), then promote. The official SCAP Security Guide Ansible roles are the supported path for repeatable hardening across a fleet.

Verify and track the score

Close the loop: re-scan after every remediation pass and confirm the number moved the right way.

sudo oscap xccdf eval \
  --profile xccdf_org.ssgproject.content_profile_cis \
  --report report-after.html \
  /usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml

sudo lynis audit system | grep -i 'hardening index'

Record both the OpenSCAP pass percentage and the Lynis index for each host over time. A baseline is only useful when its score is measured continuously — drift shows up as a falling number long before it shows up as an incident.