Lynis · hardening index

Faire monter son score Lynis : ce qui rapporte vraiment

2026-07-19 · HardStacked · 7 min de lecture

Tu as passé l'après-midi à durcir un serveur. Des clés sysctl, auditd, une bannière légale, AIDE. Tu relances lynis audit system et l'index a monté de deux points. Rien dans ce chiffre n'est évident : du gros travail ne rapporte rien, et une habitude apt coûte en silence plus que ce que la plupart des fixes rapportent.

En juillet 2026, on a mesuré un climb complet, fixe par fixe, sur des VM jetables et un VPS cloud, puis lu le code source de Lynis pour comprendre les surprises. Voici ce qui bouge vraiment le score, et ce qui ne le bouge pas.

1. Le plus gros levier est une pénalité à éviter, pas un point à gagner

Le plus gros coup unique de toute la suite de tests, c'est PKGS-7392 : des mises à jour de sécurité en attente. Dans le code source, c'est AddHP 0 25, vingt-cinq points ajoutés au dénominateur en une seule ligne. Il n'y a rien à gagner ici. Un système à jour saute le test ; un système en retard prend le coup au complet.

Le piège, c'est qu'apt peut te dire que le système est à jour pendant que la pénalité s'applique encore. Les mises à jour qui exigent d'ajouter ou de retirer un paquet sont « kept back » par apt upgrade. Mesuré sur notre box, le 19 juillet 2026 :

$ /usr/lib/update-notifier/apt-check --human-readable 13 packages can be updated. 11 of these updates are security updates. ← Lynis voit celles-là $ sudo apt-get upgrade --dry-run | grep -c '^Inst' 0 ← « rien à faire », dit apt upgrade. Les 11 sont kept back.

Sur cette machine, être complètement à jour valait quatre points d'index à lui seul, plus que n'importe quel paquet qu'on a installé.

L'habitude

sudo apt full-upgrade au lieu de upgrade, et lis le plan qu'il propose avant de dire oui (il peut ajouter ou retirer des paquets, c'est justement le but). Ensuite redémarre si /var/run/reboot-required existe : un noyau mis à jour sur disque mais pas chargé, c'est une autre pénalité (KRNL-5830). Patcher, redémarrer, puis scanner.

2. Installer un outil de sécurité ne rapporte (presque) rien

Sur une VM Debian 13 vierge, on a empilé 18 fixes de durcissement courants un à la fois, en mesurant après chacun. Dix des dix-huit ont bougé le score d'exactement zéro. Le motif derrière la plupart : Lynis ne crédite pas la présence d'un outil, il vérifie si l'outil fait réellement sa job.

auditd installé, activé, en marche : zéro. Et un jeu de règles vide est pénalisé par-dessus (c'est auditctl -l qui ne retourne rien que le test regarde).
AIDE installé sans initialiser sa base a rendu le rapport pire : Lynis a levé un nouveau warning sur la base manquante. On a ajouté un outil de sécurité et dégradé l'audit.
La bannière légale est notée au compte de mots-clés. Lynis greppe /etc/issue contre une liste de mots fixe et en veut au moins cinq. Notre première bannière en avait quatre. Zéro crédit, à un mot près.

L'habitude

Re-scanner après chaque changement et lire le delta. appliqué n'est pas crédité :

$ sudo lynis audit system --quick >/dev/null $ grep '^hardening_index' /var/log/lynis-report.dat hardening_index=79 ← le seul chiffre qui compte, avant et après chaque fixe

3. Le barème est binaire là où tu l'imagines proportionnel

On a comparé avec un système de référence qui roule AppArmor avec 26 profils en mode enforce. Son score MAC est identique à un seul profil chargé : le test vérifie seulement que aa-status sort proprement. Tout le travail de profils ne compte pour rien de plus.

Ça coupe dans l'autre sens aussi. Des partitions séparées pour /home, /tmp et /var ont l'air de valoir dix points chacune dans le code. Lis la branche d'échec : un système non partitionné reçoit déjà neuf des dix. Le vrai delta est de un point par montage, pour un changement impossible à défaire sur un VPS.

L'habitude

Avant de copier la config d'un système qui score haut, lis ce que le test vérifie vraiment (include/tests_* dans le code source de Lynis), les deux branches. La condition est souvent bien plus faible que ce que le système de référence exhibe, et parfois le changement coûteux que tu envisages ne vaut presque rien.

4. SSH est le test le plus lourd, et c'est tout ou rien

SSH-7408 juge autour de dix-neuf directives de sshd_config (X11Forwarding, MaxAuthTries, ClientAliveInterval, AllowTcpForwarding, LoginGraceTime…), chacune valant des points. Il pèse plus que n'importe quelle autre zone. Mais durcis deux ou trois options et tu obtiens zéro : on a mesuré les deux moitiés d'un durcissement SSH partiel à +0. Le bloc score comme un bloc.

L'habitude

Pousse le bloc SSH complet en un seul changement révisé, puis sshd -t, puis teste depuis un deuxième terminal avec ta session courante encore ouverte. Éditer autant de directives d'un coup, c'est exactement comme ça qu'on se barre dehors ; on a écrit un article complet sur les cinq lock-outs SSH classiques et les habitudes qui les rendent survivables.

5. Résoudre des suggestions ne monte pas l'index

Beaucoup de tests Lynis émettent une suggestion sans aucun point attaché. On a résolu sept findings dans une passe : index inchangé. Une autre passe, deux suggestions de plus réglées : inchangé encore. La liste de suggestions et le score sont deux instruments différents.

Les points ne s'additionnent pas non plus. Nos fixes mesurés isolément totalisaient +14 ; empilés sur le même système, ils ont donné +11. Plusieurs fixes se disputent le même point, donc une estimation « module par module » promet toujours trop.

L'habitude

Traite l'index comme un détecteur de régression, pas comme une liste de tâches. La liste de suggestions te dit où regarder ; seul un avant/après mesuré te dit ce qu'un changement valait.

Les quatre règles d'un climb honnête

Fige ta version de Lynis. On a mesuré le même système inchangé à 21 points d'écart entre Lynis 3.1.4 et 3.1.7. Un score sans la version de son auditeur ne veut rien dire.
Mesure le delta après chaque changement. grep '^hardening_index' /var/log/lynis-report.dat. Un fixe qui rapporte un succès peut ne rien créditer.
full-upgrade, redémarrage, puis scan. Sinon les deux plus grosses pénalités de la suite s'assoient par-dessus tout ce que ton travail de config rapporte.
Le score est un thermomètre, pas le traitement. Nos changements les plus pertinents en sécurité (auth SSH par clé seulement, règles de qualité de mot de passe) ont mesuré +0. Vise la posture ; sers-toi du chiffre pour attraper les régressions.

De quoi a l'air un vrai climb

Mesuré les 18 et 19 juillet 2026, sur un VPS cloud Ubuntu 24.04 x86 avec Lynis 3.1.7 figé : baseline 57, puis 79 après 32 fixes révisés, puis retour à 57 exactement après les avoir tous annulés. La veille, une VM Debian 13 vierge est passée de 64 à 75 avec un jeu plus petit. Distro différente, baseline différente, mêmes leçons : les points vivent dans quelques tests lourds, l'état de tes paquets et des blocs complétés, pas dans le nombre d'outils installés.

La leçon de fond

Grimper à la main, c'est des jours de scan, changement, re-scan, et une pile grandissante de modifications qu'il faudrait défaire de mémoire. Les deux habitudes qui comptent, mesurer chaque delta et préparer le chemin du retour avant chaque changement, sont exactement celles que le travail manuel saute à 2 h du matin.

Cette boucle, c'est ce que HardVps automatise : le chemin 57 → 79 ci-dessus est sa démo mesurée, chaque fixe est appliqué avec l'original capturé d'abord, chaque fichier restauré est vérifié à l'octet près par SHA-256, et les fixes risqués sont opt-in derrière un avertissement explicite.

Voir ce que HardVps fait →

Sur un Raspberry Pi ? Commence gratuitement avec audit-pi, notre audit de sécurité open source.