Lynis & CIS Benchmark : auditer Linux

Un durcissement que l'on ne mesure pas finit par dériver. Un référentiel transforme un objectif flou (« sécuriser ce serveur ») en une cible concrète et reproductible, et produit des preuves exploitables lors d'un audit. Ce domaine relie tous les autres : noyau, comptes, journalisation, services et mises à jour apparaissent tous comme des contrôles notés. La démarche est toujours la même — choisir un référentiel, scanner, lire le score, remédier, rescanner. Une précision sur Lynis et les CIS Benchmarks : Lynis fournit un hardening index rapide et indépendant de la distribution plutôt qu'un pass/fail sur un profil CIS précis, tandis qu'OpenSCAP vous note directement face à un CIS Benchmark choisi (ou STIG/ANSSI) — la plupart des équipes utilisent les deux.

Pourquoi mesurer, et quel référentiel

Trois référentiels dominent le monde Linux :

• CIS Benchmarks — guides consensuels par distribution, découpés en niveau 1 (base sûre qui ne perturbe pas l'usage normal) et niveau 2 (défense en profondeur pour hôtes sensibles, peut casser des fonctionnalités). Le meilleur point de départ généraliste.
• DISA STIG — standard plus strict du département de la Défense américain. À utiliser lorsqu'un contrat ou un cadre l'impose.
• ANSSI-BP-028 — les recommandations nationales françaises pour GNU/Linux, graduées minimal / intermédiaire / renforcé / élevé. La bonne référence pour le secteur public français et de nombreux contextes réglementés en Europe.

Choisissez un seul référentiel comme source de vérité plutôt que de panacher les contrôles. Rattachez-y les autres domaines : les sysctl noyau de kernel-hardening, sudo et la politique de mots de passe d'accounts-privileges, auditd et journald de logging-auditing.

Gains rapides avec Lynis

Lynis est un audit rapide et sans agent. Il ne modifie rien : il note et conseille.

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

Lisez l'indice de durcissement (hardening index) en fin de rapport (0–100). Distinguez ensuite les deux classes de sortie : les avertissements (warnings) sont des problèmes à corriger rapidement ; les suggestions sont des améliorations à évaluer. Approfondissez n'importe quel contrôle :

sudo lynis show details TEST-ID
sudo lynis show groups

Ajustez le périmètre via un profil personnalisé pour ne pas courir après des constats hors sujet (par exemple sur un hôte où vous n'exécutez volontairement aucun pare-feu) :

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

Suivez l'indice dans le temps : sa progression est la preuve que la remédiation a tenu.

OpenSCAP et le SCAP Security Guide

OpenSCAP évalue un hôte par rapport aux profils CIS/STIG lisibles par machine fournis par le SCAP Security Guide (paquet scap-security-guide).

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

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

Ouvrez report.html pour un détail réussite/échec par règle, avec le texte de remédiation. Remplacez l'identifiant de profil par un profil STIG ou ANSSI, et le datastream de la distribution (ssg-ubuntu2404-ds.xml, ssg-debian12-ds.xml) selon votre hôte.

Automatiser la remédiation de façon responsable

OpenSCAP peut générer des correctifs à partir d'un fichier de résultats plutôt que d'appliquer des changements à l'aveugle. Préférez la sortie Ansible, relisable et idempotente :

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

N'appliquez jamais la remédiation d'abord en production. Déployez-la en préproduction, vérifiez que les services démarrent toujours (notamment ceux touchés dans services-systemd et updates-packages), puis promouvez. Les rôles Ansible officiels du SCAP Security Guide constituent la voie supportée pour un durcissement reproductible sur un parc.

Vérifier et suivre le score

Bouclez la boucle : rescannez après chaque passe de remédiation et confirmez que le chiffre a bougé dans le bon sens.

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'

Consignez pour chaque hôte le pourcentage de réussite OpenSCAP et l'indice Lynis au fil du temps. Un référentiel n'est utile que si son score est mesuré en continu : la dérive se voit dans un chiffre qui baisse bien avant de se voir dans un incident.