Un audit de vulnérabilité avec Kali Linux permet d’identifier des faiblesses avant qu’elles ne deviennent des portes d’entrée pour un attaquant. Réalisé sur des systèmes dont vous avez l’autorisation, il associe préparation du périmètre, détection de vulnérabilités, analyse des résultats et suivi des corrections.
Greenbone Vulnerability Manager, souvent désigné par l’acronyme GVM, fournit une interface pour examiner un hôte ou un réseau. Pour une petite entreprise fictive comme Atelier Nord, l’enjeu consiste à obtenir des résultats utiles sans perturber les services ni scanner des équipements hors périmètre.
Préparer un audit de vulnérabilité avec Kali Linux
Avant d’installer l’outil, Atelier Nord définit les machines concernées, les horaires autorisés et le contact à prévenir en cas d’incident. Cette préparation évite qu’un scan de ports ou une vérification automatisée touche un réseau voisin ou un service de production sensible.
La configuration réseau de Kali doit aussi être comprise : adresse IP, route, DNS et accès à la machine auditée. Un hôte inaccessible depuis la machine d’audit peut produire un rapport incomplet, même si GVM fonctionne correctement.
Les contrôles préparatoires les plus utiles sont les suivants :
- Autorisation écrite couvrant les adresses, les méthodes et la période du contrôle
- Périmètre précis distinguant les serveurs de test et les systèmes exclus
- Fenêtre de scan adaptée aux contraintes de disponibilité des services
- Point de contact joignable pendant toute l’analyse de sécurité
Pour un premier exercice, une machine de laboratoire isolée réduit les risques et facilite l’interprétation des alertes. Cette étape prépare le choix de l’outil et la vérification de son installation.
Installer GVM sur Kali Linux et vérifier les services
Une fois le périmètre défini, l’installation de GVM met en place le gestionnaire, son interface Web et les composants nécessaires aux tests. Les noms de paquets et versions peuvent évoluer selon la version de Kali ; il faut donc lire les messages du gestionnaire de paquets plutôt que reprendre aveuglément une procédure ancienne.
Mettre à jour les paquets et initialiser Greenbone
Sur une installation Kali à jour, la procédure de base fournie pour ce scénario commence par la mise à jour des dépôts, puis l’installation des dépendances. Les commandes proposées sont sudo apt update && sudo apt dist-upgrade, puis sudo apt install gvm postgresql nsis.
L’initialisation s’effectue ensuite avec sudo gvm-setup. Le script configure notamment la base PostgreSQL, les certificats, les permissions et le compte administrateur ; conservez le mot de passe généré dans un gestionnaire sécurisé, et ne le partagez pas.
Après cette initialisation, contrôlez la configuration avec sudo gvm-check-setup et vérifiez l’état de gvmd avec sudo systemctl status gvmd.service. Selon le résultat, l’interface locale peut être accessible à l’adresse https://127.0.0.1:9392.
Contrôler les versions PostgreSQL et l’accès Web
Si GVM signale que la version PostgreSQL attendue diffère de celle associée au port 5432, ne modifiez pas les fichiers de configuration sans vérifier les clusters réellement installés. Le message d’erreur peut indiquer une incompatibilité de version ; suivez alors les instructions correspondant à la version Kali présente.
Lorsque les services démarrent, vérifiez également que l’interface écoute uniquement sur l’adresse prévue. La rendre accessible à tout le réseau augmente l’exposition : préférez un accès local ou un réseau d’administration protégé, avec filtrage pare-feu et authentification robuste.
Les vérifications de mise en service se résument à ces contrôles :
- État des services gvmd et gsad actifs sans redémarrages répétés
- Configuration GVM validée par gvm-check-setup
- Flux de données téléchargés avant la création du premier scan
- Interface Web limitée aux postes d’administration nécessaires
Une installation fonctionnelle ne garantit pas encore des résultats complets : la fraîcheur des flux et les droits du compte déterminent aussi la qualité du premier test.
Créer une cible et lancer une analyse de sécurité
Après la vérification des services, l’analyse commence dans l’interface GVM par la création d’une cible. Pour Atelier Nord, il peut s’agir d’une seule adresse IP de laboratoire, ce qui permet de contrôler précisément la portée et d’éviter un scan involontaire du réseau entier.
Définir la cible et la tâche de scan
Dans la rubrique « Targets », indiquez un nom explicite et l’adresse autorisée à examiner. Créez ensuite une tâche dans « Tasks », associez-la à cette cible et choisissez une exécution ponctuelle pour ce premier test.
Les profils d’analyse ne produisent pas tous la même charge ni le même niveau de détail. Commencez par un profil adapté à l’objectif, surveillez la machine visée et évitez les tests intrusifs sur un service critique sans accord spécifique.
Le déroulement pratique suit une séquence simple :
- Cible unique avec adresse IP confirmée et autorisée
- Tâche nommée selon l’équipement et la date prévue
- Profil choisi en fonction de la sensibilité du système
- Rapport consulté après la fin effective de l’exécution
Un scan peut nécessiter du temps, notamment lors de la première initialisation des données. Si une tâche échoue à trouver une configuration, vérifiez les droits de création et l’état des flux avant de relancer le contrôle.
Comprendre le rôle de Nmap et de Metasploit
GVM recherche des vulnérabilités à partir de tests et de signatures maintenus dans ses flux. Nmap complète parfois cet examen en cartographiant les ports et services autorisés ; son scan de ports n’établit toutefois pas, à lui seul, qu’une faille est exploitable.
Metasploit relève d’une phase différente : un test d’intrusion peut servir à valider une faiblesse dans un laboratoire contrôlé, mais cette validation exige un mandat explicite et des précautions renforcées. Pour un audit courant, privilégiez d’abord la confirmation non destructive et la vérification des versions concernées.
| Outil | Usage principal | Précaution |
|---|---|---|
| GVM | Détection automatisée de vulnérabilités | Actualiser les flux avant l’analyse |
| Nmap | Repérage des ports et services | Limiter la cible aux adresses autorisées |
| Metasploit | Validation en laboratoire contrôlé | Éviter l’exploitation en production sans mandat dédié |
| Interface GSA | Gestion des cibles, tâches et rapports | Protéger l’accès par réseau et authentification |
Ces outils répondent à des questions différentes ; leur emploi coordonné clarifie les résultats sans confondre détection, inventaire et exploitation.
Interpréter les résultats et construire un rapport d’audit
Une fois le scan terminé, le rapport classe les constats selon leur gravité et leur contexte. Une alerte ne signifie pas toujours qu’un système est compromis : l’auditeur doit vérifier la version, l’exposition du service et les conditions nécessaires à la vulnérabilité.
Trier les alertes selon le risque réel
Pour chaque résultat important, Atelier Nord consigne l’actif touché, l’élément observé et une mesure de correction. Les faux positifs ou les constats incertains sont marqués comme tels, puis comparés à la documentation du fournisseur ou à une vérification manuelle non intrusive.
Le tableau ci-dessous aide à distinguer les étapes d’analyse et les décisions associées. Il ne remplace pas l’évaluation du contexte métier, notamment lorsqu’un service est exposé à Internet ou traite des données sensibles.
| Étape | Question à examiner | Action attendue |
|---|---|---|
| Confirmation | La version ou le service correspond-il au constat ? | Comparer les informations avec l’actif réel |
| Contexte | Le service est-il accessible depuis des zones non fiables ? | Évaluer l’exposition et les protections présentes |
| Priorisation | La faille menace-t-elle une fonction essentielle ? | Classer selon impact, exposition et disponibilité d’un correctif |
| Remédiation | Quelle mesure réduit le risque durablement ? | Appliquer le correctif ou limiter l’exposition |
Suivre les corrections sans perdre la traçabilité
Un rapport d’audit utile relie chaque constat à un responsable, une échéance et une preuve de correction. Après mise à jour ou modification de configuration, un nouveau scan ciblé permet de vérifier si l’alerte a disparu, sans supposer que le risque est réglé.
Lorsque les flux semblent incomplets, consultez les journaux, notamment /var/log/gvm/gvmd.log, et laissez l’initialisation se terminer avant de conclure à un défaut. Cette vérification évite de traiter comme une panne ce qui relève simplement du téléchargement des données.
Pour maintenir un suivi exploitable, conservez ces éléments dans le dossier d’audit :
- Périmètre approuvé et paramètres appliqués à chaque tâche
- Constats vérifiés avec leur contexte et leur niveau de confiance
- Corrections suivies avec responsables et échéances définies
- Résultats de contrôle après application des mesures correctives
La valeur de l’exercice se mesure alors à la réduction documentée du risque, et non au nombre d’alertes affichées par un outil.
