Nessus über VPN: Wo der Scanner stehen muss, bevor der erste Scan läuft

Ein VPN-Symbol neben dem Browser sagt nichts über den Prozess aus, der die Scan-Pakete sendet. Wenn Konsole und Scanner auf verschiedenen Hosts laufen, ist der Tunnel des Browsers ein Pfad und die Quelle des Scans eine andere. Beginne beim Ausführungspunkt und arbeite dich dann nach außen zur Route, zur Autorisierung und zu den Anmeldedaten vor. Diese Unterscheidung steht nicht ohne Grund an erster Stelle der Checkliste.

Dies ist eine Checkliste vor dem Start, kein Scan-Tutorial. Jeder Schritt liefert eine Tatsache, die du im Auftragsprotokoll festhalten kannst, bevor ein Paket den Scanner verlässt.

Prüfpunkt eins: den Prozess finden, der die Sonden sendet

Zeichne die drei Rollen ausdrücklich auf: den Browser auf Laptop A, die Scan-Konsole auf Host B und das private Ziel C. Läuft auf B auch die Scan-Engine, braucht der Browser nur einen Pfad zu B. Erledigt eine separate Scanner-Appliance die Arbeit, braucht diese Appliance den Pfad zu C.

Browser on laptop A -> console on host B
Scanner process on B (or another appliance) -> private target C

Ein mit dem VPN verbundener Browser kann die Konsole erreichen, während der dahinter liegende Scanner noch keine Route zu C hat. Auch das Gegenteil ist möglich: Der Scanner befindet sich im privaten Netz, und die Konsole ist entfernt. Finde heraus, welche Anordnung du tatsächlich betreibst, bevor du eine Netzwerkkontrolle änderst. Benenne die Appliance in der Scan-Konfiguration, bevor du das Netzwerk beschuldigst.

Läuft der Scanner auf A, teilen sich Browser-Host und Scanner einen Kontext, aber nur solange dieser Prozess denselben Namespace und dieselbe Routing-Tabelle behält. Ein Container oder ein Dienstkonto erbt möglicherweise nicht, was der interaktive Browser sieht. Die Konsole ist eine Verwaltungsoberfläche, nicht die Scan-Engine.

Prüfpunkt zwei: Route und DNS des Scanners belegen

Führe die Routenprüfung auf dem Scanner-Host aus, nicht auf dem Laptop. Frage den Kernel, welche Schnittstelle und welches Gateway er für die Zieladresse verwenden würde, und wiederhole das für den Hostnamen des Ziels. Eine Route, die für die IP existiert, und ein Name, der auf eine andere Adresse auflöst, sind zwei verschiedene Fehler.

Bestätige die Quelladresse, die am Ziel erscheinen wird. Ein VPN-Client kann eine andere Adresse vergeben als die, die die Firewall des Ziels erwartet, und ein NAT-Gerät kann sie erneut umschreiben. Der Zielinhaber braucht die beobachtete Quelle, nicht die im VPN-Profil angezeigte Adresse.

Prüfe auch den Rückweg. Ein Scanner, der das Ziel erreicht, aber keine Antworten erhält, hat ein Routing- oder Firewall-Problem auf dem Rückweg, und das sieht genauso aus wie ein Ziel, das ausgefallen ist.

Prüfpunkt drei: Umfang und Blickwinkel genehmigen lassen

Lass dir vom Zielinhaber die Systeme, Dienste, Umgebung, Quelle und das Zeitfenster schriftlich nennen. Entscheide, welchen Blickwinkel die Prüfung abbildet: einen externen VPN-Nutzer, einen zugelassenen internen Client oder ein bestimmtes Scanner-Segment.

Eine private Route ist keine Erlaubnis, angrenzende Netze zu testen. Halte die Zielliste eng, führe ausgeschlossene Systeme auf und vereinbare Abbruchbedingungen sowie einen Kontakt, der den Lauf anhalten kann. Der Scanner prüft bereitwillig alles, was er erreichen kann, und genau deshalb muss der Umfang ausdrücklich festgelegt sein.

Halte die genehmigte Quelle im selben Dokument fest. Weicht die beobachtete Quelle des Scanners von der genehmigten ab, bildet der Lauf nicht den vereinbarten Blickwinkel ab, selbst wenn die Zielliste korrekt ist.

Prüfpunkt vier: Anmeldedaten an die Prüftiefe anpassen

Eine Erreichbarkeitsprüfung und eine authentifizierte Prüfung sind verschiedene Tests. Eine Port-Antwort beweist, dass etwas geantwortet hat; sie beweist nicht, dass Prüfungen mit Anmeldedaten liefen oder dass die Anwendung das Konto autorisiert hat.

Verwende eigene Anmeldedaten nur, wenn der vereinbarte Umfang authentifizierte Prüfungen verlangt. Bestätige die Berechtigungen und die Sperrrichtlinie des Kontos und entscheide, wie Befunde gespeichert und geteilt werden, bevor der Scan sie erzeugt.

Wenn Anmeldedaten fehlschlagen, weiche nicht stillschweigend auf einen nicht authentifizierten Lauf aus und bezeichne den Bericht nicht als geplante Prüfung. Das Ergebnis ist ein anderer Test mit anderer Bedeutung, und dieser Unterschied gehört in den Bericht.

Prüfpunkt fünf: Plan speichern, dann bewusst starten

Im Nessus-Scan-Workflow sind die Wahl einer Vorlage, das Konfigurieren der Einstellungen und das Speichern oder Starten des Scans getrennte Schritte. Nutze diese Trennung, um Zielliste, Quelle und Zeitplan zu prüfen, bevor Verkehr beginnt.

Bevor du den Start genehmigst, prüfe, welche Quelle das VPN zulässt, welchen Verkehr es trägt und wie es sich nach einem abgebrochenen Tunnel erholt. Erweitere den Firewall-Zugriff nicht nur deshalb, weil eine vorläufige Verbindung fehlgeschlagen ist; finde die Schicht, die sie abgelehnt hat, und behebe diese Schicht.

Halte nach dem Lauf den Scanner-Host, seine beobachtete Quelle, die Zielliste und alle Prüfungen fest, die nicht abgeschlossen werden konnten. Ein Bericht, der von einer anderen Quelle oder ohne die vorgesehenen Anmeldedaten erstellt wurde, bildet den ursprünglichen Plan nicht ab, und das zu benennen gehört zum Ergebnis.

Ziehe die Auftragszugänge zurück und behandle aufbewahrte Ergebnisse nach dem vereinbarten Prozess. Die Checkliste ist erst abgeschlossen, wenn die Belege zu dem von dir genehmigten Pfad passen, nicht schon dann, wenn der Scan einfach Ergebnisse geliefert hat.