Nessus-Schwachstellenscan-Lab — Azure

Vollständiger Lebenszyklus des Schwachstellenmanagements — scannen, finden, beheben, verifizieren — durchgeführt in meiner Live-Azure-AD-Lab-Umgebung mit einem dedizierten, per Terraform bereitgestellten Nessus-Scanner.

Was dieses Lab demonstriert

Ich habe eine dedizierte Ubuntu-24.04-Scanner-VM in meiner bestehenden Azure-AD-Lab-Umgebung bereitgestellt, einen nicht authentifizierten Basisscan und einen Scan mit Anmeldedaten gegen einen Domänencontroller, einen Dateiserver und einen in die Domäne eingebundenen Client ausgeführt, die Ergebnisse analysiert, einen Befund mit hohem Schweregrad (CVE-2013-3900) durch Härtung der Registry per PowerShell behoben und den Fix mit einem erneuten Scan verifiziert. Dies ist der vollständige Workflow, den Unternehmensprogramme für Schwachstellenmanagement kontinuierlich ausführen.

	Nicht authentifizierter Basisscan	Scan mit Anmeldedaten
Befunde	35	64
Sichtbarkeit	Nur externe Angriffsfläche — die Sicht des Angreifers	Im Inneren des Betriebssystems — Patchstände, Registry-Konfiguration, lokale Prüfungen
Authentifizierung	Fehlgeschlagen (alle 3 Hosts)	Windows-Anmeldedaten über NTLMv2, niemals im Klartext übertragen
Scanzeit	15 Minuten	23 Minuten

Dieser Sprung bei den Befunden ist das gesamte Argument für das Scannen mit Anmeldedaten — der in diesem Lab behobene Befund CVE-2013-3900 mit hohem Schweregrad ist eine lokale Prüfung, die der nicht authentifizierte Scan überhaupt nicht sehen konnte.

Architektur

Architekturdiagramm Dedizierte NESSUS01-Scanner-Appliance auf Subnet-Servers mit authentifizierten Scan-Pfaden zu allen drei Windows-Zielen. Die Verwaltungsebene ist nur über einen SSH-Tunnel von der Admin-Workstation aus erreichbar — Port 8834 ist niemals öffentlich exponiert.

Der Scanner wird in das bestehende Lab-VNet aus meiner Enterprise Azure Infrastructure Automation-Reihe eingebunden und als unabhängige Terraform-Konfiguration mit eigenem Remote-State bereitgestellt.

Host	Rolle	Betriebssystem	Private IP
NESSUS01	Schwachstellen-Scanner	Ubuntu 24.04 LTS	10.0.1.8
DC01	Domänencontroller (lab.local)	Windows Server 2025	10.0.1.5
FS01	Dateiserver	Windows Server 2025	10.0.1.6
CLIENT01	In die Domäne eingebundene Workstation	Windows 11 Pro	10.0.1.7

Design-Entscheidungen, die ich getroffen habe:

Dedizierte Scanner-VM statt Installation von Nessus auf einem Ziel. Unternehmens-Scanner werden als unabhängige Netzwerkappliances mit ungehinderter Sichtlinie zu ihren Zielen platziert — das Scannen von einem Host, der selbst ein Ziel ist, verfälscht die Ergebnisse.
Terraform-Datenquellen gegen die bestehende Infrastruktur. Die Scanner-Konfiguration referenziert das bestehende VNet und Subnetz über data-Blöcke, anstatt sie zu duplizieren. Der State ist in einem eigenen nessus-scanner.tfstate-Schlüssel isoliert, sodass der Scanner erstellt und zerstört werden kann, ohne den Kern-Lab-State zu berühren.
Die Nessus-Web-UI (Port 8834) ist niemals öffentlich exponiert. Die NSG erlaubt nur SSH (22) von meiner Admin-IP; ich erreiche die UI über einen SSH-Tunnel (ssh -L 8834:localhost:8834). Die Exponierung der Verwaltungsebene ist der häufigste Weg, auf dem Scanner-Appliances kompromittiert werden.
Nur SSH-Schlüsselauthentifizierung — ed25519-Schlüsselpaar, keine Passwort-Authentifizierung auf dem Scanner.

Phase 0 — Sicherheitsüberprüfung vor dem Start (Übe, was du scannst)

Bevor ich etwas bereitgestellt habe, habe ich die bestehenden NSG-Regeln geprüft — und genau die Art von Fehlkonfiguration gefunden, die dieses Lab aufdecken soll: Die RDP-Regel erlaubte Quelle * (beliebige IP im Internet).

NSG vor der Härtung Überprüfung vor dem Start: Die Abfrage az network nsg list deckt auf, dass Allow-RDP-3389 für jede Quelle (*) offen ist.

Ich habe sie vor dem Fortfahren auf meine aktuelle öffentliche IP eingeschränkt:

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

NSG nach der Härtung Dieselbe Regel nach der Behebung — Quelle auf eine einzelne Admin-IP eingeschränkt.

Eine Exposition in der eigenen Umgebung zu finden und zu beheben, bevor man einen Scanner darauf richtet, ist der Denkwechsel vom „Ausführen eines Tools" zum „Sicherheit betreiben".

Phase 1 — Den Scanner mit Terraform bereitstellen

Fünf Ressourcen — öffentliche IP, NSG, NIC, NSG-Zuordnung und die Ubuntu-VM — in weniger als zwei Minuten bereitgestellt:

terraform apply: 5 hinzugefügt, 0 geändert, 0 zerstört. Die Ausgaben enthalten den einsatzbereiten SSH-Befehl.

Anschließend habe ich mich per SSH verbunden und die Headless-Installation von Nessus Essentials 10.12.1 durchgeführt:

Scanner-SSH-Sitzung Erste SSH-Verbindung zu NESSUS01 mit schlüsselbasierter Authentifizierung — Ubuntu 24.04 läuft unter 10.0.1.8 und ist bereit für die Headless-Nessus-Installation.

Phase 2 — Nicht authentifizierter Basisscan

Erster Scan: keine Anmeldedaten — das sieht ein Angreifer im Netzwerksegment.

Konfiguration des Basic-Scans Basic Network Scan, der alle drei Hosts anvisiert: 10.0.1.5, 10.0.1.6, 10.0.1.7.

Ergebnisse des Basic-Scans Basisergebnisse: 35 Befunde auf 3 Hosts, die Auth-Spalte zeigt Fail — Nessus konnte sich nicht anmelden, sodass jedes Ergebnis ausschließlich aus externer Beobachtung stammt.

Phase 3 — Scan mit Anmeldedaten

Das Scannen mit Anmeldedaten ist der Unternehmensstandard für internes Schwachstellenmanagement. Ich habe die Windows-Ziele vorbereitet, indem ich den Dienst Remote Registry aktiviert und die erforderlichen Firewall-Regelgruppen im Domänenprofil geöffnet habe:

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

Beliebteste