Sophos Managed Risk: authentifizierte Scan-Zugangsdaten konfigurieren

Bei einem authentifizierten internen Vulnerability Scan meldet sich der Scanner am Zielsystem an. So kann er lokale Dateien, Registry-Einträge, installierte Software und Konfigurationen prüfen, die für einen Scan ohne Zugangsdaten nicht sichtbar sind. Dadurch findet er in der Regel mehr Schwachstellen. Ein unauthentifizierter Scan bleibt dennoch nützlich: Er zeigt eher, was ein externer Angreifer ohne Konto erreichen würde.

Das sichere Vorgehen gliedert sich in vier Schritte:

Ein dediziertes Scan-Konto mit den für die vorgesehenen Prüfungen nötigen Rechten vorbereiten.
Das Zielbetriebssystem für SMB/WMI beziehungsweise SSH erreichbar machen.
Unter Managed Risk > Settings > Credentials > Add credential den passenden Credential-Typ anlegen.
Das Credential einem internen Vulnerability Scan mit Scan type: Authenticated zuweisen und das Ergebnis im nächsten Scan validieren.

Zielsysteme vor Sophos Fusion vorbereiten

Die Vorbereitung erfolgt direkt auf dem Windows-, macOS- oder Linux-Ziel und ist von der späteren Erfassung der Zugangsdaten in Sophos Fusion getrennt. Auch eine korrekt ausgefüllte Fusion-Maske kann fehlende Freigaben, Dienste oder Rechte auf dem Ziel nicht ersetzen.

Windows

Für Windows-Endgeräte und Server ausser Domain-Controllern ein dediziertes lokales Konto in der lokalen Administratorengruppe verwenden. Domain-Controller erfordern dagegen einen Domain-Administrator und gehören in einen separaten Scan mit eigenen Zugangsdaten. So kommt das mächtigere Konto nicht auf Member-Servern oder Clients zum Einsatz.

Vor der Zuweisung prüfen:

Sicherheitsrichtlinien wie Deny access to this computer from the network und Access this computer from the network, weitere lokale Richtlinien, Endpoint-Schutz sowie IPS/IDS dürfen die vorgesehenen Credential-Checks nicht blockieren.
Für einige lokale Prüfungen ist PowerShell 5.0 oder neuer erforderlich.
Der Scanner benötigt SMB- und WMI-Zugriff. Die Host-Firewall muss Verbindungen von der IP-Adresse der Managed-Risk-Scanning-Appliance zulassen; für File and Printer Sharing sind TCP 139 und 445 relevant. Ports anderer zu prüfender Dienste müssen ebenfalls vom Scanner erreichbar sein.
Die administrativen Freigaben IPC$, ADMIN$ und C$ müssen verfügbar sein.
Remote Registry muss laufen beziehungsweise mit den verwendeten administrativen Rechten für den Scan startbar sein.
Für die dokumentierten Windows-Kontoszenarien muss Network access: Sharing and security model for local accounts auf Classic - local users authenticate as themselves stehen. Das gilt sowohl bei einem Domain-Konto für lokale Audits als auch bei einem lokalen Konto; eine Anmeldung als Gast reicht für lokale Sicherheitsprüfungen nicht.
Bei lokalen Konten darf UAC den Remote-Admin-Token nicht filtern. Die dokumentierten Varianten sind das Ausschalten von UAC oder der DWORD-Wert HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\system\LocalAccountTokenFilterPolicy mit dem Wert 1. Eine solche Sicherheitsänderung nur nach internem Change-Prozess und auf die betroffenen Systeme begrenzt umsetzen.
Für WMI die vordefinierten eingehenden Regeln Windows Management Instrumentation (ASync-In), Windows Management Instrumentation (WMI-In) und Windows Management Instrumentation (DCOM-In) aktivieren. Die Regeln nach Möglichkeit auf die IP-Adresse der Scanning-Appliance begrenzen.

Diese Voraussetzungen nicht durch eine breite Firewallfreigabe für beliebige Quellen ersetzen. Wenn die Scanning-Appliance und ein Ziel in verschiedenen VLANs liegen, benötigt die Appliance laut Scan-Vorgabe vollständigen bidirektionalen Zugriff auf alle Ports und Protokolle des Ziel-VLANs. Routing und Zwischen-Firewalls müssen diesen Zugriff erlauben; die Regeln dabei auf die Appliance und die vorgesehenen Zielbereiche begrenzen.

macOS

macOS-Ziele werden über SSH geprüft: entweder mit einem Schlüsselpaar oder mit Benutzerzugangsdaten und sudo beziehungsweise su. Für vollständige lokale Prüfungen muss das Scan-Konto Mitglied der Administratorengruppe sein und Full Disk Access besitzen. Mit weniger Rechten sind zwar einzelne Prüfungen wie die Ermittlung des Patchstands möglich, aber nicht dieselbe Prüftiefe. Das dedizierte Konto muss auf allen vorgesehenen macOS-Zielen denselben Benutzernamen haben; wenn möglich, ist ein Schlüsselzugang den Benutzerzugangsdaten vorzuziehen.

Vor dem Scan gelten folgende Voraussetzungen:

Remote Login aktivieren und dem dedizierten Scan-Konto erlauben.
In der Systemeinstellung Remote Login die Option Allow full disk access for remote users aktivieren. Ausserdem den beiden dokumentierten Prozessen /usr/libexec/sshd-keygen-wrapper und /Library/NessusAgent/run/sbin/nessus-service unter Privacy & Security Full Disk Access gewähren.
Bei Kerberos muss sshd Kerberos unterstützen, die Interaktionsmethode gssapi-with-mic verwenden und Reverse-DNS korrekt funktionieren.
SSH-Server und Scanner müssen einen gemeinsamen unterstützten Cipher besitzen. Dokumentiert sind blowfish-cbc, aes128-cbc, aes192-cbc, aes256-cbc, 3des-cbc und AES-CTR. Keine veraltete Verschlüsselung nur für den Scan pauschal aktivieren; zuerst die bereits sichere gemeinsame Option prüfen.
Für einen Schlüsselzugang den öffentlichen Schlüssel als authorized_keys beim dedizierten Konto hinterlegen und den privaten Schlüssel ausschliesslich geschützt für den Scanner bereitstellen.

Linux

Auch Linux-Ziele werden über SSH geprüft: mit einem Schlüsselpaar oder mit Benutzerzugangsdaten und sudo beziehungsweise su. Für die grösstmögliche Prüftiefe muss das Konto Befehle mit Root-Rechten ausführen können. Ein weniger privilegiertes Konto kann Teilresultate liefern, deckt Konfigurations- und Dateiprüfungen aber nicht vollständig ab.

Vor dem Scan prüfen:

Einen dedizierten SSH-Benutzer mit exakt demselben Namen auf allen vorgesehenen Zielen einrichten. Bei reiner Schlüsselanmeldung muss das Konto ohne gültiges Passwort geführt werden; der öffentliche Schlüssel liegt in authorized_keys, der private Schlüssel bleibt geschützt beim Scanner.
SSH-Verbindung und vorgesehene Privilegienerhöhung vom Netz der Scanning-Appliance aus ermöglichen.
Bei Kerberos muss sshd Kerberos unterstützen, gssapi-with-mic verwenden und Reverse-DNS korrekt funktionieren.
Die Shell-Konfiguration des Scan-Kontos benötigt eine PS1-Variable mit mindestens vier Zeichen. Eine sehr kurze Eingabeaufforderung wie PS1='$ ' kann den Scan stark verlangsamen.
Für die SSH-Cipher gelten dieselben dokumentierten Optionen wie bei macOS. Bestehende sichere gemeinsame Algorithmen verwenden und die Hostkonfiguration nicht unnötig aufweiten.

Die allgemeine SSH-Hostvorbereitung kann modernere Schlüsseltypen unterstützen. In Managed Risk > Settings > Credentials akzeptiert Public Key derzeit jedoch nur RSA- und DSA-Schlüssel im OpenSSH-Format. Ein dort nicht unterstützter Schlüsseltyp lässt sich deshalb nicht durch eine Änderung am Zielsystem nutzbar machen.

Credential in Sophos Fusion anlegen

Unter Managed Risk > Settings den Tab Credentials öffnen und Add credential wählen. In Create credential zuerst den Typ auswählen. Plaintext-Authentifizierung wird nicht unterstützt.

SNMPv3

SNMPv3 ist für Netzwerkgeräte mit SNMP Version 3 vorgesehen. Folgende Felder ausfüllen:

Credential type: SNMPv3.
Credential name: eindeutiger Name, beispielsweise snmpv3-core-switches.
Description: optionaler Hinweis zum vorgesehenen Gerätebereich.
Username: Benutzer des SNMPv3-Kontos.
Port: standardmässig 161; nur ändern, wenn das Ziel SNMPv3 auf einem anderen Port bereitstellt.
Security Level: Authentication and privacy. Diese Kombination aus Authentifizierung und Verschlüsselung ist derzeit die einzige Option.
Authentication algorithm: SHA-256, SHA-384 oder SHA-512 passend zur Zielkonfiguration.
Authentication password: Authentifizierungspasswort des SNMPv3-Kontos.
Privacy algorithm: AES-256 oder AES-256C passend zur Zielkonfiguration.
Privacy password: Privacy-Passwort des SNMPv3-Kontos.
Mit Create speichern.

Windows

Für Credential type: Windows zunächst einen eindeutigen Credential name und optional eine Description eintragen. Danach unter Authentication method eine der drei Varianten wählen:

Kerberos: Username, Password, Domain, Key Distribution Center (KDC), KDC Port (Standard 88), KDC Transport (TCP oder UDP) und Realm eintragen.
NTLM Hash: Username, Hash und Domain eintragen. Einen NTLM-Hash wie ein Passwort behandeln und nie in Diagnoseunterlagen übernehmen.
Password: Username, Password und bei Bedarf die optionale Domain eintragen.

Mit Create speichern. Bei lokalen Konten muss der Benutzer zum jeweiligen Ziel passen; bei Domain-Controller-Scans die dafür reservierten Domain-Admin-Zugangsdaten verwenden.

SSH für Linux und macOS

Für Credential type: SSH einen eindeutigen Credential name, optional eine Description und anschliessend die Authentication method wählen:

Kerberos: Username, Key Distribution Center (KDC), KDC Port (Standard 88), KDC Transport (TCP oder UDP) und Realm eintragen.
Password: Username und Password eintragen. Elevate privileges with nur wählen, wenn die vorbereitete Zielkonfiguration dies benötigt.
Public Key: Username eintragen. Unter Private key mit Add File die private Schlüsseldatei hochladen oder den Schlüssel direkt einfügen. Nur RSA- und DSA-Schlüssel im OpenSSH-Format werden unterstützt. Für einen geschützten Schlüssel zusätzlich Private key passphrase eintragen.

Bei Public Key unter Elevate privileges with zwischen Nothing und sudo wählen. Für sudo zusätzlich sudo user und, falls erforderlich, sudo password eintragen. Das Konto und die gewählte Erhöhung müssen zur vorbereiteten Konfiguration auf dem Ziel passen.

Optional lassen sich unter Targets Hostnamen, IP-Adressen oder CIDR-Blöcke eintragen, um dieses Public-Key-Credential für diese Ziele zu priorisieren. Mehrere Werte mit Komma oder Leerzeichen trennen. Diese Priorisierung ersetzt weder die Zieldefinition des Scans noch die Credential-Auswahl im Scan.

Mit Create speichern.

VMware ESX SOAP API

Dieser Typ ist für VMware-ESX/ESXi-Hosts vorgesehen:

Credential type: VMware ESX SOAP API.
Credential name: eindeutiger Name.
Description: optionaler Hinweis zu den vorgesehenen Hosts.
ESX SOAP API Authentication Method: Username and Password. Dies ist derzeit die einzige Option.
Username: VMware-Konto mit administrativem Zugriff auf den ESX/ESXi-Host.
Password: Passwort dieses Kontos.
Mit Create speichern.

Für umfassende Prüfungen benötigt dieses Konto administrativen Zugriff auf den Host. Das Credential ist für VMware-Virtualisierungsumgebungen bestimmt, nicht für Windows- oder SSH-Ziele innerhalb der VMs.

Credential einem authentifizierten Scan zuweisen

Gespeicherte Zugangsdaten lösen noch keinen Scan aus. Unter My Products > Managed Risk > Scans > Internal einen internen Vulnerability Scan anlegen und auf der Seite Create Vulnerability Scan wie folgt konfigurieren:

Unter Select scanner die verbundene Scanning-Appliance wählen.
Unter Configure scan details Name und Beschreibung eintragen.
Scan type auf Authenticated setzen.
Unter Select credentials die passenden Credentials wählen. Pro Scan sind höchstens zehn Credentials möglich.
Unter Add scan targets die vorgesehenen IP-Adressen, CIDR-Bereiche oder Hostnamen erfassen und mit Add übernehmen. Einzeln erfasste Werte jeweils mit Enter bestätigen; eingefügte Listen müssen kommasepariert sein.
Unter Schedule the weekly scan Tag, Uhrzeit und Zeitzone festlegen und oben rechts mit Save speichern.

Zugangsdaten nach Betriebssystem, Vertrauensbereich und Schutzbedarf trennen. Insbesondere gehört ein Domain-Admin-Credential nicht in einen breiten Scan normaler Windows-Clients. Sind mehr als zehn Credentials erforderlich, den Zielbereich in nachvollziehbare Scans aufteilen, statt Zugangsdaten zusammenzulegen oder Rechte auszuweiten.

Windows-Credential vor dem nächsten Scan testen

Die dokumentierten Credential-Tests gelten derzeit nur für Windows. Sie müssen von einem Windows-System im selben Subnetz wie die Scanning-Appliance und mit exakt denselben Zugangsdaten ausgeführt werden. So lassen sich die Netzwerkbedingungen des Scanners möglichst genau nachbilden.

Eine Command Prompt oder PowerShell als Administrator öffnen. Im Beispiel ist 192.0.2.25 eine Dokumentationsadresse und muss durch die interne IP des Zielsystems ersetzt werden. LAB-SRV-025\svc_mrisk ist ein lokales Beispielkonto; bei einem Domain-Konto stattdessen die Form DOMAIN\User mit den eigenen Werten verwenden.

IPC$ und ADMIN$ prüfen

net use \\192.0.2.25\ipc$ /user:LAB-SRV-025\svc_mrisk *
net use \\192.0.2.25\admin$ /user:LAB-SRV-025\svc_mrisk *

Nach jedem Befehl das Passwort an der verdeckten Eingabeaufforderung eingeben. The command completed successfully bestätigt für diesen Test die Zugangsdaten und den jeweiligen SMB-Zugriff. Erfolg bei ADMIN$ zeigt zusätzlich, dass das Konto administrativen Freigabezugriff besitzt.

Remote Registry prüfen

reg query \\192.0.2.25\HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion /v ProgramFilesDir

Eine ausgegebene Registry-Zeile für ProgramFilesDir bestätigt, dass Remote Registry über die bestehende Sitzung erreichbar ist. Bei The network path was not found zuerst Dienst, SMB-Pfad und Firewall prüfen; bei Access is denied Kontorechte, UAC-Remote-Token und die tatsächlich verwendete Identität kontrollieren.

WMI prüfen

wmic /node:"192.0.2.25" /user:"LAB-SRV-025\svc_mrisk" /password:* os get name

Das Passwort erst an der Eingabeaufforderung eingeben. Eine Betriebssystembezeichnung unter Name bestätigt den WMI-Zugriff für diesen Test. Ist wmic auf der verwendeten Windows-Version nicht vorhanden, keinen ungetesteten Ersatzbefehl verwenden. Stattdessen die WMI-Firewallregeln und die Hostvorbereitung prüfen und die eigentliche Validierung über den nächsten Managed-Risk-Scan durchführen.

Sitzungen immer bereinigen

Nach dem Test beide Verbindungen entfernen, auch wenn ein Zwischenschritt fehlgeschlagen ist:

net use \\192.0.2.25\ipc$ /delete
net use \\192.0.2.25\admin$ /delete

Danach mit net use kontrollieren, dass keine Verbindung zum Testziel mehr aufgeführt wird, und das administrative Terminal schliessen.

Ergebnis im nächsten Scan validieren

Nach dem nächsten geplanten Lauf unter Managed Risk > Report History kontrollieren, ob der interne Vulnerability Report erstellt wurde. Authentifizierte Ergebnisse sind in der Regel detaillierter als unauthentifizierte. Eine bestimmte Anzahl Findings ist jedoch kein Erfolgskriterium: Betriebssystem, offene Ports, installierte Software, verwendete Plugins und Scan-Typ beeinflussen das Resultat.

Für eine belastbare Prüfung:

Bestätigen, dass im Scan Scan type: Authenticated und die vorgesehenen Credentials ausgewählt sind.
Sicherstellen, dass die Zielsysteme im Scan-Scope liegen und von der Scanning-Appliance erreichbar sind.
Bei Windows zuerst die vier Bereiche IPC$, ADMIN$, Remote Registry und WMI prüfen.
Bei Linux und macOS SSH-Erreichbarkeit, Schlüssel- beziehungsweise Kerberos-Konfiguration und die vorgesehene Privilegienerhöhung prüfen.
Host- und Zwischen-Firewalls auf blockierten Verkehr von der IP-Adresse der Scanning-Appliance kontrollieren.
Erst danach Credential-Felder ändern und beim nächsten Scan erneut validieren.

Wenn die Resultate weiterhin wie ein unauthentifizierter Scan wirken oder unerwartet unvollständig bleiben, unter Threat Analysis Center > Cases > Create case > Managed Risk service request eine Anfrage an das Managed-Risk-Team erstellen. Scan-Name, Zeitfenster mit Zeitzone, Scannername, Zieltyp, Credential-Typ, betroffene anonymisierte Ziele, beobachtetes Ergebnis und bereits durchgeführte Prüfungen angeben. Keine Passwörter, Hashes, privaten Schlüssel oder vollständigen sensiblen Konsolenausgaben anhängen.

Credentials bearbeiten oder löschen

Zum Bearbeiten unter Managed Risk > Settings > Credentials in der Spalte Actions das Drei-Punkte-Menü öffnen, Edit wählen, die Felder anpassen und mit Update speichern. Die Änderung beim nächsten vorgesehenen Scan validieren.

Vor dem Löschen zuerst alle Scan-Konfigurationen prüfen, die das Credential verwenden. Danach im selben Drei-Punkte-Menü Delete wählen und im Dialog mit Confirm endgültig löschen. Das Löschen entfernt das Credential aus allen Scan-Konfigurationen, in denen es verwendet wurde, und kann deren künftige authentifizierte Läufe beeinträchtigen. Anschliessend jeden betroffenen Scan öffnen, die verbleibende Credential-Auswahl kontrollieren und nötigenfalls ein vorbereitetes Ersatz-Credential zuweisen.

Mit dem Refresh-Symbol oben rechts lässt sich die Credential-Liste neu laden. Es bestätigt, dass die Listenansicht aktualisiert wurde, aber nicht, dass ein Credential auf einem Ziel funktioniert; diesen Nachweis liefert erst der Test beziehungsweise der nächste Scan.