Une infrastructure informatique évolue en permanence. De nouveaux serveurs sont déployés, des applications sont mises à jour, des ports sont ouverts et certaines machines échappent temporairement au processus de patch management. Cette évolution crée progressivement des vulnérabilités, des configurations faibles et des logiciels obsolètes.
Un scanner de vulnérabilités permet d’identifier automatiquement une partie de cette exposition. Parmi les solutions les plus connues, Nessus analyse les systèmes, les services réseau et les configurations afin de détecter les failles de sécurité susceptibles d’affecter une organisation. Lancer un scan ne suffit toutefois pas : il faut comprendre ce que l’outil vérifie, valider ses résultats et intégrer les constats dans un véritable processus de Vulnerability Management.
Qu’est-ce qu’un scanner de vulnérabilités ?
Un scanner de vulnérabilités, ou vulnerability scanner, recherche automatiquement des faiblesses connues sur un ensemble de systèmes. Il compare les informations recueillies sur les cibles avec une base de contrôles régulièrement mise à jour. Il peut notamment identifier des correctifs manquants, des logiciels obsolètes, des services inutilement exposés, des protocoles faibles, des certificats expirés, des comptes par défaut ou des écarts de configuration.
Son objectif principal n’est pas d’exploiter systématiquement les vulnérabilités, mais de détecter les conditions indiquant qu’un système pourrait être affecté. Un scan représente donc une photographie de l’exposition à un instant donné. Sa qualité dépend du périmètre, de la visibilité réseau, des droits accordés au scanner et de la politique utilisée.
À quoi sert Nessus ?
Nessus est un scanner de vulnérabilités développé par Tenable. Il permet d’évaluer des serveurs, postes de travail, équipements réseau, bases de données, services exposés et certaines configurations cloud ou Active Directory. Il peut inventorier les systèmes accessibles, rechercher des vulnérabilités connues, identifier des mises à jour absentes, contrôler des règles de durcissement et confirmer qu’une remédiation a bien été appliquée.
Nessus ne remplace ni l’inventaire des actifs, ni le patch management, ni l’analyse humaine. Il produit des observations techniques qui doivent être vérifiées, contextualisées et transformées en actions.
Scan de vulnérabilités, pentest et audit de sécurité
| Activité | Objectif | Approche | Résultat |
|---|---|---|---|
| Scan de vulnérabilités | Identifier des faiblesses connues | Contrôles automatisés à grande échelle | Constats potentiels ou confirmés |
| Pentest | Démontrer l’exploitabilité et les impacts | Tests manuels et exploitation contrôlée | Preuves et scénarios d’attaque |
| Audit de sécurité | Évaluer le niveau de maîtrise global | Analyse technique, documentaire et organisationnelle | Écarts, risques et plan d’amélioration |
Un scan Nessus peut alimenter un pentest, mais ne constitue pas à lui seul un test d’intrusion. Le pentester cherche à contourner les contrôles et à combiner plusieurs faiblesses pour atteindre un objectif. L’audit possède un périmètre plus large : politiques, responsabilités, sauvegardes, gestion des accès, réponse à incident ou exigences réglementaires.
Comment fonctionne un scan Nessus ?
Définition des cibles et découverte des machines
L’opérateur fournit des adresses IP, plages réseau ou noms DNS dont le périmètre doit être autorisé. Nessus tente ensuite d’identifier les machines actives à l’aide de méthodes comme ARP sur le réseau local, ICMP ou des sondes TCP. Une machine qui ne répond pas au ping n’est pas nécessairement éteinte : un pare-feu peut bloquer l’ICMP alors que plusieurs services restent accessibles. La politique peut donc, selon le contexte, demander de scanner également les hôtes qui ne répondent pas à la découverte.
Découverte des ports et des services
Le scanner recherche les ports TCP ou UDP accessibles. Il peut utiliser un scan SYN, une connexion TCP complète ou un scan UDP, puis essaie d’identifier le service réellement présent : serveur web, SSH, SMB, base de données ou autre protocole. Le numéro de port seul ne suffit pas, car une application HTTPS peut écouter sur 8443 et un service SSH sur un port non standard.
Le choix de la plage influence directement la couverture. La plage default de Nessus examine
plusieurs milliers de ports courants ; un scan complet peut contrôler les 65 536 ports. Cette couverture
augmente cependant la durée et la charge réseau. Le scan UDP est également plus lent et son résultat
plus difficile à interpréter en raison de l’absence fréquente de réponse du protocole.
Le rôle des plugins Nessus
Les plugins Nessus sont les unités de contrôle exécutées par le moteur. Écrits en NASL, ils contiennent une logique de détection, des informations sur la faiblesse recherchée, des références et une proposition générique de remédiation. Ils sont regroupés par familles : Windows, distributions Linux, bases de données, équipements réseau, services web ou contrôles de conformité.
Certains plugins analysent une bannière ou une version distante. D’autres envoient une requête spécifique et examinent la réponse. Les contrôles locaux utilisent les informations obtenues après authentification : paquets installés, registre Windows, correctifs, fichiers ou paramètres système. Le flux de plugins doit rester à jour pour détecter les vulnérabilités récemment publiées.
Vulnérabilités, mauvaises configurations et logiciels obsolètes
Une détection peut reposer sur une version vulnérable, l’absence d’un correctif, une option dangereuse ou un comportement observable. Nessus peut ainsi signaler un serveur non mis à jour, TLS 1.0 encore actif, une suite cryptographique faible, un partage accessible ou une règle de durcissement non respectée. La preuve fournie dans la sortie du plugin est essentielle pour comprendre comment le résultat a été établi.
Scans authentifiés et non authentifiés
Scan non authentifié
Un scan non authentifié observe la cible depuis le réseau. Il détecte les ports exposés, certaines versions, les protocoles faibles et les vulnérabilités testables à distance. Cette approche mesure bien la surface d’attaque visible depuis le point de scan, mais reste limitée lorsque les versions sont masquées ou que les correctifs ne peuvent pas être déduits à distance.
Scan authentifié
Lors d’un scan authentifié, Nessus se connecte avec un compte autorisé, par exemple via SSH sous Linux ou les mécanismes d’administration Windows. Il peut examiner directement les paquets, correctifs, versions de bibliothèques, fichiers et paramètres locaux. Cette méthode offre généralement une meilleure couverture et réduit la dépendance aux bannières réseau.
Les comptes doivent être dédiés, protégés et surveillés. Le rapport doit confirmer que l’authentification a réussi : un scan configuré avec des identifiants peut fonctionner comme un simple scan distant si le compte est refusé ou insuffisamment privilégié.
CVE, CVSS, criticité et niveau de risque
Une CVE, ou Common Vulnerabilities and Exposures, est un identifiant attribué à une vulnérabilité divulguée publiquement. Elle relie le résultat du scanner aux avis des éditeurs et aux référentiels de sécurité. Le CVSS décrit sa sévérité technique sur une échelle de 0 à 10.
| Score CVSS | Sévérité |
|---|---|
| 0,0 | Aucune |
| 0,1 à 3,9 | Faible |
| 4,0 à 6,9 | Moyenne |
| 7,0 à 8,9 | Élevée |
| 9,0 à 10,0 | Critique |
CVSS prend notamment en compte le vecteur d’attaque, les privilèges requis, l’interaction utilisateur et les impacts sur la confidentialité, l’intégrité et la disponibilité. Il ne constitue pourtant pas un niveau de risque métier complet. L’exposition, l’existence d’un exploit, la criticité de l’actif, les données traitées et les contrôles compensatoires doivent compléter le score.
Quels types de scans utiliser ?
Nessus propose notamment la découverte d’hôtes, le scan réseau, l’audit authentifié des correctifs, le scan externe ou interne, l’audit de conformité, l’inventaire SSL/TLS, les contrôles ciblés sur une CVE, l’audit Active Directory et, selon l’édition, les scans applicatifs ou par agent. Le modèle doit répondre à l’objectif : une découverte rapide n’offre pas la profondeur d’un audit authentifié.
Pourquoi la politique de scan est-elle déterminante ?
Une politique définit les méthodes de découverte, ports, identifiants, plugins, délais d’attente, niveau de parallélisme et options de sécurité. Trop restrictive, elle ignore des services ; trop agressive, elle peut saturer un lien ou perturber un équipement ancien. Les politiques doivent être testées sur un petit périmètre, documentées et adaptées aux types d’actifs. Les contrôles potentiellement intrusifs, notamment certains tests de déni de service, exigent une attention particulière.
Gérer les faux positifs
Un faux positif peut provenir d’une bannière incorrecte, d’un correctif rétroporté sans changement du numéro de version, d’une détection partielle ou d’une authentification incomplète. L’analyste examine la sortie du plugin, sa méthode de détection et l’avis de l’éditeur, puis vérifie le paquet, le patch ou la configuration effective.
Une exception ne doit jamais être masquée sans justification. Elle doit avoir un propriétaire, une preuve, une date d’expiration et une réévaluation. Les règles de plugins peuvent modifier la présentation du rapport, mais elles ne suppriment pas l’exécution du contrôle.
Exemple d’analyse avec Nessus
Une PME exploite 80 postes, 15 serveurs et plusieurs applications internes. Elle évalue son exposition après l’intégration d’un ancien serveur de gestion documentaire.
1. Découverte des machines
Le scan identifie 92 systèmes actifs, dont le serveur 10.20.5.17, absent de l’inventaire.
Les ports 22, 443 et 8443 sont accessibles. Cet écart entre l’inventaire théorique et la réalité constitue
déjà un risque à traiter.
2. Lancement d’un scan authentifié
Un compte SSH dédié permet à Nessus d’énumérer le système, les paquets et les correctifs installés. Le rapport confirme explicitement que l’authentification a réussi.
3. Identification d’une vulnérabilité critique
La sortie du plugin associe un composant web vulnérable à la CVE fictive CVE-20XX-12345 et
indique un risque d’exécution de code à distance.
4. Analyse de la CVE et du score CVSS
Le vecteur montre une attaque réalisable depuis le réseau, sans privilège ni interaction utilisateur, avec un impact élevé. Le score justifie une analyse immédiate, mais l’analyste ne s’y arrête pas : il recherche un exploit public, l’exposition réelle du port et la fonction métier du serveur.
5. Vérification du résultat
L’analyste examine la preuve, consulte l’avis de l’éditeur et confirme localement la version. Il vérifie qu’aucun correctif rétroporté n’est présent et que le port 8443 est accessible depuis les segments utilisateurs. Le constat est confirmé.
6. Priorisation de la correction
L’exploitation distante, l’absence d’authentification, les documents sensibles et l’existence d’un exploit augmentent le risque. Cette vulnérabilité passe avant une autre CVSS 9.8 située sur une machine de test isolée et arrêtée par défaut. La priorité traduit le risque réel, pas uniquement la couleur du rapport.
7. Patch ou mitigation
L’équipe sauvegarde la configuration, teste la mise à jour puis applique le patch. Si cela avait été impossible immédiatement, elle aurait pu désactiver le composant, filtrer le port ou limiter l’accès à un segment d’administration comme mesure temporaire.
8. Nouveau scan de confirmation
Après maintenance, le contrôle ciblé ne remonte plus et la version corrigée est détectée. L’équipe vérifie le fonctionnement du service et conserve les preuves du constat, du changement et du scan de validation. Une vulnérabilité ne doit être clôturée qu’après cette confirmation.
Intégrer Nessus au Vulnerability Management
La gestion des vulnérabilités forme une boucle continue : inventorier et classifier les actifs, scanner, valider les résultats, prioriser, attribuer les corrections, appliquer les patches ou mitigations, puis contrôler la remédiation. La fréquence doit suivre la criticité des actifs et les changements importants, pas uniquement un calendrier mensuel.
La priorité combine CVSS, exposition réseau, criticité métier, exploitabilité, menace active et protections existantes. Le catalogue Known Exploited Vulnerabilities de la CISA aide notamment à identifier les CVE exploitées dans des attaques réelles.
Bonnes pratiques pour les scans Nessus
- Maintenir Nessus et son flux de plugins à jour.
- Définir précisément les cibles et obtenir l’autorisation de scan.
- Utiliser des comptes dédiés et contrôler la réussite de l’authentification.
- Tester les politiques avant leur déploiement en production.
- Adapter la fréquence à la criticité et à l’exposition des actifs.
- Protéger les rapports, qui décrivent les faiblesses de l’infrastructure.
- Documenter les faux positifs et acceptations de risque.
- Confirmer chaque correction par un nouveau scan.
Avantages et limites de Nessus
Nessus automatise de nombreux contrôles, offre une couverture étendue et fournit des résultats détaillés et reproductibles. Les scans authentifiés sont particulièrement utiles pour identifier les correctifs absents et les configurations locales.
Il ne détecte cependant pas toutes les vulnérabilités, dépend de la visibilité et des privilèges obtenus, et comprend difficilement le contexte métier. Il ne reproduit pas la créativité d’un attaquant et ne remplace ni un pentest ni un audit complet. Un scan mal configuré peut enfin être incomplet ou perturbateur.
Conclusion
Nessus apporte une visibilité structurée sur les vulnérabilités, correctifs manquants et mauvaises configurations d’une infrastructure. Sa valeur ne se mesure pas au nombre de résultats produits, mais à la capacité de l’organisation à les valider, les prioriser et les corriger durablement.
Correctement configuré et intégré au Vulnerability Management, il aide les équipes IT à passer d’une accumulation de failles à un processus mesurable : connaître les actifs, réduire l’exposition et vérifier que chaque remédiation est réellement efficace.
Structurer votre gestion des vulnérabilités
Découvrez mes compétences en gestion des vulnérabilités et le Cyber Security Assessment pour inventorier l’exposition, valider les constats et construire une feuille de route de remédiation priorisée.
Échanger sur vos vulnérabilités
Nessus : comprendre le fonctionnement d’un scanner de vulnérabilités