Durcir un serveur Linux ? Commencez par l'auditer avec Lynis

Lynis est un outil en ligne de commande qui scanne une machine Linux, macOS ou BSD et renvoie une liste de tâches : des dizaines de faiblesses précises, chacune classée selon son importance. Il n’en corrige aucune. Cet écart, entre repérer un problème et décider quoi en faire, c’est exactement ce que la plupart des guides pour durcir un serveur Linux escamotent. Les checklists génériques circulent de serveur en serveur et s’appliquent du haut en bas, qu’elles correspondent ou non à la machine qui les reçoit. Lynis prend le chemin inverse : il audite d’abord, note ce qu’il trouve, et laisse la décision à la personne qui gère réellement la machine.

Ce guide suppose un accès sudo à une machine Debian, Ubuntu, de la famille RHEL, ou macOS/BSD. Testez-le sur une machine de test ou une VM jetable en premier lieu. Certains correctifs ci-dessous touchent SSH, le protocole de connexion à distance par lequel la plupart des serveurs sont administrés, et un mauvais réglage à cet endroit peut vous verrouiller dehors.

Installer Lynis

Lynis est packagé dans la plupart des dépôts de distribution, en général avec une version de retard. Sur Debian et Ubuntu :

sudo apt update
sudo apt install lynis

Sur Fedora, RHEL et les autres systèmes de la famille Red Hat :

sudo dnf install lynis

Pour la version la plus récente, clonez directement depuis la source :

cd /usr/local
sudo git clone https://github.com/CISOfy/lynis

Michael Boelen a créé Lynis en 2007, et le développe encore aujourd’hui via CISOfy, la société néerlandaise qu’il a fondée en 2013. L’outil de base est gratuit, open source, sous licence GPLv3. Un module payant existe pour piloter des audits sur plusieurs serveurs depuis un tableau de bord unique, mais tout ce qui suit dans ce guide fonctionne avec la seule version en ligne de commande, gratuite.

Lancer votre premier audit

Une fois installé, l’audit complet tient en une commande :

sudo lynis audit system

Il passe la machine au crible, section par section : le chargeur de démarrage, la façon dont les connexions sont authentifiées, les permissions des fichiers et répertoires, les paquets installés, les réglages réseau, le pare-feu, la configuration SSH, la journalisation, entre autres. Un passage complet prend une à deux minutes sur un serveur typique. Tout ce que Lynis trouve s’affiche à l’écran au fur et à mesure, étiqueté observation, avertissement ou suggestion. Le même détail est écrit dans deux fichiers pour consultation ultérieure : /var/log/lynis.log pour le journal test par test, et /var/log/lynis-report.dat pour les résultats structurés qu’un script ou une comparaison future pourra relire.

L’accès root n’est pas strictement obligatoire. Un flag --pentest lance un scan non privilégié qui saute tout test nécessitant les droits root :

lynis audit system --pentest

Ce mode ne remplace pas l’audit complet. Des catégories entières restent non testées, donc le score qui en ressort est plus bas et signifie moins de choses. Ce pour quoi il est utile, c’est un premier coup d’œil rapide sur une machine avant d’y avoir un accès élevé, ou une vérification externe rapide par quelqu’un qui, justement, ne devrait pas avoir sudo sur cette machine-là.

Lire le hardening index sans courir après le chiffre

L’audit se termine par un hardening index, une note de 0 à 100 censée résumer combien de mesures recommandées sont en place. En pratique, une installation fraîche et non configurée se situe couramment dans les 50 ou les 60, et un serveur qui a subi un vrai passage de durcissement peut monter dans les 80 ou plus.

Boelen, qui écrit toujours sur l’outil sur son propre site, est direct sur ce que ce chiffre n’est pas : le hardening index n’est qu’un indicateur des mesures prises, pas un pourcentage de la sécurité réelle du système. Il met aussi en garde contre le raccourci évident : désactiver ou sauter les tests qu’un système échoue systématiquement, juste pour voir le score grimper. Ça fait monter le chiffre sans toucher au risque réel, et ça rend toute comparaison avec une autre machine dénuée de sens.

La bonne lecture du score est relative, pas absolue. Ce serveur est-il mieux durci qu’il ne l’était le mois dernier, et l’écart entre lui et un serveur comparable dans le même parc a-t-il du sens.

Corrigez d’abord les deux changements qui comptent le plus

Un premier passage Lynis sur un serveur moyen peut renvoyer plus de cinquante suggestions. Essayer de toutes les traiter en une session, c’est généralement comme ça que finissent la plupart des audits : quelqu’un ouvre la liste, corrige trois éléments, et n’y revient jamais. Deux changements, signalés sur presque toute installation par défaut, valent la peine d’être faits avant tout le reste de la liste.

Le premier concerne l’authentification SSH par mot de passe. Si la connexion par clé fonctionne déjà, confirmez-le dans une seconde session de terminal avant de fermer la première, puis désactivez complètement la connexion par mot de passe :

sudo sed -i 's/#\?PasswordAuthentication .*/PasswordAuthentication no/' /etc/ssh/sshd_config
sudo systemctl restart sshd

Ça supprime toute une catégorie d’attaques par devinette de mot de passe contre SSH, en général le service le plus fréquemment sondé sur n’importe quel serveur exposé sur internet. C’est aussi le même réflexe qui sous-tend une architecture zero trust : arrêter d’accorder l’accès par défaut et exiger une preuve à la place.

Le second concerne Fail2Ban, un démon qui surveille des fichiers de journal comme /var/log/auth.log et bloque temporairement toute adresse IP qui accumule trop de tentatives de connexion échouées :

sudo apt install fail2ban
sudo systemctl enable --now fail2ban

La documentation de Fail2Ban est claire sur ce que ça apporte : ça réduit le rythme des tentatives d’intrusion, mais ça ne peut pas corriger une authentification faible à lui seul, ce qui explique pourquoi il vient s’ajouter au changement SSH ci-dessus, pas le remplacer.

Automatiser le ré-audit et suivre la tendance

Un audit ponctuel n’est qu’une photo à un instant donné. Lynis est fait pour tourner à répétition, et il a un flag prévu pour ça :

sudo lynis audit system --cronjob

Le flag --cronjob lance le scan sans invites interactives, ce qui le rend adapté à une tâche planifiée :

# /etc/cron.weekly/lynis-audit
#!/bin/sh
lynis audit system --cronjob

Chaque exécution écrase le même fichier /var/log/lynis-report.dat, donc gardez une copie datée après chaque scan si l’objectif est une vraie courbe de tendance plutôt que le dernier instantané seul. Comparer deux rapports côte à côte montre quelles suggestions ont été résolues et lesquelles sont apparues depuis le dernier passage, un signal plus concret que le chiffre du score seul.

Confirmer un correctif isolé ne demande pas de relancer un audit complet. Le flag --tests-from-category restreint un scan à un seul domaine :

sudo lynis show categories
sudo lynis audit system --tests-from-category <nom-de-catégorie>

Lancer la liste des catégories une fois montre les noms exacts que Lynis reconnaît sur cette installation. Un ré-audit ciblé juste après le changement SSH ci-dessus se termine en quelques secondes plutôt qu’en plus d’une minute pour un scan complet, ce qui rend réaliste de vérifier un correctif tout de suite plutôt que d’attendre le prochain audit planifié.

Testez avant de toucher à la production

Chaque changement suggéré ci-dessus, désactiver les mots de passe SSH, redémarrer un démon, resserrer une règle de pare-feu, peut aussi casser quelque chose qui dépend de la configuration actuelle, plus permissive : un agent de supervision qui s’authentifie encore par mot de passe, une tâche cron qui suppose qu’un port reste ouvert. Appliquez les suggestions de Lynis sur une copie de préproduction du serveur d’abord, ou gardez au minimum une seconde session ouverte en parallèle pendant le redémarrage de SSH, pour qu’une erreur ne vous coupe pas le seul chemin d’accès disponible.

Questions fréquentes

Est-il sûr de lancer Lynis sur un serveur en production ?

Oui. Un audit lynis audit system standard ne fait que lire des fichiers de configuration et de journal. Il ne modifie rien sur la machine par défaut, donc le lancer sur un serveur en production ne comporte pas plus de risque que n’importe quel autre outil d’inspection en lecture seule.

Lynis corrige-t-il les problèmes qu’il trouve ?

Non, et c’est délibéré. Lynis produit une liste de suggestions notées, avec des liens vers la documentation et, pour beaucoup d’entre elles, la commande exacte pour corriger. Mais appliquer l’un ou l’autre reste une décision manuelle. Le produit payant Lynis Enterprise ajoute du reporting centralisé sur plusieurs serveurs, pas de correction automatique.

Qu’est-ce qu’un bon score de hardening index ?

Il n’existe pas de note de passage universelle. Le chiffre est utile pour suivre la progression d’un serveur dans le temps, ou pour repérer une machine d’un parc qui traîne nettement derrière les autres. Traiter n’importe quel chiffre fixe comme un seuil de réussite ou d’échec passe à côté de l’intérêt de l’outil, selon son propre créateur.

Lynis, c’est la même chose que CIS-CAT ou OpenSCAP ?

Non. CIS-CAT est le scanner du Center for Internet Security pour ses propres référentiels publiés. OpenSCAP est un standard et un outillage distincts, portés par Red Hat. Lynis est un projet indépendant qui s’appuie sur les référentiels CIS, NIST et divers guides éditeurs comme base documentaire, mais il n’est ni construit ni certifié par aucune de ces organisations.

Ce qu’il faut retenir pour qui gère un serveur Linux

Lynis ne durcira pas un serveur tout seul, et c’est exactement le principe. Un outil qui appliquerait discrètement tous les réglages recommandés finirait par casser quelque chose d’important, sur une machine que personne ne surveillait d’assez près pour s’en rendre compte. Ce qu’il fait réellement, c’est transformer « durcir le serveur » d’une instruction vague en une liste courte, classée, précise, puis s’effacer. Commencez par SSH et Fail2Ban, relancez l’audit à intervalles réguliers, et laissez le score suivre la progression au lieu de la définir. C’est une façon plus honnête de durcir un serveur Linux que de dérouler la checklist de quelqu’un d’autre du haut en bas.