Audit de durcissement : Lynis, ANSSI, CIS#

Pourquoi#

Les chapitres précédents (Durcissement SSH, Durcissement système, nftables, fail2ban) appliquent des mesures de sécurité ponctuelles, chacune justifiée individuellement. Mais comment savoir si l’ensemble, une fois combiné, atteint un niveau de durcissement cohérent, et surtout, comment comparer objectivement ce niveau à des référentiels reconnus plutôt qu’à une impression subjective de “j’ai fait ce qu’il fallait” ? C’est le rôle d’un audit automatisé.

Ce guide, y compris ce chapitre, ne vise pas l’exhaustivité en matière de sécurité. Lynis lui-même ne couvre pas tout (il le dit explicitement dans ses propres résultats, sous forme de suggestions) : c’est un outil d’aide à la décision, pas une garantie de sécurité absolue. Le score obtenu doit être traité comme un indicateur parmi d’autres, pas comme une certification.

Comment#

Lynis : l’auditeur de référence#

Lynis exécute environ 300 contrôles répartis en plus de 60 catégories (authentification, réseau, pare-feu, stockage, journalisation, SSH, cryptographie, durcissement noyau, détection de malware…). Chaque test produit un PASS, un WARNING, ou une SUGGESTION, et un score global, le Hardening Index, résume la proportion de tests réussis sur une échelle de 0 à 100.

apt install -y lynis debsums
mkdir -p /var/log/lynis

lynis audit system --quiet 2>&1 | tee /var/log/lynis/baseline-$(date +%Y%m%d_%H%M%S).log

grep "Hardening index" /var/log/lynis/lynis.log

# Lister les points à corriger
lynis show warnings
lynis show suggestions

# Si "Unknown argument" (arrive sur certaines versions) :
grep "Warning:" /var/log/lynis/lynis.log
grep "Suggestion:" /var/log/lynis/lynis.log

Les référentiels derrière Lynis#

Lynis ne sort pas de nulle part : il opérationnalise des recommandations issues de référentiels reconnus.

• CIS Benchmarks (Center for Internet Security) : benchmarks détaillés par système d’exploitation (ex. CIS Debian 12 Benchmark), avec plusieurs niveaux (L1 Server, L1 Workstation, L2 Server…). Lynis se positionne globalement entre le niveau L1 (plus pragmatique) et le niveau L2 (plus exigeant) du CIS.
• ANSSI BP-028 : les Recommandations de configuration d’un système GNU/Linux de l’Agence Nationale de la Sécurité des Systèmes d’Information (France), 80 recommandations réparties sur 4 niveaux (minimal, intermédiaire, renforcé, élevé). Plusieurs directives déjà posées dans les chapitres précédents en sont directement issues : kernel.kptr_restrict=2, kernel.dmesg_restrict=1, permissions 0700 sur /etc/cron.*, UMASK 027, SHA_CRYPT_ROUNDS élevé (chapitre Durcissement système).

Compléter les règles auditd maintenant que tout est installé#

Le chapitre Durcissement système a délibérément limité les règles auditd à ce qui existait déjà à ce stade (comptes système, SSH) : une règle -w sur un fichier absent fait échouer son propre chargement. Maintenant que chrony, nftables et fail2ban sont installés, les fichiers qu’ils utilisent existent : c’est le bon moment pour étendre la surveillance :

cat >> /etc/audit/rules.d/99-stratum1.rules <<'EOF'
-w /etc/chrony/                -p wa -k chrony_config
-w /etc/nftables.conf          -p wa -k nft_config
-w /etc/fail2ban/              -p wa -k f2b_config
EOF

augenrules --load
auditctl -l | grep -E "chrony_config|nft_config|f2b_config"

Interpréter un score#

Erreurs à éviter#

Un warning Lynis n’est pas automatiquement un vrai problème, mais il ne doit jamais être écarté sans en comprendre la cause. Exemple réel rencontré sur ce projet : Lynis signalait en permanence [WARNING] Can't find any security repository in /etc/apt/sources.list (test PKGS-7388). Cause : le serveur tournait alors une version Debian encore en phase testing avant le freeze, dont les dépôts utilisaient une convention (trixie-updates) différente de celle que Lynis recherche spécifiquement (une ligne *-security). C’était un faux positif documenté, propre à cette phase du cycle de release Debian, disparu de lui-même après le passage en stable (Debian 13 « trixie », août 2025). La bonne pratique n’est pas de l’ignorer silencieusement, mais de le documenter explicitement comme faux positif accepté, avec la raison, pour qu’un futur audit ne reparte pas de zéro dans l’investigation.

• Viser 100/100 sans réfléchir au coût. Passer de 82 à 90+ nécessite typiquement des profils AppArmor ciblés par service (plusieurs jours de travail), un système de surveillance d’intégrité de fichiers comme AIDE (charge CPU/IO récurrente), et une politique de mots de passe stricte (friction opérationnelle). Pour un opérateur unique gérant un seul serveur, ce rapport coût/bénéfice est souvent défavorable : AppArmor prend tout son sens quand on doit comparer et maintenir des centaines de serveurs, beaucoup moins sur une instance unique déjà auditée mensuellement.
• Copier une remédiation Lynis sans vérifier qu’elle s’applique au contexte réel. Certaines suggestions Lynis n’ont de sens que sur des architectures spécifiques (ex. partitions /home et /var séparées, non pertinent sur un Raspberry Pi à rootfs unique par conception). Accepter consciemment une suggestion inapplicable, documentée comme telle, vaut mieux que de forcer une remédiation qui ne correspond pas à l’architecture réelle.
• Traiter chaque suggestion isolément sans vue d’ensemble. Sur la vingtaine de suggestions qui subsistent généralement à 82/100, la plupart sont soit informationnelles, soit des arbitrages de politique délibérés (durée de validité des mots de passe), autant les lister et les trancher une fois, plutôt que de les revoir individuellement à chaque audit.

Vérifier#

# Score courant
grep "Hardening index" /var/log/lynis/lynis.log | tail -1

# Détail d'un test spécifique pour comprendre un warning
lynis show details SSH-7408

# Fraîcheur de l'audit (Lynis lui-même signale un audit trop ancien)
stat -c %Y /var/log/lynis/lynis.log

Lynis gagne à être programmé en tâche mensuelle (cron ou systemd timer) plutôt que lancé uniquement à l’installation. Un score qui se dégrade dans le temps (paquet retiré, service réactivé par une mise à jour, permission modifiée manuellement) est bien plus facile à corriger s’il est détecté tôt qu’après plusieurs mois de dérive silencieuse.

📚 Pour aller plus loin

• Documentation officielle Lynis : cisofy.com/lynis.
• CIS Benchmarks : cisecurity.org.
• ANSSI, Recommandations de configuration d’un système GNU/Linux (référence BP-028), disponible sur cyber.gouv.fr.