Netzwerk-Telemetrie über Sophos XDR Collector aufnehmen

Für OPNsense, pfSense, Netskope SSE und NetScaler ADC führt der dokumentierte Datenweg über einen Sophos XDR Data Collector. Zuerst wird der Collector bereitgestellt, danach die Quelle mit ihrem passenden Syslog-Format angebunden und die tatsächliche Aufnahme geprüft. Eine generische Syslog-Zieladresse allein genügt nicht: Sophos muss das Format und die Ereigniskategorie korrekt zuordnen können.

Die hier beschriebenen netflow-Daten benötigen eine Sophos-Next-Gen-SIEM-Subscription. Netskope und NetScaler liefern zusätzlich andere Schemas; diese sind in der Produktdokumentation nicht pauschal mit derselben SIEM-Fussnote versehen. Für OPNsense und pfSense besteht der geprüfte Umfang dagegen aus Firewall-Verbindungsereignissen im Schema netflow. Die SIEM-Einordnung und die Integrationsgrundlagen helfen bei der Auswahl und Lizenzprüfung.

Collector und Quellumfang vorbereiten

Der Collector muss unter Security Operations > Integrations > Data Collectors für den richtigen Tenant bereitgestellt sein. Das Collector-Runbook erklärt Ressourcen, regionale Uplinks, DNS, Zeitversorgung und die Abgrenzung zur alten SVA sowie zu NDR. Ein neuer XDR Data Collector übernimmt nicht automatisch eine bisherige NDR-Arbeitslast.

Vor der Quellenänderung hält man deren bisherigen Logpfad, das Ziel des neuen Collectors, die zugelassenen Quellnetze und den konkreten Ereignisumfang fest. Eingehende Syslog-Verbindungen werden nur aus den vorgesehenen Netzen freigegeben. Ein dokumentierter UDP-Pfad darf nicht ohne Kompatibilitätsprüfung durch TLS-Syslog oder ein anderes Format ersetzt werden. UDP bestätigt die Zustellung einzelner Meldungen nicht; Verluste müssen beim Abgleich von Quelle und Ziel berücksichtigt werden.

Für jeden Pilot wird ein harmloses, freigegebenes Ereignis mit Uhrzeit und Quellnachweis gewählt. Die Konfiguration eines Receivers oder ein grüner Integrationsstatus beweist weder die Aufnahme jedes Logtyps noch dessen Normalisierung. Deshalb werden Verbindung, Datenfluss und fachlicher Inhalt getrennt abgenommen.

OPNsense: filterlog über UDP/514

Der dokumentierte OPNsense-Weg verarbeitet filterlog-Meldungen über erlaubte oder blockierte TCP-, UDP- und ICMP-Verbindungen. Voraussetzung sind Zugriff auf die OPNsense-Verwaltung und ein erreichbarer XDR Data Collector.

1. Nach Bereitstellung des Collectors in OPNsense die Konfiguration für Remote Logging öffnen. Die Menüführung richtet sich nach der eingesetzten OPNsense-Version; die folgenden Feldwerte sind der von Sophos dokumentierte Umfang.
2. Enabled einschalten und Transport auf UDP(4) setzen.
3. Unter Applications filter (filterlog) wählen. Bei Levels info, notice, warn, error, critical, alert und emergency auswählen. Facilities leer lassen.
4. Unter Hostname die tatsächliche Collector-IP eintragen und Port auf 514 setzen. rfc5424 ausschalten. Als Description ist FilterLog dokumentiert; diese Bezeichnung nicht mit einem anderen Logformat verwechseln.
5. Speichern und ein vorgesehenes, ungefährliches Firewall-Ereignis erzeugen. Die Quellregel muss das erwartete Ereignis tatsächlich protokollieren. Zeitpunkt, Quell-/Zieladresse und Aktion zunächst in OPNsense belegen, danach im Sophos-Schema netflow vergleichen.

Fehlt der Datensatz, werden Quellprotokollierung, filterlog-Auswahl, UDP/IPv4-Weg, Ziel-IP, Port und RFC5424-Einstellung geprüft. Nicht zuerst Schutzregeln deaktivieren, um einen Testfluss zu erzwingen.

pfSense: Firewall Events im BSD-Format

pfSense liefert ebenfalls Firewall-Filterlogs für TCP, UDP und ICMP. Das dokumentierte Format unterscheidet sich von anderen pfSense-Logs und darf nicht durch eine beliebige Remote-Syslog-Auswahl ersetzt werden.

1. In der pfSense-Verwaltung die Log Settings öffnen.
2. Unter General Logging Options BSD (RFC 3164, default) als Logformat wählen.
3. Unter Remote Logging Options Enable Remote Logging aktivieren.
4. Für Source Address ein Interface beziehungsweise Netz wählen, das den Collector erreichen kann. IP Protocol auf IPv4 setzen.
5. Unter Remote log servers die tatsächliche Collector-IP eintragen und bei Remote Syslog Contents Firewall Events auswählen.
6. Nach dem Speichern ein freigegebenes, tatsächlich protokolliertes Firewall-Ereignis erzeugen und im richtigen Sophos-Tenant als netflow nachweisen. Aktion und Verbindungsmerkmale müssen zum Quelllog passen.

Eine andere Source Address kann Routing und Firewall-Zuordnung verändern. Wenn Daten ausbleiben, kontrolliert man deshalb zuerst den Ausgangspfad des gewählten Interfaces, dann den Receiver und das BSD-Format. Andere Logkategorien sind durch diese Anleitung nicht automatisch abgedeckt.

Netskope SSE: Cloud Log Shipper und CEF

Der Netskope-Weg besteht aus zwei Teilen: Netskope Cloud Log Shipper ruft Daten über die Netskope-APIs ab und leitet sie als CEF über Syslog zum Sophos-Collector. Ein direkt am Collector eingetragenes Netskope-Konto ersetzt den Log Shipper nicht.

Die Integration kann Web-/Cloud-Aktivität, Malwarebefunde, Sicherheits- und Policy-Alerts sowie administrative Aktivität liefern. Diese werden unter anderem http, antivirus, thirdpartyalert, nids und auth zugeordnet. Zusätzliches netflow für Verbindungs- und Tunnelereignisse unterliegt der SIEM-Lizenzgrenze.

1. Einen für den eigenen Netskope-Tenant freigegebenen Cloud Log Shipper bereitstellen. Dessen API-Zugang und die gewünschten Ereigniskategorien nach dem zum Shipper passenden Netskope-Verfahren konfigurieren. Die Sophos-Anleitung legt dafür keinen universellen API-Berechtigungssatz fest.
2. Im Shipper das Ausgabe-Plugin: Syslog wählen.
3. Als Mapping Syslog Defaults Mapping verwenden. Es muss der dokumentierte CEF-Datenweg erhalten bleiben; ein frei angepasstes Mapping kann die Normalisierung verändern.
4. Als Ziel die echte IP des Sophos XDR Data Collectors eintragen. Transport und Receiver müssen zur freigegebenen Shipper-/Collector-Konfiguration passen; aus den UDP/514-Vorgaben anderer Produkte folgt hier kein universeller Netskope-Port.
5. Ein passendes Quellereignis auswählen und prüfen, ob der Shipper es aus der API abgerufen und weitergeleitet hat. Danach in Sophos das erwartete Schema und die benötigten Felder vergleichen.

Fehlen nur Netzwerk-Verbindungsdaten, werden zusätzlich Ereignisauswahl und SIEM-Entitlement geprüft. Das Vorhandensein eines HTTP-Datensatzes ist kein Nachweis für die Aufnahme sämtlicher Netskope-Kategorien. Probleme des API-Abrufs und Probleme der Syslog-Weiterleitung werden getrennt untersucht.

NetScaler ADC: Auditlogs mit eindeutigem Zeitbezug

NetScaler ADC, früher Citrix ADC, liefert über Syslog unter anderem Web-/Application-Firewall-Ereignisse (http), Authentisierung und VPN-Sessions (auth) sowie administrative Befehle (managementevent). TCP-Verbindungsaufbau und -abbau werden netflow zugeordnet und benötigen SIEM.

1. Nach Bereitstellung des Collectors im NetScaler die Audit Logging-Konfiguration für Syslog öffnen. Die konkrete Server-/Policy-Zuordnung wird passend zur eingesetzten NetScaler-Version und zum beabsichtigten Umfang eingerichtet; die Sophos-Quelle dokumentiert dafür keinen universellen CLI-Befehl.
2. Als Syslog-Ziel die IP des richtigen Sophos XDR Data Collectors eintragen und den freigegebenen Netzwerkweg kontrollieren.
3. Das Datumsformat auf MM/DD/YYYY einstellen. DD/MM/YYYY ist für die korrekte Aufnahme nicht unterstützt.
4. Ereignisse mit UTC-Zeit übermitteln. Eine nachträgliche Anzeigeumstellung in Sophos repariert keinen falsch interpretierten Quellzeitstempel.
5. Eine freigegebene administrative Änderung oder Anmeldung aus dem vorgesehenen Auditumfang erzeugen. Quellnachweis, Zeit, Benutzer und Aktion mit dem entsprechenden Sophos-Schema vergleichen. Eine gewünschte netflow-Aufnahme benötigt einen eigenen Verbindungstest.

Bei scheinbar fehlenden Ereignissen zuerst Quellzeit und Suchzeitfenster vergleichen. Falsches Datum oder falsche Zeitzone kann einen Datensatz ausserhalb des erwarteten Bereichs erscheinen lassen. Danach Audit-Policy, tatsächlich gesendete Kategorie, Collector-IP und Netzwerkweg prüfen.

Abnahme und kontrollierter Rückbau

Für jede Quelle dokumentiert man mindestens ein reproduzierbares Ereignis, die Quelle, den Tenant, Aufnahmezeit und normalisiertes Schema. Adressen, Ports, Aktion und Benutzer werden nur soweit erwartet und vorhanden verglichen. Keine Detection oder kein Case bedeutet nicht automatisch, dass keine Daten aufgenommen wurden; dafür ist der tatsächliche Datensatz massgeblich.

Nach Quellen- oder Formatänderungen wird die Abnahme wiederholt. Ein Receiver, der gestern gültiges CEF verarbeitet hat, beweist nichts über ein heute verändertes Mapping. Für Zeitabweichungen wird die Uhrzeit der Quelle geprüft, nicht die Schutzfunktion deaktiviert.

Zum Rückbau den neu eingerichteten Remote-Logging-Eintrag beziehungsweise den dafür vorgesehenen Shipper-Ausgabepfad stoppen und den zuvor dokumentierten Logpfad kontrollieren. Gemeinsam verwendete Collector, API-Zugänge und andere Shipper-Ausgaben bleiben bestehen. Erst nach Kontrolle der übrigen Abhängigkeiten die ausschliesslich dafür genutzten Ressourcen entfernen. Das Entfernen einer Integration löscht historische Telemetrie nicht nachweislich und stellt verlorene Ereignisse nicht wieder her.