La première exécution de Lynis sur un VPS neuf donne d’ordinaire une valeur autour de 60 et une longue liste de suggestions où l’on ne sait par quoi commencer. La bonne nouvelle : 80 à 85 représentent le travail d’une soirée, et la plupart des étapes ne sont pas cosmétiques mais réellement utiles. La mauvaise : les quinze derniers points sont hors d’atteinte sur une machine virtuelle louée, et les poursuivre est une erreur.

Ce que l’indice montre et ce qu’il ne montre pas

L’indice de durcissement est le rapport pondéré des tests réussis au total — pas un pourcentage de sécurité. Lynis exécute environ trois cents tests et produit deux listes distinctes : warnings, qui ressemblent à de vrais problèmes, et suggestions, c’est-à-dire ce qui pourrait être amélioré. Commencez toujours par les avertissements ; ils sont généralement peu nombreux.

Cent points n’existent pas : certaines recommandations supposent des décisions prises à l’installation du système (des partitions séparées pour /home, /tmp et /var), d’autres exigent un accès au chargeur d’amorçage dont un VPS ne dispose pas, d’autres encore se contredisent. Et comparer son indice à celui d’autrui ne sert à rien : Lynis retire des points pour ce qui tourne sur la machine. Chaque service actif est un port ouvert de plus, une configuration propre et une douzaine de nouvelles suggestions — d’où des valeurs élevées surtout là où rien d’autre que SSH ne tourne. Pour un serveur de travail avec un site, une base de données et de la messagerie, 85 est un bon résultat.

Exécuter en root

sudo lynis audit system

Sans sudo, Lynis saute tous les tests qui ont besoin des fichiers système et annonce un indice plus bas — non parce que le serveur serait mauvais, mais parce que les contrôles étaient invisibles. Le rapport est écrit dans /var/log/lynis-report.dat, le journal lisible dans /var/log/lynis.log.

Chaque ligne de sortie commence par un identifiant de test tel que SSH-7408 ou KRNL-6000. C’est par cet identifiant que se trouvent aussi bien l’explication que le moyen de désactiver un test — retenez sa forme, tout le reste tourne autour d’elle.

Ce qui fait réellement bouger le nombre

SSH (SSH-7408). Le bloc le plus lourd : un seul test vérifie une douzaine de paramètres à la fois. Ne modifiez pas tout sshd_config, déposez un fichier séparé afin qu’une mise à jour du paquet n’efface pas votre travail :

sudo tee /etc/ssh/sshd_config.d/10-hardening.conf <<'EOF'
PermitRootLogin no
PasswordAuthentication no
MaxAuthTries 3
MaxSessions 2
X11Forwarding no
AllowTcpForwarding no
ClientAliveInterval 300
ClientAliveCountMax 2
LogLevel VERBOSE
TCPKeepAlive no
EOF
sudo sshd -t && sudo systemctl reload ssh

sshd -t avant de recharger le service est obligatoire : une erreur dans la configuration alors que votre session est ouverte vous laissera dehors. Et avant de mettre PasswordAuthentication no, assurez-vous que la clé fonctionne réellement — depuis un second terminal ouvert.

Paramètres du noyau (KRNL-6000). Le test vérifie une vingtaine de valeurs sysctl. Un fichier pour cela :

sudo tee /etc/sysctl.d/99-hardening.conf <<'EOF'
kernel.dmesg_restrict = 1
kernel.kptr_restrict = 2
kernel.sysrq = 0
fs.protected_hardlinks = 1
fs.protected_symlinks = 1
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.all.log_martians = 1
EOF
sudo sysctl --system

Outils manquants. Une bonne part des suggestions se résume à « installez ce qui n’est pas là » : auditd (journal des événements système), aide (intégrité des fichiers), debsums (intégrité des paquets), unattended-upgrades (mises à jour de sécurité automatiques), sysstat et acct (comptabilité des processus), un antivirus. Chacun ferme une ou deux recommandations, mais installez-les non pour les points : sans eux, vous ne reconstituerez rien après un incident.

Petites choses au bon rapport effort/résultat. umask 027 dans /etc/login.defs ; la durée de vie des mots de passe dans le même fichier ; les bannières /etc/issue et /etc/issue.net ; les compilateurs lisibles par root seul (chmod 700 /usr/bin/gcc). Au sujet des bannières, disons-le franchement : elles n’apportent rien à la sécurité, c’est une formalité juridique — mais elles donnent un point.

Un piège dans login.defs

Modifier umask par un remplacement de ligne avec sed laisse souvent plusieurs lignes UMASK dans le fichier. Lynis ne prend alors pas la valeur en compte, et le test AUTH-9328 reste rouge bien que le réglage paraisse fait. Vérifiez après modification :

grep -c '^UMASK' /etc/login.defs

Il doit y en avoir exactement une. Il en va de même pour tout autre paramètre de ce fichier.

Faux positifs et comment les faire taire correctement

Certains avertissements ne concernent pas du tout votre serveur. Un exemple réel : sur le VPS d’un grand hébergeur, le test PKGS-7388 signale qu’aucun dépôt de sécurité n’a été trouvé — simplement parce que les dépôts sont décrits au format deb822 avec un renvoi vers un fichier de miroirs, tandis que Lynis cherche la ligne habituelle. Les mises à jour de sécurité arrivent pourtant parfaitement.

Cela se fait taire non en supprimant des lignes du rapport, mais avec un profil. Les fichiers de profil portent l’extension .prf (et non .prof — on y perd facilement une demi-heure), et vos règles vont dans /etc/lynis/custom.prf :

skip-test=PKGS-7388
skip-test=KRNL-5788

Une règle : chaque ligne doit être accompagnée d’un commentaire expliquant pourquoi le test est ignoré. Dans six mois, vous ne saurez plus s’il a été désactivé parce qu’il ne s’applique pas ou parce que le corriger était trop pénible — et la différence entre ces deux cas est tout l’enjeu.

Ce qu’il ne faut pas faire

Ne courez pas après le chiffre. L’indice se gonfle aisément en désactivant les tests gênants, et au-delà d’un certain niveau c’est le seul moyen — sauf que le serveur n’en devient pas plus sûr. Autre chose est utile : fixer votre propre valeur et surveiller ses variations. Un indice qui chute après une mise à jour ou la modification d’une configuration par quelqu’un d’autre est un signal bien plus précieux que sa valeur absolue.

C’est précisément pourquoi il vaut la peine de lancer Lynis selon un calendrier plutôt qu’une seule fois, et de conserver les rapports pour avoir de quoi comparer. À quoi cela ressemble rassemblé sur une page, la démonstration ci-dessous le montre : l’indice, la liste des avertissements avec leurs identifiants de test et ce qui a changé depuis l’exécution précédente.