nessus-vulnerability-scanning-lab

Gestion des vulnérabilités en entreprise sur Azure — Scanner Nessus déployé via Terraform, analyse avec informations d'identification, correction de CVE-2013-3900 avec re-vérification par scan.

Cette augmentation du nombre de résultats constitue l'argument complet en faveur de l'analyse authentifiée — la vulnérabilité de sévérité Élevée CVE-2013-3900 que j'ai corrigée dans ce laboratoire est un contrôle local que l'analyse non authentifiée ne pouvait pas du tout voir.

Architecture

Appliance scanner dédiée NESSUS01 sur Subnet-Serveurs avec des chemins d'analyse authentifiée vers les trois cibles Windows. Le plan de gestion accessible uniquement via tunnel SSH depuis le poste de travail administrateur — le port 8834 n'est jamais exposé publiquement.

Le scanner rejoint le VNet de laboratoire existant de ma série Enterprise Azure Infrastructure Automation series, déployé en tant que configuration Terraform indépendante avec son propre état distant.

Décisions de conception que j'ai prises :

• Machine virtuelle scanner dédiée au lieu d'installer Nessus sur une cible. Les scanners d'entreprise sont placés comme des appliances réseau indépendantes avec une ligne de vue dégagée vers leurs cibles — scanner depuis un hôte qui est également une cible contamine les résultats.
• Sources de données Terraform contre l'infrastructure existante. La configuration du scanner référence le VNet et le sous-réseau existants via des blocs data plutôt que de les dupliquer, avec un état isolé dans sa propre clé nessus-scanner.tfstate afin que le scanner puisse être créé et détruit sans toucher à l'état du laboratoire principal.
• L'interface web de Nessus (port 8834) n'est jamais exposée publiquement. Le NSG autorise uniquement SSH (22) depuis mon IP administrateur ; j'accède à l'interface via un tunnel SSH (ssh -L 8834:localhost:8834). L'exposition du plan de gestion est la principale raison pour laquelle les appliances scanner sont compromises.
• Authentification par clé SSH uniquement — paire de clés ed25519, pas d'authentification par mot de passe sur le scanner.

Phase 0 — Revue de Sécurité Pré-déploiement (Pratiquez Ce Que Vous Scannez)

Avant de déployer quoi que ce soit, j'ai audité les règles NSG existantes — et j'ai trouvé exactement le genre de mauvaise configuration que ce laboratoire existe pour détecter : la règle RDP autorisait la source * (n'importe quelle IP sur Internet).

Audit pré-déploiement : la requête az network nsg list expose Allow-RDP-3389 ouvert à n'importe quelle source (*).

Je l'ai resserrée à mon IP publique actuelle avant de procéder :

La même règle après correction — source restreinte à une seule IP administrateur.

Trouver et corriger une exposition dans votre propre environnement avant d'y pointer un scanner est le changement d'état d'esprit entre « exécuter un outil » et « faire de la sécurité ».

Phase 1 — Déployer le Scanner avec Terraform

Cinq ressources — IP publique, NSG, NIC, association NSG et la VM Ubuntu — déployées en moins de deux minutes :

terraform apply : 5 ajoutés, 0 modifiés, 0 détruits. Les sorties incluent la commande SSH prête à l'emploi.

Je me suis ensuite connecté via SSH et effectué l'installation sans tête de Nessus Essentials 10.12.1 :

Première connexion SSH à NESSUS01 avec authentification par clé — Ubuntu 24.04 opérationnel à 10.0.1.8, prêt pour l'installation sans tête de Nessus.

Phase 2 — Analyse de Référence Non Authentifiée

Première analyse : aucune identification — c'est ce qu'un attaquant sur le segment réseau voit.

Analyse réseau de base ciblant les trois hôtes : 10.0.1.5, 10.0.1.6, 10.0.1.7.

Résultats de référence : 35 résultats sur 3 hôtes, colonne Auth affichant Échec — Nessus n'a pas pu se connecter, donc chaque résultat provient uniquement de l'observation externe.

Phase 3 — Analyse Authentifiée

L'analyse authentifiée est la norme d'entreprise pour la gestion interne des vulnérabilités. J'ai préparé les cibles Windows en activant le service Registre à distance et en ouvrant les groupes de règles de pare-feu requis sur le profil Domaine :

Préparation de la cible sur FS01 — RemoteRegistry en cours d'exécution avec démarrage automatique, règles WMI et Partage de fichiers et d'imprimantes activées pour le profil Domaine.

J'ai configuré les identifiants Windows dans l'analyse avec les options de sécurité que les entreprises exigent : ne jamais envoyer d'identifiants en clair et NTLMv2 uniquement.

Configuration des identifiants Windows — domaine LAB, NTLMv1 désactivé, transmission d'identifiants en clair désactivée, Registre à distance activé pour l'analyse.

Résultats authentifiés : 64 résultats — une augmentation de 83 % par rapport à la référence non authentifiée sur les mêmes trois hôtes.

Résultats triés par sévérité, avec le contrôle local de validation de signature WinVerifyTrust de sévérité Élevée désormais visible — un résultat que l'analyse non authentifiée n'avait aucun moyen de détecter.

Phase 4 — Analyser la Vulnérabilité Élevée : CVE-2013-3900

Le plugin #166555 a signalé Validation de signature WinVerifyTrust (CVE-2013-3900) sur DC01 et FS01 — score de base CVSS v3 8.8, Tenable VPR 9.0. La valeur de registre EnableCertPaddingCheck était absente, laissant les hôtes dans un état où un attaquant pouvait ajouter un contenu malveillant à un exécutable signé sans invalider sa signature Authenticode.

Analyse complète du résultat : la sortie du plugin confirme que la valeur de registre est absente sur 10.0.1.5 et 10.0.1.6, avec le chemin de correction exact documenté dans la section Solution.

Pourquoi ce résultat est important : il s'agit d'une vulnérabilité d'atténuation par configuration — aucun correctif n'existe car Microsoft a rendu la correction optionnelle. Elle était absente sur les images fraîches de Windows Server 2025 en 2026, treize ans après la publication du CVE. C'est exactement le type de problème que seules l'analyse authentifiée et la gestion de la configuration peuvent détecter.

Phase 5 — Corriger et Vérifier

J'ai appliqué la correction sur les hôtes affectés conformément à la section Solution du plugin — en définissant EnableCertPaddingCheck = 1 aux deux chemins de registre 64 bits et Wow6432Node — puis j'ai vérifié les deux clés avant de relancer l'analyse :

Correction appliquée et vérifiée avec Get-ItemProperty — les deux chemins de registre renvoient désormais EnableCertPaddingCheck : 1.

Puis l'étape que la plupart des gens sautent — la nouvelle analyse de vérification. Vous ne fermez pas le ticket tant que le scanner n'a pas confirmé la disparition du résultat :

Analyse de vérification (Historique : 2) : le résultat de sévérité Élevée CVE-2013-3900 est résolu. La plus haute sévérité restante est Moyenne.

Analyser → corriger → vérifier. Boucle fermée.

Compétences Démontrées

Pourquoi C'est Important pour le Poste

La gestion des vulnérabilités est une fonction centrale dans pratiquement tous les rôles en opérations de sécurité, sécurité cloud et GRC. Ce laboratoire couvre l'ensemble du travail — pas seulement exécuter un scanner, mais architecturer son placement de manière sécurisée, préparer correctement les cibles, distinguer le signal du bruit dans les résultats, exécuter une correction et prouver qu'elle a fonctionné. La comparaison entre analyse non authentifiée et authentifiée ainsi que la nouvelle analyse de vérification sont les deux choses qui distinguent les praticiens des opérateurs d'outils.

Rapport d'Évaluation

Le livrable professionnel complet — résumé exécutif, méthodologie, analyse détaillée du résultat CVE-2013-3900, classification des risques résiduels et recommandations priorisées — est disponible en PDF :

Vulnerability-Assessment-Report.pdf

Nessus Essentials n'inclut pas l'exportation de rapports, ce livrable a donc été rédigé indépendamment à partir des données d'analyse — ce qui constitue en soi la compétence en rédaction de rapports que la version gratuite ne fournit pas.

Laboratoires Connexes

Ce scanner se déploie dans l'environnement construit par ma série Enterprise Azure Infrastructure Automation series :

• Lab 1 — Infrastructure Terraform
• Lab 2 — Active Directory
• Lab 3 — Serveur de fichiers NTFS et RBAC
• Labs 4–6 — Azure RBAC

Aucun secret n'est stocké dans ce dépôt — le scanner utilise uniquement l'authentification par clé SSH, et les identifiants d'analyse ont été saisis directement dans la console Nessus, jamais commités dans le code.