Vous lancez un audit avant une mise en production et Lynis remonte une longue liste d’avertissements. Le score attire l’œil, mais appliquer chaque suggestion dans l’ordre peut casser un accès SSH, un service métier ou une sauvegarde.
Sur un serveur Debian, Ubuntu ou Rocky de test, Lynis aide à repérer des réglages à contrôler. Le bon usage consiste à lire le test, relier la recommandation au rôle du serveur, puis corriger un point mesurable à la fois.
Préparer l’audit sur un périmètre connu
Installez Lynis depuis les dépôts de votre distribution lorsque le paquet est disponible. Sur Debian ou Ubuntu, l’installation utilise APT. Sur Rocky Linux ou RHEL, le nom et la disponibilité du paquet peuvent dépendre des dépôts activés.
sudo apt update
sudo apt install lynis
lynis show versionAvant l’audit, conservez la configuration des services qui exposent le serveur, en particulier SSH, le pare-feu et les sauvegardes. Un instantané de VM ou une copie versionnée de /etc simplifie le retour arrière si une recommandation modifie un comportement attendu.
Faites aussi l’inventaire du rôle de la machine. Un hôte web, un serveur de sauvegarde et une VM de laboratoire n’acceptent pas les mêmes restrictions. Le score Lynis ne connaît ni vos flux applicatifs ni votre politique interne.
Lire le rapport Lynis sans suivre chaque suggestion
Lancez l’audit complet avec les privilèges nécessaires. Lynis écrit ses résultats dans son journal et son rapport, généralement sous /var/log/lynis.log et /var/log/lynis-report.dat.
sudo lynis audit system
sudo less /var/log/lynis.log
sudo grep '^suggestion=' /var/log/lynis-report.datChaque suggestion doit passer par trois questions : quel test l’a produite, quel fichier ou service serait modifié, et quel contrôle prouvera que le serveur fonctionne encore après le changement ? Ce tri évite de confondre une bonne pratique générale avec une exigence adaptée à votre machine.
- Une alerte liée à SSH concerne l’accès d’administration. Gardez une seconde connexion ouverte avant toute modification de
sshd_config. - Une recommandation sur les permissions vise un chemin précis. Vérifiez le propriétaire et le service qui l’utilise avant un
chmod. - Une suggestion de noyau ou de module demande une fenêtre de maintenance, car le redémarrage peut être nécessaire.
La documentation de Lynis explique les commandes, les profils et les fichiers de rapport. Elle sert à comprendre le test remonté, pas à imposer une configuration identique sur tous les serveurs.
Corriger un réglage puis relancer le contrôle
Choisissez une recommandation à faible impact et documentez l’état initial. Par exemple, avant de réduire les permissions d’un fichier, relevez son propriétaire, son groupe et les processus qui l’ouvrent.
sudo stat /chemin/vers/le/fichier
sudo lsof /chemin/vers/le/fichier
sudo systemctl status nom-du-service --no-pagerAppliquez ensuite la correction retenue, testez le service, puis relancez Lynis. Le rapport doit montrer la disparition ou l’évolution du test concerné. Si le service échoue, restaurez la configuration sauvegardée au lieu d’ajouter un second changement pour contourner le premier.
sudo systemctl restart nom-du-service
sudo systemctl status nom-du-service --no-pager
sudo lynis audit systemUtiliser le score comme repère, pas comme objectif
Un score plus élevé signale souvent des contrôles supplémentaires, mais il ne prouve pas qu’un serveur est adapté à sa charge ou protégé contre chaque risque. Une règle appliquée sans connaître l’application peut améliorer le score et interrompre un flux nécessaire.
Je commencerais par les résultats qui correspondent à un service réellement exposé, puis je vérifierais chaque changement dans le journal et avec le service concerné. Cette méthode prend plus de temps qu’une série de commandes copiées, mais elle laisse un système dont vous connaissez les compromis.
Gardez le rapport avant et après l’intervention. Il devient utile lors d’une prochaine mise à jour ou quand un autre administrateur doit comprendre pourquoi un réglage a été choisi.