Lynis
Introduction à l'audit de sécurité avec Lynis
Notions théoriques
Lynis est un outil open source dédié à l’audit de sécurité des systèmes Unix/Linux, largement utilisé par les administrateurs système et les experts en cybersécurité.
Lynis analyse la configuration d’un système pour :
- identifier les failles de sécurité,
- identifier les erreurs de configuration
- et proposer des solutions concrètes pour renforcer la protection.
Lynis est comme un "scanner" qui passe votre système au peigne fin pour s’assurer qu’il respecte les standards de sécurité.
Quels sont les usages de Lynis ?
Lynis effectue des tests sur plusieurs composants du système :
- Permissions des fichiers : Vérifie si les fichiers sensibles sont bien protégés.
- Services et ports : Identifie les services inutiles ou vulnérables.
- Mises à jour logicielles : Détecte les paquets obsolètes.
- Configurations réseau : Analyse les règles de pare-feu et les paramètres réseau.
Pourquoi choisir Lynis ?
- Simplicité : Installation et exécution rapides, même pour les débutants.
- Rapports clairs : Les résultats sont organisés en sections (avertissements, suggestions, informations) et stockés dans un fichier consultable.
- Flexibilité : Compatible avec de nombreuses distributions Linux (Debian, Ubuntu, CentOS, etc.).
- Open source : Gratuit, avec un code source disponible sur GitHub, permettant des personnalisations.
- Mises à jour régulières : Une communauté active maintient l’outil à jour face aux nouvelles menaces.
Comment fonctionne un audit ?
Lorsqu’un audit est lancé, Lynis exécute des scripts qui comparent la configuration actuelle aux bonnes pratiques de sécurité.
Par exemple, il vérifie si le mot de passe root est sécurisé ou si des ports inutiles sont ouverts.
À la fin, un rapport détaille les failles et propose des actions correctives, comme modifier des permissions ou désactiver un service.
Pourquoi est-ce utile pour vous ?
En tant que futurs administrateurs ou développeurs, utiliser Lynis permet de comprendre les failles courantes des systèmes et d’apprendre à les sécuriser.
Lynis est un outil pratique pour maintenir des serveurs fiables, que ce soit pour un projet personnel ou une entreprise.
Planifier des audits réguliers de Lynis, avec crontab
par exemple, garantit que le système reste sécurisé au fil du temps.
Ressources pour aller plus loin
- Tutoriel "Auditer Debian 12 avec Lynis"
- YouTube - Tutoriels Lynis
- Documentation officielle de Lynis
- GitHub de Lynis
Exemple pratique
Il est possible d’utiliser Lynis pour auditer un système Debian et analyser les résultats pour améliorer la sécurit é. Voici les étapes détaillées.
-
Installer Git pour récupérer les sources de Lynis depuis GitHub :
sudo apt update
sudo apt install git -
Cloner le dépôt officiel de Lynis depuis https://github.com/CISOfy/lynis :
git clone https://github.com/CISOfy/lynis.git
-
Accéder au répertoire de Lynis :
cd lynis
-
Vérifier la version de Lynis pour s’assurer qu’elle est à jour :
./lynis update info
-
Si une mise à jour est disponible, l’appliquer avec la commande suivante :
./lynis update
-
Modifier les permissions pour sécuriser les fichiers de Lynis :
chown -R root: .
-
Afficher les commandes Lynis utiles :
./lynis --help
-
Lancer un audit complet du système :
sudo ./lynis audit system
-
Consulter le rapport généré dans
/var/log/lynis-report.dat
avecless
pour naviguer plus facilement :sudo less /var/log/lynis-report.dat
astuceVous pouvez utiliser les touches :
-
j
etk
pour naviguer dans le rapport, -
g
pour aller au début etG
pour aller à la fin.
Pour quitter, appuyez sur
q
. -
-
Identifier une suggestion du rapport, et agir en conséquence.
Par exemple, si Lynis affiche, dans son rapport, "No malware scanner found"
Cela indique qu'aucun scanner de malwares n'est détecté sur le système.
Pour résoudre ce problème, Lynis recommande plusieurs outils au choix, tels que :
- rkhunter,
- chkrootkit,
- OSSEC,
- ou Wazuh .
Par exemple, si on choisit rkhunter, voici les actions à réaliser pour suivre la recommandation :
-
Installer rkhunter
Sur un système basé sur Debian/Ubuntu, ouvrir un terminal et exécuter :sudo apt update
sudo apt install rkhunterCela installe rkhunter, un outil spécialisé dans la détection de rootkits, de malwares et d’autres anomalies.
-
Mettre à jour la base de données de rkhunter
Avant de lancer une analyse, mettre à jour la base de signatures de rkhunter pour inclure les dernières définitions de menaces :sudo rkhunter --update
Cette commande télécharge les signatures les plus récentes.
-
Initialiser la base de référence de rkhunter
Configurer une base de référence pour que rkhunter reconnaisse les fichiers légitimes du système :sudo rkhunter --propupd
Cette étape crée une base de données des propriétés des fichiers système pour détecter les modifications ultérieures.
-
Lancer une analyse complète avec rkhunter
Exécuter une analyse pour détecter les rootkits et autres malwares :sudo rkhunter --check --skip-keypress
--check
: Lance l’analyse complète.--skip-keypress
: Évite les pauses interactives pendant l’analyse. Les résultats sont affichés dans le terminal et enregistrés dans/var/log/rkhunter.log
.
-
Consulter le journal d’analyse
Vérifier les résultats de l’analyse pour identifier les alertes ou les fichiers suspects :less /var/log/rkhunter.log
Parcourir le journal pour repérer les avertissements (marqués comme "Warning") et les recommandations.
-
Configurer des analyses automatiques (optionnel)
Pour surveiller le système régulièrement, planifier une analyse automatique via une tâche cron :- Éditer le fichier cron :
sudo crontab -e
- Ajouter une ligne pour exécuter une analyse quotidienne à 3h00, par exemple :
0 3 * * * /usr/bin/rkhunter --check --quiet --skip-keypress --logfile /var/log/rkhunter.log
- Éditer le fichier cron :
- Relancer l’audit pour vérifier l’amélioration du score de sécurité :
sudo ./lynis audit system
Consulter le rapport dans /var/log/lynis-report.dat
pour vérifier que rkhunter est détecté :
less /var/log/lynis-report.dat
Comparer le nouveau rapport avec l’ancien pour noter les progrès.
Test de mémorisation/compréhension
TP pour réfléchir et résoudre des problèmes
Une suggestion de Lynis indique des comptes sans date d'expiration :
Il faut configurer des dates d'expiration pour les comptes utilisateurs root
et sio
pour renforcer la sécurité en s’assurant que les mots de passe expirent périodiquement.
:::
Étape 1 : Accéder au terminal et vérifier les comptes
Ouvrir un terminal sur un système Ubuntu. Vérifier les comptes root
et sio
pour confirmer leur existence et leur statut actuel en exécutant :
sudo getent passwd | grep -E 'root|sio'
Noter si une date d'expiration est mentionnée ou si le champ est vide.
La commande sudo getent passwd | grep -E 'root|sio'
consulte la base de données des utilisateurs et filtre les entrées pour root
et sio
.
Le résultat affiche des lignes comme root:x:0:0:root:/root:/bin/bash
ou sio:x:1001:1001::/home/sio:/bin/bash
.
Si le champ après le UID/GID (souvent vide ou contenant une date) est absent ou indéfini, cela confirme qu’aucune date d’expiration n’est définie.
Cette étape sert de base pour les modifications à venir.
Étape 2 : Définir une date d’expiration pour root
Utiliser la commande chage
pour définir une date d’expiration du mot de passe pour le compte root
à 90 jours à partir d’aujourd’hui (23 juillet 2025, soit 21 octobre 2025) :
sudo chage -E 2025-10-21 root
Vérifier la modification :
sudo chage -l root
La commande sudo chage -E 2025-10-21 root
définit la date d’expiration du mot de passe de root
au 21 octobre 2025,
calculée comme 90 jours après le 23 juillet 2025 (15:47 CEST).
L’option -E
spécifie la date d’expiration. Ensuite, sudo chage -l root
affiche les détails du compte,
y compris la ligne "Account expires" qui doit maintenant indiquer "2025-10-21".
Si la date n’apparaît pas, vérifier la syntaxe ou les privilèges avec sudo
.
Étape 3 : Définir une date d’expiration pour sio
Répéter le processus pour le compte sio
avec la même date d’expiration (21 octobre 2025) :
sudo chage -E 2025-10-21 sio
Vérifier la modification :
sudo chage -l sio
La commande sudo chage -E 2025-10-21 sio
applique la même date d’expiration (21 octobre 2025) au compte sio
. Comme pour root
, sudo chage -l sio
confirme la modification en affichant "Account expires: 2025-10-21" dans la sortie. Si l’utilisateur sio
n’existe pas, créer un compte test avec sudo adduser sio
avant d’appliquer chage
, puis vérifier à nouveau.
Étape 4 : Lancer un audit Lynis initial
Exécuter un audit pour vérifier l’état actuel :
sudo ./lynis audit system
Consulter le rapport pour confirmer la suggestion initiale :
less /var/log/lynis-report.dat
La commande sudo ./lynis audit system
lance un audit complet, générant un rapport dans /var/log/lynis-report.dat
.
Utiliser less /var/log/lynis-report.dat
et rechercher les lignes autour de "AUTH-9282"
pour trouver "Result: found one or more accounts without expire date set" avec les comptes root
et sio
listés.
Cela valide que la suggestion de Lynis est active avant la correction.
Noter le score initial (Hardening index) à la fin du rapport.
Étape 5 : Relancer l’audit après modification
Exécuter un nouvel audit pour vérifier que les comptes ont maintenant des dates d’expiration :
sudo ./lynis audit system
Consulter le nouveau rapport :
less /var/log/lynis-report.dat
Relancer sudo ./lynis audit system
met à jour l’audit après les modifications.
Ouvrir le rapport avec less /var/log/lynis-report.dat
et vérifier la section "AUTH-9282".
Si les dates d’expiration sont correctement définies, la ligne "Result: found one or more accounts without expire date set" devrait disparaître ou indiquer que les comptes sont conformes.
Noter le nouveau score de sécurité (Hardening index) à la fin et comparer avec l’initial pour confirmer une augmentation.
Étape 6 : Documenter les changements
Créer un fichier texte expiration_report.txt
pour résumer les actions :
- Lister les comptes modifiés (
root
,sio
). - Indiquer la nouvelle date d’expiration (21 octobre 2025).
- Noter la différence de score de sécurité avant et après.
Utiliser nano
pour éditer :
nano expiration_report.txt
Enregistrer et quitter après rédaction.
Exécuter nano expiration_report.txt
ouvre l’éditeur.
Rédiger un texte comme :
Comptes modifiés : root, sio
Nouvelle date d'expiration : 2025-10-21
Score de sécurité initial : 65
Score de sécurité final : 68 (amélioration de 3 points)
Enregistrer avec Ctrl+O
, valider avec Entrée
, et quitter avec Ctrl+X
.
Vérifier le contenu avec cat expiration_report.txt
pour s’assurer que toutes les informations sont bien enregistrées.
Étape 7 : Tester un scénario supplémentaire
Ajouter une contrainte supplémentaire : définir une période de validité de 90 jours pour les mots de passe de root
et sio
avec :
sudo chage -M 90 root
sudo chage -M 90 sio
Vérifier avec :
sudo chage -l root
sudo chage -l sio
Les commandes sudo chage -M 90 root
et sudo chage -M 90 sio
définissent une période de validité de 90 jours pour les mots de passe,
forçant leur changement après cette durée. sudo chage -l root
et sudo chage -l sio
affichent les détails,
notamment "Maximum number of days between password change: 90".
Cela ajoute une couche de sécurité en obligeant une rotation régulière des mots de passe, à vérifier lors d’un prochain audit.
Étape 8 : Ré-analyser avec Lynis
Exécuter un audit supplémentaire pour constater l’impact de la période de validité :
sudo ./lynis audit system
Consulter le rapport pour vérifier l’augmentation des points :
less /var/log/lynis-report.dat
Relancer sudo ./lynis audit system
après avoir défini la période de validité de 90 jours
permet de réévaluer le système. Ouvrir le rapport avec less /var/log/lynis-report.dat
et vérifier la section "Hardening index" à la fin.
Comparer ce score avec les précédents : l’ajout d’une politique de renouvellement des mots de passe devrait augmenter légèrement le score (par exemple, de 68 à 70), reflétant une sécurité renforcée.
Noter ce nouveau score pour la documentation.
Étape 9 : Réflexion sur la sécurité
Analyser le rapport final pour identifier une autre suggestion (par exemple, désactiver un service inutilisé).
Proposer une commande corrective et l’ajouter à expiration_report.txt
avec une brève explication.
Exécuter :
nano expiration_report.txt
Ouvrir less /var/log/lynis-report.dat
et chercher une autre suggestion, comme "Disable unused service: telnet" dans la section "[+] Suggestions".
Proposer :
sudo systemctl disable telnet
sudo systemctl stop telnet
Modifier expiration_report.txt
avec nano expiration_report.txt
et ajouter :
Suggestion supplémentaire : Désactiver le service telnet
Action : sudo systemctl disable telnet && sudo systemctl stop telnet
Raison : Telnet est non sécurisé et expose le système à des risques.
Enregistrer et quitter.
Cette action réduit les vecteurs d’attaque en éliminant un service obsolète.