Nessus Vulnerability Scanning Lab — Azure

Intero ciclo di vita della gestione delle vulnerabilità — scansiona, trova, correggi, verifica — eseguito nel mio ambiente lab Azure Active Directory utilizzando uno scanner Nessus dedicato, distribuito con Terraform.

Cosa Dimostra Questo Lab

Ho distribuito una VM scanner Ubuntu 24.04 dedicata nel mio ambiente lab Azure AD esistente, ho eseguito una scansione di base non autenticata e una scansione con credenziali contro un domain controller, un file server e un client aggiunto al dominio, ho analizzato i risultati, ho risolto un finding di gravità Alta (CVE-2013-3900) tramite hardening del registro di PowerShell, e ho verificato la correzione con una nuova scansione. Questo è il flusso di lavoro completo che i programmi enterprise di gestione delle vulnerabilità eseguono in modo continuo.

	Baseline non autenticata	Scansione con credenziali
Findings	35	64
Visibilità	Solo superficie d'attacco esterna — la prospettiva dell'attaccante	All'interno del sistema operativo — livelli di patch, configurazione del registro, controlli locali
Autenticazione	Fail (tutti e 3 gli host)	Credenziali Windows via NTLMv2, mai inviate in chiaro
Tempo di scansione	15 minuti	23 minuti

Questo balzo nei findings è l'intero argomento a favore della scansione con credenziali — il finding di gravità Alta CVE-2013-3900 che ho risolto in questo lab è un controllo locale che la scansione non autenticata non poteva assolutamente vedere.

Architettura

Architecture diagram Appliance scanner dedicato NESSUS01 su Subnet-Servers con percorsi di scansione con credenziali verso tutti e tre i target Windows. Il piano di gestione è raggiungibile solo tramite tunnel SSH dalla workstation amministrativa — la porta 8834 non è mai esposta pubblicamente.

Lo scanner si unisce alla VNet lab esistente della mia serie Enterprise Azure Infrastructure Automation, distribuito come configurazione Terraform indipendente con il proprio remote state.

Host	Ruolo	OS	IP privato
NESSUS01	Scanner di vulnerabilità	Ubuntu 24.04 LTS	10.0.1.8
DC01	Domain controller (lab.local)	Windows Server 2025	10.0.1.5
FS01	File server	Windows Server 2025	10.0.1.6
CLIENT01	Workstation aggiunto al dominio	Windows 11 Pro	10.0.1.7

Decisioni progettuali che ho preso:

VM scanner dedicata invece di installare Nessus su un target. Gli scanner enterprise vengono posizionati come appliance di rete indipendenti con linea di vista libera verso i loro target — scansionare da un host che è anche lui un target contamina i risultati.
Data source Terraform contro l'infrastruttura esistente. La configurazione dello scanner fa riferimento alla VNet e alla subnet esistenti tramite blocchi data invece di duplicarli, con lo state isolato nella propria chiave nessus-scanner.tfstate così lo scanner può essere creato e distrutto senza toccare lo state del lab principale.
La UI web di Nessus (porta 8834) non è mai esposta pubblicamente. L'NSG consente solo SSH (22) dal mio IP amministrativo; raggiungo la UI tramite un tunnel SSH (ssh -L 8834:localhost:8834). L'esposizione del piano di gestione è il primo motivo per cui le appliance scanner vengono compromesse.
Solo autenticazione con chiave SSH — coppia di chiavi ed25519, nessuna autenticazione con password sullo scanner.

Fase 0 — Revisione di Sicurezza Pre-Flight (Pratica Ciò Che Scansiona)

Prima di distribuire qualsiasi cosa, ho verificato le regole NSG esistenti — e ho trovato esattamente il tipo di misconfigurazione che questo lab esiste per intercettare: la regola RDP consentiva source * (qualsiasi IP su internet).

NSG before hardening Verifica pre-flight: la query az network nsg list rivela Allow-RDP-3389 aperta a qualsiasi origine (*).

L'ho ristretta al mio IP pubblico attuale prima di procedere:

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

NSG after hardening La stessa regola dopo la correzione — origine limitata a un singolo IP amministrativo.

Trovare e correggere un'esposizione nel proprio ambiente prima di puntare uno scanner è il cambio di mentalità dal "usare uno strumento" al "fare sicurezza."

Fase 1 — Distribuire lo Scanner con Terraform

Cinque risorse — IP pubblico, NSG, NIC, associazione NSG e la VM Ubuntu — distribuite in meno di due minuti:

terraform apply: 5 aggiunte, 0 modificate, 0 distrutte. Gli output includono il comando SSH pronto all'uso.

Poi mi sono connesso via SSH e ho eseguito l'installazione headless di Nessus Essentials 10.12.1:

Scanner SSH session Prima connessione SSH a NESSUS01 con autenticazione basata su chiave — Ubuntu 24.04 attivo su 10.0.1.8, pronto per l'installazione headless di Nessus.

Fase 2 — Scansione di Base Non Autenticata

Prima scansione: nessuna credenziale — questo è ciò che un attaccante sul segmento di rete vede.

Basic scan configuration Scansione di rete di base che targettizza tutti e tre gli host: 10.0.1.5, 10.0.1.6, 10.0.1.7.

Basic scan results Risultati della baseline: 35 findings su 3 host, colonna Auth su Fail — Nessus non ha potuto effettuare il login, quindi ogni risultato deriva solo da osservazione esterna.

Fase 3 — Scansione con Credenziali

La scansione con credenziali è lo standard enterprise per la gestione interna delle vulnerabilità. Ho preparato i target Windows abilitando il servizio Remote Registry e aprendo i gruppi di regole firewall richiesti sul profilo Domain:

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

Remote Registry preparation Preparazione del target su FS01 — RemoteRegistry in esecuzione con avvio Automatic, regole WMI e File & Printer Sharing abilitate per il profilo Domain.

nessus-vulnerability-scanning-lab

Più Popolari