Sophos XDR Data Collector überwachen und warten

Unter Security Operations > Integrations > Data Collectors werden die Sophos XDR Data Collectors überwacht. Für einen belastbaren Betriebsnachweis prüft man drei Ebenen: Collector erreichbar, erwartete Quellen senden, Ereignisse kommen im Backend passend an. Der Status Online allein beantwortet nur einen Teil dieser Prüfung.

Dieses Runbook behandelt bereits bereitgestellte Collector. Das Migrationsrunbook erklärt den Wechsel alter SVA-Log-Collector und das On-Premises-Deployment. Neue AWS-, Azure- oder GCP-Instanzen werden nach der Cloud-Anleitung bereitgestellt. Auf den Appliances dürfen keine zusätzlichen Drittanbieterprogramme installiert werden.

Status und Quellen gemeinsam prüfen

In der Tabellen- oder Kartenansicht den richtigen Collector anhand von Name, Plattform und Tenant zuordnen. Die Statuswerte bedeuten:

• Online: Der Collector hat sich gemeldet; seine Anwendungen sind bereitgestellt und gesund.
• Warning: Einzelne Anwendungen haben sich nicht kürzlich gemeldet oder wurden nicht korrekt bereitgestellt.
• Offline: Ein zuvor bereitgestellter Collector hat sich nicht kürzlich gemeldet.
• Provisioning: Der Collector ist noch nicht ausgerollt.

Last Log Seen zeigt einen Logempfang innerhalb der letzten Stunde. N/A bedeutet, dass in dieser Stunde nichts gemeldet wurde. Bei einer absichtlich stillen Quelle kann das erwartbar sein; bei einer aktiven Firewall muss die Ursache geprüft werden. Ein anderer sendender Host kann den Collector aktiv erscheinen lassen, obwohl eine einzelne wichtige Quelle fehlt.

Den Collector öffnen und auf Summary unter Current Data Sources die Anzahl gesunder Quellen, Warnungen und Quellen ohne Daten vergleichen. Ein Klick auf eine Kennzahl öffnet die entsprechend gefilterte Quellenliste. Unter Health zeigen Eingangsgraph und Syslog-Quellentabelle, wer tatsächlich an den Collector liefert. Der Standardzeitraum ist eine Stunde und lässt sich bis auf 30 Tage erweitern. Damit wird die vorherige Aktivität einer Quelle mit dem aktuellen Ausfall verglichen.

Total Events beschreibt die vom Collector erfassten Ereignisse der letzten 24 Stunden. Data Usage zeigt dagegen die Datennutzung des Tenants im laufenden Monat; diese Zahl darf nicht allein diesem Collector zugerechnet werden. Für eine externe Bestandsaufnahme steht Actions > Export All as CSV zur Verfügung. Status und Download des Exports werden auf Data Exports geprüft.

Zur Quellenabnahme ein erwartetes freigegebenes Ereignis mit Quellsystem und Uhrzeit korrelieren und im vorgesehenen XDR-Suchweg kontrollieren. Eingangsaktivität am Collector beweist weder die passende Normalisierung noch eine Detection. Format- und Parserfragen erklärt das Custom-Parser-Runbook.

Backlog und Durchsatz einordnen

Auf Performance zunächst denselben Zeitraum wie bei der Quellenprüfung wählen. Backlog Age ist das Alter der ältesten zum Backend-Versand wartenden Datei, Backlog Count die Anzahl wartender Dateien. Sophos bündelt und komprimiert Ereignisse vor dem Versand; diese Werte sind keine direkt ablesbare Anzahl verlorener Logs.

Einzelne kurze Ausschläge, bei hoher Last typischerweise unter einer Minute, können vorkommen. Wichtiger ist der Verlauf: Steigen Alter und Anzahl dauerhaft oder während der Arbeitszeit und sinken erst nachts, ist die Verarbeitung beziehungsweise der Versand der aktuellen Last nicht gewachsen. Dann Ausgangsbandbreite, QoS, Proxy und Collector-Auslastung zusammen untersuchen. Ein Neustart erklärt oder beseitigt eine dauerhafte Kapazitätslücke nicht.

Ingress / Egress zeigt empfangene und gesendete Bytes an der primären Netzwerkschnittstelle. Mehr eingehende als ausgehende Bytes sind wegen der Kompression nicht automatisch ein Fehler. Wächst gleichzeitig der Backlog und erreicht Egress ein gleichbleibendes Plateau, prüft man den Uplink und dessen Begrenzungen. Für die Dokumentation MIN, MAX, AVG und LAST mit Zeitraum und betroffenen Quellen erfassen, nicht nur einen isolierten Screenshot.

Der Collector besitzt einen 200-GB-Spool für zeitweise verzögerten oder unterbrochenen Versand. Das ist kein unbegrenzt belastbarer Puffer und keine Ersatzaufbewahrung für SIEM-Retention. Auch die Herstellerangabe bis 200'000 EPS gilt nur für passend konfigurierte Systeme und ist keine Garantie für jede VM oder Leitung. Bei dauerhaft steigendem Rückstau vor einer Ressourcenänderung den tatsächlichen Engpass klären.

Wartungsfenster in UTC festlegen

Normale Softwareupdates erfolgen automatisch, typischerweise alle 24 Stunden bei gesundem verbundenem Collector. Service maintenance umfasst grössere Änderungen wie Betriebssystem- oder Kernel-Upgrades und kann einen Neustart erfordern. Ein wöchentliches Wunschfenster bedeutet nicht, dass jede Woche eine solche Wartung stattfindet.

Auf der Detailseite Maintenance öffnen:

1. Unter Maintenance Window Wochentag und Startzeit in UTC wählen. Den lokalen Termin einschliesslich Sommerzeit getrennt gegenprüfen.
2. Eine Dauer von zwei bis sechs Stunden auswählen. Ein Zeitraum mit geringer Last und erreichbarer Betriebsverantwortung ist sinnvoll.
3. Mit Submit Update speichern und das angezeigte Fenster zurücklesen.
4. Unter Logs > Upcoming bereits geplante Wartungen separat prüfen. Eine spätere Änderung des Wunschfensters verschiebt diese nicht.

Eine anstehende Wartung kann einmal über ihre Checkbox und Defer Maintenance auf die folgende Woche verschoben werden. Status wie Pending, Download Ready, Upgrade Ready, Upgrade Running und Upgrade Running Rebooting zeigen den Ablauf. Unter History wird Complete beziehungsweise Failed mit Zeit und Ergebnis kontrolliert. Ist der Collector zum geplanten Zeitpunkt ungesund oder nicht erreichbar, läuft die Wartung nicht an.

Vor einer Wartung müssen die betroffenen Quellen und ihre Puffer-/Wiederholungsmechanismen bekannt sein. Bei einem Neustart kann Logtransport aussetzen. Auch TCP garantiert nicht allein, dass die sendende Anwendung alle Ereignisse aufbewahrt und erneut überträgt; bei UDP besteht ein entsprechendes Verlustrisiko. Danach frische Ereignisse und mögliche Zeitlücken pro Quelle prüfen. Sophos empfiehlt Supportkontakt, wenn der Collector nach einem Neustart länger als 30 Minuten nicht wieder erreichbar ist.

Admiral zunächst lesend verwenden

Admiral ist die lokale Textkonsole des Collectors. On-Premises wird sie über die VM-Konsole geöffnet. In AWS führt der Weg über die EC2-Instanz zu Actions > Monitor and troubleshoot > EC2 serial console > Connect; dazu braucht man die dafür freigegebenen AWS-Rechte. In Azure liegt Serial console im VM-Bereich unter Help, in GCP Connect to serial console in den Instanzdetails. Ein deaktivierter Zugang wird mit dem Cloud-Verantwortlichen geklärt, statt spontan zusätzliche Rechte oder eine neue Fernzugriffsfläche zu schaffen.

Am Prompt helfen help, Tab-Vervollständigung und ? bei der tatsächlich verfügbaren Syntax. Mit Ctrl-C erhält man eine neue Eingabezeile, ohne einen angefangenen Befehl auszuführen. Die folgenden dokumentierten show-Befehle lesen Status und erzeugen laut Sophos keinen Netzwerkverkehr:

show system info
show network
show routes
show date
show ntp status
show disk
show memory
show uptime

Damit werden Identität, Netzwerte, Route, Uhrzeit, Datenträger und Ressourcen mit dem erwarteten Zustand verglichen. Diagnoseausgaben können interne Netzinformationen enthalten und werden bereinigt in der Betriebsdokumentation abgelegt. Die Befehle vor der Verwendung mit der Hilfe des installierten Builds abgleichen.

run-Befehle können dagegen Aktionen auslösen und Netzwerkverbindungen erzeugen. Für eine gezielte freigegebene Diagnose gibt es etwa run dns check, run ntp check, run tunnel check und run e2e check. run dns check with verbose output liefert ausführlichere DNS-Diagnose. Das ist kein Freibrief für alle angebotenen Aktionen: run reboot und run shutdown planen nach einer Minute einen Neustart beziehungsweise das Abschalten. Befehle des maintenance-Menüs wie Dienstneustarts gehören in einen abgestimmten Support- oder Wartungsvorgang, nicht in eine rein lesende Erstdiagnose.

Konfiguration ändern und Wiederbereitstellung vorbereiten

Actions > Edit Collector Configuration steht nur bei einem laufenden gesunden Collector mit Ready zur Verfügung. Vor dem Speichern bisherige Werte, erforderliche Netzänderungen, betroffene Quellen und einen Wiederbereitstellungsweg festhalten. Ein Konfigurationswechsel kann den Collector unerreichbar machen.

Nach dem Absenden zeigt ein Banner den ausstehenden Change; bis zum Abschluss lässt sich die Konfiguration nicht erneut bearbeiten. Sophos testet die Verbindung und versucht bei einem Fehler die alte Konfiguration wiederherzustellen. Auch dieser automatische Rückweg kann fehlschlagen, etwa bei gleichzeitigen Netzänderungen. Dann kann eine erneute Bereitstellung nötig sein. Ein Erfolgsbanner wird deshalb zusätzlich mit Status, Quellnachweisen und Suchergebnis bestätigt.

Anschliessend die aktualisierten Bereitstellungsdateien über Actions > Download Collector Files sichern. Bei Cloud-Collector auch die zugehörige Cloud-Vorlage beziehungsweise Terraform-Bereitstellung aktualisieren, damit ein Instanzersatz nicht die alte Konfiguration zurückbringt. Beim laufenden On-Premises-Collector muss die neue ISO nicht nachträglich eingehängt werden; sie wird für eine spätere Wiederbereitstellung aufbewahrt.

Actions > Delete ist keine Massnahme zur Eingrenzung eines Offline-Problems. Vor einer geplanten Stilllegung müssen Quellen umgestellt, frische Ereignisse am Ersatz nachgewiesen und Rückweg sowie Aufbewahrung geklärt sein. Für eine Supporteskalation Collector-/Tenant-Zuordnung, Zeitraum, Quellliste, Status und bereinigte Admiral-Ausgaben erfassen. Credentials, vollständige Konfigurationsdateien und unnötige personenbezogene Logs gehören nicht in frei zugängliche Tickets.