Sophos Endpoint mit Self Help und SDU diagnostizieren
Ein Endpoint-Problem wird nicht durch wahlloses Neuinstallieren gelöst. Zuerst wird eingegrenzt, ob Schutzkomponenten, Central-Kommunikation, Update, Policy, Betriebssystem oder Netzwerk betroffen sind. Endpoint Self Help liefert dafür lokale Zustände und erste Ursachen. Die Sophos Diagnostic Utility, kurz SDU, sammelt anschliessend die technischen Protokolle.
Vor der Logsammlung
Vor jeder Diagnose werden die sichtbaren Symptome dokumentiert:
- betroffener Computer, Betriebssystem und Zeitpunkt,
- lokale Fehlermeldung oder Screenshot,
- Central Health, Last Active, Agent Mode und wirksame Policies,
- letzte Installation, Aktualisierung oder Policy-Änderung,
- reproduzierbarer Test und erwartetes Verhalten.
Diese Angaben sind oft wichtiger als ein sehr grosses Logarchiv ohne Zeitbezug.
Endpoint Self Help öffnen
In der lokalen Sophos-Endpoint-Oberfläche wird unten rechts About und danach Open Endpoint Self Help Tool gewählt. Das Werkzeug zeigt den Zustand wichtiger Komponenten, Kommunikation und Schutzdienste.
Self Help eignet sich für Fragen wie:
- Läuft die erwartete Komponente?
- Ist ein Dienst gestoppt oder fehlerhaft?
- Erreicht der Agent Central und die Update-Infrastruktur?
- Gibt es einen bekannten lokalen Konfigurations- oder Berechtigungsfehler?
Ein roter Check wird mit Name, Status, Detailtext und Zeitpunkt dokumentiert. Vor einer Reparatur wird geprüft, ob die Ursache durch eine zentrale Policy oder eine Netzwerksperre erneut erzeugt würde.
Stürzt SophosDiag.exe bereits beim Öffnen ab und nennt das Windows Application Event Log eine beschädigte benutzerspezifische user.config, wird nur die im Fehler angegebene Datei unter dem betreffenden Benutzerprofil entfernt. Der versionsabhängige übergeordnete Ordner wird nicht als fixer Pfad automatisiert gelöscht. Danach wird Self Help erneut geöffnet; bleibt der Fehler bestehen, folgt SDU beziehungsweise eine Reparatur der installierten Komponente.
Self-Help-Seiten gezielt verwenden
Die einzelnen Seiten beantworten unterschiedliche Fragen. Sie werden nicht als allgemeine Ampel gelesen:
| Seite | Aussage | Typischer nächster Schritt |
|---|---|---|
| Communication | MCS, Central-Verbindung, RCA, SXL oder Relay meldet einen Fehler | Network Test, Proxy, DNS und angezeigten Server prüfen |
| Update | Updatezustand, Updatequelle und letzter erfolgreicher Lauf | Update Now, Cache beziehungsweise Direktverbindung und AutoUpdate prüfen |
| Policy | letzter empfangener Policy-Stand und lokaler Override | Central-Zuweisung, Kommunikation und Override vergleichen |
| Network Test | Erreichbarkeit der tatsächlich konfigurierten Kommunikationswege | fehlgeschlagenen HTTPS-, DNS- oder ICMP-Schritt eingrenzen |
| Performance Analysis | zuvor erzeugte Scanner-Zusammenfassungen auswerten | belastende Prozesse, Pfade und Zeitfenster vergleichen |
Ein Policy-Update kann bis zu fünf Minuten benötigen. Ist Override Sophos Central Policy for up to 4 hours lokal aktiv, werden neue Central-Policies zwischengespeichert und erst nach Ende des Overrides angewendet. Eine alte Policy-Zeit ist dann kein Kommunikationsbeweis.
Unter Components werden installierte, heruntergeladene und erwartete Modulversionen verglichen. Not installed, unterschiedliche Download- und Installationsstände oder mehrere Versionen werden zuerst gegen Updatezustand, ausstehenden Neustart und ein konkurrierendes Sicherheitsprodukt geprüft. Das lokale Repository wird nicht vorsorglich gelöscht. Unter System kann ein weiterhin gemeldeter Pending Restart aus Windows Update stammen; nach einer Änderung an Hardware oder Sicherheitssoftware lässt sich der Softwarestand mit der Endpoint-CLI gezielt neu einlesen, bevor eine Reparatur gestartet wird.
Im Normalfall kommen Central-Aktionen innerhalb weniger Sekunden bis Minuten an. Last Active wird dagegen höchstens ungefähr stündlich aktualisiert. Bei einer Benutzer-Policy kann der Wechsel länger dauern, weil Central-Benutzer, lokal angemeldetes Konto und die vom MCS Client erkannte interaktive Sitzung zuerst übereinstimmen müssen.
Network Test richtig interpretieren
Der Network Test prüft die Kanäle Updating, Management Communication und Sophos Extensible List (SXL). Pro Ziel versucht das Werkzeug zuerst HTTPS, danach je nach Ergebnis ICMP und DNS-Auflösung. Für die Funktion ist eine erfolgreiche HTTPS-Verbindung entscheidend. Ein Ping oder nslookup allein beweist deshalb keine funktionierende Central-Kommunikation.
Bei einem Update Cache oder Message Relay prüft Self Help nur die DNS-Auflösung des zugewiesenen Servers. Ein grüner DNS-Test bestätigt weder Dienstzustand noch Port noch Weiterleitung. Die eigentliche Cache- oder Relay-Funktion wird separat kontrolliert.
Zwei Grenzen sind besonders wichtig:
- Nach einer geänderten Cache- oder Relay-Zuweisung muss Endpoint Self Help geschlossen und neu geöffnet werden, sonst kann der Network Test noch das alte Ziel verwenden.
- Authentifizierte Proxies werden vom Network Test nicht unterstützt und können irreführende Resultate erzeugen.
SXL-Tests benötigen eine administrative UAC-Erhöhung. Verwendet das Gerät ein Message Relay, führt Self Help den SXL-Test nicht direkt aus, weil dieser Verkehr über das Relay läuft.
Bleibt die Kommunikation fehlerhaft, werden die von Self Help angezeigten Brokeradressen mit der lokalen MCS-Konfiguration verglichen. Zusätzlich werden Routing, Windows-Hosts-Datei, Proxy und Firewall-Log geprüft. Nach einer Korrektur kann der Sophos MCS Client neu gestartet und Self Help aktualisiert werden. Ein Browserzugriff auf Central ersetzt diese Prüfung nicht.
Updatefehler ohne vorschnelle Cache-Löschung
Ein fehlgeschlagenes Update innerhalb der Sophos-Grace-Period kann vorübergehend sein. Zuerst werden Update Now, Netzwerk, Proxy, Updatequelle und Zeit des letzten erfolgreichen Updates geprüft. Erst wenn diese Prüfungen keine Ursache zeigen, kommt das von Sophos dokumentierte Zurücksetzen des lokalen AutoUpdate-Caches infrage.
Bei einem reproduzierbaren Fehler wird SophosUpdate.log mit einer zeitgleichen Paketaufzeichnung sowie Firewall- oder Proxy-Logs korreliert. Entscheidend sind DNS-Antwort, tatsächlich kontaktierter Updateserver, direkter oder proxied Pfad und der erste HTTP- beziehungsweise TLS-Fehler. Die wichtigsten Windows-Logpfade stehen unter Sophos Endpoint Windows-Logs und Dienste richtig auswerten.
Dieser Eingriff benötigt deaktivierten Tamper Protection, Administratorrechte und erzeugt einen Pending-Restart-Alert. Die Cache- und Repository-Ordner werden gesichert beziehungsweise umbenannt, nicht ungeprüft gelöscht. Danach muss ein vollständiges Update erfolgreich sein und Self Help nach Refresh wieder einen gesunden Zustand zeigen.
Performance Analysis
Seit Core Agent 2024.3 kann Endpoint Self Help auf unterstützten Windows-Systemen Scanner-Zusammenfassungen laden. Die CSV-Dateien liegen standardmässig unter:
C:\ProgramData\Sophos\Sophos File Scanner\Logs\summary.<TIMESTAMP>.csv
Sie können auf einem anderen Gerät mit Endpoint Self Help analysiert werden. Die Datei zeigt, welche Prozesse und Pfade während des protokollierten Zeitfensters Scanlast erzeugten. Daraus entsteht noch keine pauschale Ausnahme. Erst werden Anwendung, Zugriffsmuster und engster technisch sinnvoller Ausschluss geprüft.
Bei der Auswertung werden zuerst Ordner mit langer kumulierter Scanzeit, danach besonders häufig geprüfte Pfade und schliesslich grosse Datenmengen verglichen. Ein häufig gescannter Pfad muss nicht derselbe sein wie der Pfad mit der höchsten Gesamtdauer. Warnt Self Help vor einer zu breiten Ausnahme, darf diese höchstens kurz zur Ursachenbestätigung dienen. Als dauerhafte Lösung wird sie auf den tatsächlich belastenden Unterordner oder Prozess eingegrenzt.
Product Analysis geht einen Schritt weiter und schaltet Schutzfunktionen geführt aus und wieder ein, um die beteiligte Komponente einzugrenzen. Dafür sind Administratorrechte und bei aktivem Manipulationsschutz das Tamper-Protection-Kennwort erforderlich. Der Ablauf gehört auf ein kontrolliertes Testgerät oder in ein Wartungsfenster: Schutzstatus und Updatezustand werden vor Beginn dokumentiert, das Ergebnis gespeichert und anschliessend alle Funktionen sowie Updates wieder auf den Ausgangszustand gesetzt. Das Werkzeug liefert eine Hypothese, aber keine automatische Freigabe für eine Ausnahme.
File Info statt Bauchgefühl
Unter Tools > File Info lässt sich eine Windows-PE-Datei lokal bewerten. Self Help zeigt SHA-256, Grösse, Application-Control-Kategorie und Produktname sowie die resultierende Policy-Entscheidung. Local Reputation berücksichtigt Sophos-Daten und kundeneigene Allowed Applications beziehungsweise Blocked Items. Sie kann deshalb von der live abgefragten Global Reputation abweichen und diese für die lokale Entscheidung übersteuern.
Der Deep-Learning-Bereich benötigt eine passende Intercept-X-Lizenz. Ein grünes Ergebnis beweist nicht, dass eine bereits erkannte Malware harmlos ist: Erkannte Malware- oder PUA-Dateien lassen sich normalerweise gar nicht in die Seite ziehen. Für eine Fehlklassifizierung werden Hash, Signatur, lokaler und globaler Lookup-Typ sowie der konkrete Policy-Entscheid gesichert und danach der dokumentierte Sample-Submission-Prozess verwendet.
Policy-, Service- und Operations-Status vertiefen
Zeigt die Policy-Seite veraltete Zeitstempel, wird zwischen Empfang und lokaler Verarbeitung unterschieden. McsClient.log wird auf Verbindungs- und Backoff-Einträge geprüft, McsAgent.log auf Policy-, Namespace- und Statusfehler. In der MCS-Cache-Struktur zeigen Active.policy und Latest.policy, ob eine neue Policy angekommen ist, aber lokal noch nicht aktiv wurde. Dienste werden erst nach Sicherung der Beobachtung neu gestartet; danach muss das Log den erfolgreichen Übergang bestätigen.
Auf der Operations-Seite ist nicht jedes blaue oder leere Symbol ein Fehler. Eine deaktivierte Data-Lake-Funktion, ein bewusst ausgeschlossenes Gerät oder ein erreichtes tägliches Uploadlimit werden von einem tatsächlich fehlerhaften Live-Query-Dienst unterschieden. Bei schlechtem Data-Lake-Status werden zuerst SophosLiveQueryService.log, SophosOsquery.log und der Dienstzustand geprüft.
Der Heartbeat-Abschnitt zeigt Bereitschaft, Zertifikatszustand und eine bestehende Verbindung zu einer Sophos Firewall. Ein Eintrag configured, no connection currently available beweist allein keinen Endpoint-Fehler, und der Heartbeat-Status fliesst nicht in den allgemeinen Device Health ein. Wird eine Verbindung erwartet, werden Endpoint- und Firewall-Logs anhand von Zeitpunkt und Device ID korreliert. Registry- oder Zertifikatsreparaturen aus Advanced Self Help erfolgen nur mit Export beziehungsweise Backup, deaktiviertem Tamper Protection und einem dokumentierten Rückweg.
SDU über die Oberfläche starten
Aus Endpoint Self Help lässt sich Launch SDU öffnen. Nach Start sammelt das Werkzeug Systeminformationen und Sophos-Produktlogs. Am Ende kann das Paket gespeichert oder an Sophos übermittelt werden.
Das Archiv kann Hostnamen, Benutzernamen, Pfade, IP-Adressen, Prozesslisten, Konfigurationen und Ereignisse enthalten. Es gehört deshalb nicht in öffentliche Tickets, ungeschützte Fileshares oder Chatverläufe.
Ein online erreichbares Gerät lässt sich auch aus Central diagnostizieren: Unter My Environment > Computers & Servers wird das Gerät geöffnet und über More actions > Diagnose eine SDU-Sammlung ausgelöst. Das Archiv wird direkt an Sophos übertragen; für den Supportfall wird der angezeigte Dateiname notiert. Ausführung und auslösender Administrator erscheinen in den Audit Logs.
Ist das Gerät offline, hält Central den Auftrag höchstens 14 Tage vor. Danach wird er verworfen und muss neu ausgelöst werden. Der Befehl startet bei der nächsten Central-Kommunikation, daher werden Zeitpunkt, Datenschutzfreigabe und erwartete Gerätekonnektivität vor dem Auslösen geklärt.
Product Logging und Packet Capture
Product Logging erhöht den Log-Level einzelner Endpoint-Komponenten. Es wird nur für die tatsächlich verdächtige Komponente und ein reproduzierbares Zeitfenster aktiviert. Nach der Reproduktion werden alle Änderungen über Revert zurückgesetzt und die erzeugten Logs zusammen mit Startzeit, Endzeit und Testschritten gesichert. Dauerhaftes Debug-Logging kann sensible Inhalte und erhebliches Datenvolumen erzeugen.
Die in Self Help integrierte Paketaufzeichnung verwendet Windows pktmon. Sie ist auf älteren Windows-Versionen nicht verfügbar und benötigt UAC-Erhöhung. Die Standardgrenze beträgt 512 MB; ein administrativ gewähltes Limit verhindert, dass eine lange Aufzeichnung das Laufwerk füllt. Self Help erzeugt eine ETL- und eine PCAPNG-Datei unter C:\ProgramData\Sophos\Endpoint Self Help\PacketCapture. Das Schliessen von Self Help stoppt die Aufzeichnung.
Kann Self Help weder Logging noch Paketaufzeichnung oder SDU erhöhen, werden zuerst die Windows-UAC-Einstellungen geprüft. Insbesondere vollständig deaktiviertes UAC oder unterdrückte Elevation-Prompts können die Funktion blockieren. Microsoft-Standardwerte wiederherzustellen ist sauberer als Sophos-Werkzeuge dauerhaft über das integrierte Administratorkonto zu starten.
SDU unter Windows per Kommandozeile
Die Windows-Version liegt normalerweise unter:
C:\Program Files\Sophos\Sophos Diagnostic Utility\sducli.exe
Eine administrative Eingabeaufforderung liefert mit folgendem Aufruf die integrierte Hilfe:
& "C:\Program Files\Sophos\Sophos Diagnostic Utility\sducli.exe" -help
Wichtige Parameter sind:
| Parameter | Zweck |
|---|---|
-[no-]sysinfo | Systeminformationen ein- oder ausschliessen |
-[no-]sophos | Sophos-Produktlogs ein- oder ausschliessen |
-outputdir="<directory>" | Zielverzeichnis festlegen |
-outputname="<path>" | Namen und Pfad des ZIP-Archivs festlegen |
Die lokal installierte -help-Ausgabe ist für die vorhandene Agentversion massgebend. Automatisierte Sammlungen werden mit Speicherlimit, sicherem Ziel und Löschfrist versehen.
SDU unter macOS per Kommandozeile
Auf einem Mac wird SDU aus dem Programmpaket gestartet:
/Library/Sophos\ Anti-Virus/Tools/Sophos\ Diagnostic\ Utility.app/Contents/MacOS/Sophos\ Diagnostic\ Utility --cli --help
Mit --output_path="<path>" lässt sich der Ausgabeort festlegen. Der Prozess benötigt die Berechtigungen, die für die zu sammelnden Daten erforderlich sind. Fehlende Full-Disk-Access- oder System-Extension-Freigaben werden zusätzlich über die macOS-Berechtigungsdiagnose geprüft.
Forensikmodus richtig einordnen
SDU kann spezielle Forensik-Logs erzeugen. Dieser Modus ist für Sophos Incident Response beziehungsweise eine gezielte forensische Untersuchung vorgesehen. Er ist kein Ersatz für einen vollständigen Enterprise-Forensikprozess und sollte nicht ohne definierten Auftrag dauerhaft aktiviert werden.
Bei einer möglichen Kompromittierung gelten zusätzliche Regeln:
- Gerät nicht vorschnell neu starten oder bereinigen,
- Zeitquelle und Zeitzone dokumentieren,
- Beweisdaten nur auf ein kontrolliertes Ziel schreiben,
- Hash, Übergabe und Zugriff auf das Archiv protokollieren,
- Incident-Response-Verantwortliche einbeziehen.
Konfiguration und Softwarestatus per CLI ausgeben
Die lokale Endpoint-CLI kann Policy- und Softwarezustände ausgeben. Output configuration zeigt, welche Einstellungen am Gerät angekommen sind. Software Monitor liefert Zustände installierter Komponenten und kann deren Status aktualisieren.
Diese Ausgaben helfen bei drei typischen Widersprüchen:
- Central zeigt eine Policy als zugewiesen, lokal fehlt die Einstellung.
- Agent Mode ist korrekt, aber eine Komponente ist nicht installiert oder nicht gesund.
- Ein Update wurde angekündigt, Software Monitor bleibt jedoch in einem fehlerhaften Zustand.
Die lokal verfügbare Hilfe wird vor der Verwendung geprüft, weil Befehle und Parameter vom installierten Agentstand abhängen können.
Logs zielgerichtet auswerten
Nicht jedes Log wird vollständig gelesen. Man beginnt mit einem engen Zeitfenster und sucht nach dem ersten Fehler, nicht nur nach Folgefehlern. Besonders nützlich sind:
- Installer- und Update-Logs bei Rolloutproblemen,
- MCS- beziehungsweise Management-Kommunikation bei fehlendem Central-Kontakt,
- Health- und Komponentenlogs bei rotem Status,
- Web-, DLP-, Application- oder Peripheral-Ereignisse bei Policy-Problemen,
- Betriebssystem-Eventlogs rund um Dienststarts, Treiber und Zertifikate.
Ein einzelnes error ist noch keine Ursache. Zeitliche Korrelation, Komponente und reproduzierbares Verhalten entscheiden.
Supportpaket vorbereiten
Ein gutes Supportpaket enthält:
- kurze Problembeschreibung und Auswirkung,
- exakten Zeitpunkt mit Zeitzone,
- betroffene und nicht betroffene Vergleichsgeräte,
- Schritte zur Reproduktion,
- relevante Central-Screenshots ohne Geheimnisse,
- SDU-Archiv und gegebenenfalls Installer-Logs,
- bereits getestete Massnahmen und deren Ergebnis.
Tamper-Protection-Kennwörter, API-Secrets, Proxy-Kennwörter und Installer-Tokens werden niemals in Klartext beigefügt.
Minimum Escalation Requirements erfüllen
Sophos hat die Windows-Endpoint-Anforderungen für Supporteskalationen nach Fehlerklasse aufgeteilt. Ein SDU ohne eigene Analyse erfüllt diese Minimum Escalation Requirements, kurz MER, nicht.
Für jeden Fall werden zuerst Plattform und Produktversion, betroffene Komponente, Umfang, Häufigkeit, Reproduzierbarkeit, Änderungen vor dem Auftreten sowie exakte Fehlermeldungen erfasst. Die Logs müssen vollständig sein, den Fehlerzeitpunkt enthalten und bei Client-Server-Problemen zeitlich zusammenpassen.
Danach kommen szenariospezifische Daten hinzu:
| Fall | Zusätzliche Mindestdaten |
|---|---|
| Installation oder Deinstallation | vollständige CLI, Deploymentweg, Installerlog und bei Bedarf Process-Monitor-Aufzeichnung mit Advanced Output und allen Events |
| Update oder Kommunikation | Self-Help- und Network-Test-Ergebnis, Updatequelle beziehungsweise Relay, Proxy und betroffene Serveradresse |
| Scanning oder Detection | Schutzfunktion, Reproduktionsschritt, File-Info-Reputation, passendes Komponentenlog und gegebenenfalls Performance Analysis |
| Performance | betroffener Prozess, CPU-, RAM- oder I/O-Verlauf, reproduzierbares Zeitfenster und passender ETL- beziehungsweise Process-Dump |
| Crash oder Bluescreen | vollständiger oder aktiver Memory Dump, Stackanalyse auf Sophos- und Fremdtreiber sowie SDU aus demselben Zeitraum |
| Device Management | effektive Policy, lokale Komponente, konkrete Anwendung beziehungsweise Hardware und funktionsspezifisches Debug-Log |
Bei einem Performancefall wird zuerst unterschieden, ob SophosFileScanner.exe, SEDService.exe, SSPService.exe, ein anderer Sophos-Prozess oder die allgemeine Systemlast auffällig ist. Ein global deaktivierter Schutz liefert ohne zeitgleiche Messung und genaue Komponentenzuordnung keine belastbare Ursache.
Zusätzlich wird unter Account Preferences > Evaluation Modes geprüft, ob Aggressive threat detection aktiviert ist. Diese Support- und SophosLabs-Diagnoseoption erhöht die Systemlast deutlich und ist keine produktive Sicherheitsbaseline. Ist sie aktiv, wird der Auftrag dazu dokumentiert und die Option nach der vorgesehenen Messung wieder deaktiviert. Bleibt das Problem danach bestehen, wird es als eigener Performancefall mit neuem Zeitfenster weiter untersucht.
Bei Exploit-, Ransomware- oder HitmanPro.Alert-Fällen wird zusätzlich geprüft, ob Sophos bereits eine Endpoint Maintenance Release mit einem passenden Bugfix anbietet. Ein Crashdump oder vollständiger Memory Dump wird nach der reproduzierten Störung und vor dem SDU erzeugt, damit die Artefakte aus demselben Zeitfenster stammen. Schutz-DLLs oder Treiber werden nicht ohne aktuelles Sophos-Runbook umbenannt.
Ein Supportfall enthält nicht nur die gesammelten Dateien, sondern auch das Ergebnis der eigenen Prüfung: Welches Log zeigt den ersten relevanten Fehler, zu welcher Uhrzeit und welche Hypothese wurde damit bestätigt oder verworfen?