Laboratoire d'Analyse des Vulnérabilités Nessus — Azure

Cycle de vie complet de la gestion des vulnérabilités — analyser, trouver, corriger, vérifier — exécuté sur mon environnement de laboratoire Azure Active Directory en direct à l'aide d'un scanner Nessus dédié déployé avec Terraform.

Ce que démontre ce laboratoire

J'ai déployé une machine virtuelle scanner Ubuntu 24.04 dédiée dans mon environnement de laboratoire Azure AD existant, réalisé une analyse de référence non authentifiée et une analyse authentifiée contre un contrôleur de domaine, un serveur de fichiers et un client joint au domaine. J'ai analysé les résultats, corrigé une vulnérabilité de sévérité Élevée (CVE-2013-3900) via un renforcement de registre PowerShell, et vérifié la correction avec une nouvelle analyse. C'est le workflow complet que les programmes de gestion des vulnérabilités en entreprise exécutent en continu.

	Analyse de référence non authentifiée	Analyse authentifiée
Résultats	35	64
Visibilité	Surface d'attaque externe uniquement — le point de vue de l'attaquant	À l'intérieur du système d'exploitation — niveaux de correctifs, configuration du registre, contrôles locaux
Authentification	Échec (3 hôtes)	Identifiants Windows via NTLMv2, jamais envoyés en clair
Durée d'analyse	15 minutes	23 minutes

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

Diagramme d'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.

Hôte	Rôle	OS	IP privée
NESSUS01	Scanner de vulnérabilités	Ubuntu 24.04 LTS	10.0.1.8
DC01	Contrôleur de domaine (lab.local)	Windows Server 2025	10.0.1.5
FS01	Serveur de fichiers	Windows Server 2025	10.0.1.6
CLIENT01	Poste de travail joint au domaine	Windows 11 Pro	10.0.1.7

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).

NSG avant durcissement 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 :

az network nsg rule update -g RG-FileServerLab --nsg-name NSG-RDP \
  -n Allow-RDP-3389 --source-address-prefixes $(curl -s ifconfig.me)

NSG après durcissement 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 :

Session SSH du scanner 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.

Configuration de l'analyse de base 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 l'analyse de base 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 :

Set-Service -Name RemoteRegistry -StartupType Automatic
Start-Service RemoteRegistry
Set-NetFirewallRule -DisplayGroup "File and Printer Sharing" -Enabled True -Profile Domain
Set-NetFirewallRule -DisplayGroup "Windows Management Instrumentation (WMI)" -Enabled True -Profile Domain

nessus-vulnerability-scanning-lab

Populaires