Sophos Firewall MDR Threat Feeds aktivieren und prüfen

MDR Threat Feeds verbinden den Sophos-MDR-Service mit der Sophos Firewall. MDR-Analysten können IPv4-Adressen, Domains und URLs, die zu einem aktiven Vorfall in der eigenen Umgebung gehören, über Sophos Central an die Firewall übertragen. Die Firewall protokolliert oder blockiert passenden Traffic danach ohne manuelle Pflege einer eigenen Feed-Datei.

Für einen sicheren Rollout braucht es mehr als den Schalter in WebAdmin. Die MDR-Lizenz, Central-Registrierung, lokale Aktion, erforderliche Traffic-Sichtbarkeit, Logziele und der Kontaktweg zum MDR-Team müssen zusammenpassen. Ein lokaler Log and drop-Status beweist noch nicht, dass ein bestimmter IoC angekommen ist oder ein betroffener Datenstrom die nötigen Prüfungen durchläuft.

MDR Threat Feeds in acht Schritten

1. Prüfen, ob das Xstream Protection Bundle auf der Firewall und Sophos MDR Essentials oder Sophos MDR Complete in Sophos Central aktiv sind.
2. Unter System > Sophos Central kontrollieren, ob die richtige Firewall mit dem richtigen Central-Konto registriert ist.
3. In Sophos Central den beabsichtigten Threat response mode und den betrieblichen MDR-Kontaktweg dokumentieren.
4. Unter System services > Log settings für Active threat response mindestens ein nutzbares Logziel aktivieren.
5. Protect > Active threat response > MDR threat feeds öffnen und die Funktion einschalten.
6. Für einen kurzen kontrollierten Pilot Log only, für den produktiven Schutz nach erfolgreicher Abnahme Log and drop wählen und Apply anklicken.
7. Positiv- und Negativprüfung über Log Viewer, Endpoint-Kontext und Sophos Central durchführen.
8. Audit-ID, Verantwortliche, Ausnahmeprozess, Review-Termin und Rollback dokumentieren.

Wichtig: MDR Threat Feeds sind nur ein Teil des MDR-Betriebs. Sie ersetzen weder den MDR-Vertrag noch Endpoint-Sensoren, Incident-Kommunikation, enge Firewall-Regeln oder einen getesteten Wiederherstellungsweg. Eine breite Ausnahme oder unkontrollierte Deaktivierung kann eine laufende Reaktion des MDR-Teams schwächen.

Was MDR Threat Feeds leisten

Sophos MDR-Analysten können Intelligence zu einem aktiven Vorfall direkt über Sophos Central an die Firewall senden. Der Feed ist deshalb kundenspezifischer als eine allgemeine globale Reputationsliste. Ein übertragener IoC kann eine IPv4-Adresse, Domain oder URL sein.

Die lokale Firewall-Aktion bestimmt, was bei einem Match geschieht:

• Log only protokolliert den Treffer, lässt den Traffic aber zu.
• Log and drop protokolliert und verwirft den passenden Traffic.

Sophos empfiehlt für bekannte IoCs die Blockwirkung. Ein kurzer Log only-Pilot kann trotzdem sinnvoll sein, wenn eine bestehende Umgebung zuerst Sichtbarkeit, Logging und mögliche Nebenwirkungen prüfen muss. Dieser Pilot braucht ein festes Enddatum. Ohne geplante Umstellung bleibt sonst eine aktive MDR-Integration dauerhaft ohne lokale Blockwirkung.

Der Threat response mode in Sophos Central und die lokale Feed-Aktion sind zwei verschiedene Ebenen. Der Central-Modus legt fest, welche Reaktionsbefugnisse das MDR-Team besitzt. Log only oder Log and drop legt fest, wie die Firewall einen bereits übertragenen IoC behandelt. Beide Einstellungen werden vor dem Rollout mit dem MDR-Vertrag und dem internen Incident-Prozess abgeglichen.

Voraussetzungen sauber prüfen

Lizenz und Sophos Central

MDR Threat Feeds benötigen auf der Firewall das Xstream Protection Bundle. Zusätzlich braucht es Sophos MDR Essentials oder Sophos MDR Complete in Sophos Central. Das Xstream-Bundle allein enthält keinen vollständigen MDR-Service.

Die Firewall muss im richtigen Sophos-Central-Konto registriert sein. Unter System > Sophos Central werden Registrierung und die Weitergabe von Reports und Logs geprüft. Den vollständigen Verbindungsablauf erklärt Sophos Firewall mit Sophos Central verbinden.

Vor dem Aktivieren müssen auch Zuständigkeiten geklärt sein:

• Wer darf den Threat response mode in Central ändern?
• Wer nimmt einen MDR-Anruf oder eine Rückfrage ausserhalb der Bürozeit an?
• Wer darf eine Ausnahme genehmigen?
• Wo werden Audit-ID, Incident-ID und technische Beweise dokumentiert?
• Welche Systeme dürfen bei bestätigter Kompromittierung isoliert werden?

Logziele aktivieren

Unter System services > Log settings wird in der Zeile Active threat response mindestens eines dieser Ziele aktiviert:

• Local reporting für Log Viewer und lokale Reports
• ein konfigurierter Syslog server für SIEM oder SOC
• Central reporting für Sophos Central

Die Spalte Central reporting erscheint erst, wenn auf der Sophos-Central-Seite Send reports and logs to Sophos Central aktiviert ist. XGS 87/87w und 107/107w unterstützen kein lokales Reporting; dort braucht es Central Reporting oder Syslog.

Für Benachrichtigungen wird zusätzlich System services > Notification list geprüft. Die Aktivierung eines Logziels beweist nur den Transportweg, nicht die korrekte Alarmbearbeitung.

Sichtbarkeit für IP, Domain und URL

Ein IoC wirkt nur auf Traffic, den die Firewall passend verarbeiten kann. Für weitergeleiteten Ziel-IP-Traffic ist eine passende Firewall-Regel nötig. Domain-Matches benötigen in der betreffenden Regel Application Classification oder eine IPS-Policy. Für einen vollständigen HTTPS-URL-Pfad braucht es Web Proxy mit Entschlüsselung oder DPI mit passender SSL/TLS-Inspection-Regel.

Systemgerichteter Traffic zu Diensten unter Administration > Device access, etwa WebAdmin, VPN Portal und VPN, kann anhand einer bösartigen Quell-IPv4-Adresse geprüft werden. Bei eingehendem weitergeleitetem DNAT- oder WAF-Traffic muss für die erwartete Logsichtbarkeit unter System services > Log settings > Active threat response zusätzlich Remote source match (inbound traffic) aktiviert sein.

Die allgemeine Traffic-, Modul- und Inspection-Logik steht in Sophos Firewall Threat Feeds einrichten und sicher betreiben. Dort wird auch erklärt, warum eine Domain- oder URL-Erkennung ohne die passende Klassifizierung beziehungsweise Entschlüsselung ausbleiben kann.

MDR Threat Feeds konfigurieren

1. Mit einem persönlichen Administratorkonto an WebAdmin anmelden.
2. Protect > Active threat response > MDR threat feeds öffnen.
3. MDR threat feeds einschalten.
4. Als Action für einen terminierten Pilot Log only oder nach erfolgreicher Abnahme Log and drop wählen.
5. Mit Apply speichern.
6. Seite neu laden und kontrollieren, ob Schalter und Action gespeichert sind.
7. Im Audit Trail Zeitstempel, Administrator und Änderung prüfen.
8. In Sophos Central kontrollieren, ob die Firewall online ist und MDR dem richtigen Kunden beziehungsweise Mandanten zugeordnet ist.

Nicht gleichzeitig Logging, Inspection, Ausnahmen und Action grossflächig ändern. Ein gestufter Rollout macht sichtbar, welche Änderung einen Treffer oder eine Nebenwirkung verursacht hat.

Wirkung belastbar abnehmen

Sophos veröffentlicht keinen allgemeinen harmlosen MDR-Testindikator. Es ist deshalb keine gute Abnahme, eine echte Malware-Domain oder bekannte schädliche IP aufzurufen. Die technische Kontrolle wird in mehrere beweisbare Ebenen getrennt.

Konfiguration und Transport

1. MDR-Schalter und gewünschte Action auf der Firewall prüfen.
2. Central-Registrierung und MDR-Lizenz kontrollieren.
3. Active-Threat-Response-Logging für das erwartete Ziel bestätigen.
4. In Central prüfen, ob MDR- oder Firewall-Tasks erfolgreich verarbeitet wurden.
5. Bei einem echten MDR-Vorfall den erwarteten IoC und die zugehörige Audit-ID mit dem MDR-Team abgleichen.

Die Sophos Central Firewall Task Queue zeigt MDR- und API-Aufträge. Success bestätigt die Verarbeitung des Central-Tasks, aber noch nicht die Wirkung auf einen konkreten Datenstrom. Bei Partial Success oder Failed werden betroffene Firewall, Entity, Action und Credential ID gesichert und mit der lokalen Konfiguration verglichen.

Treffer im Log Viewer untersuchen

Unter Log viewer > Active threat response werden mindestens diese Informationen gesichert:

• Zeitstempel, Firewall und bei HA der verarbeitende Node
• Action und Feedname
• Source- und Destination-IP, Domain oder URL
• Ports und Protokoll
• Event-ID und weitere Detailfelder
• bei MDR die audit_ID

Mit Synchronized Security kann die Firewall bei verwalteten Windows-Endpoints zusätzlich Benutzer, Host und Prozess zeigen. Im Log Viewer sind dafür Process user und Executable sowie in der Detailansicht host_process_user, endpoint_id und execution_path relevant. Auf macOS erscheinen diese Prozessdetails nicht; dort wird der Endpoint über die Source-IP und Central-Daten zugeordnet.

Die lokale Zusammenfassung steht unter Reports > Network & threats > Active threat response in der Liste Synchronized IoC. Die Übersicht der Sophos-Firewall-Dienste und Logdateien ordnet zusätzlich atr.log ein. Ein einzelner Logeintrag wird nie isoliert bewertet: Firewall-, DNS-, Web-, IPS-, Endpoint- und Central-Ereignisse desselben Zeitfensters gehören zusammen.

Positiv- und Negativprüfung

Ein produktiver Pilot sollte mindestens diese zwei Fälle enthalten:

1. Positiv: Ein realer, vom MDR-Team bestätigter IoC oder Incident erzeugt auf der erwarteten Firewall einen nachvollziehbaren Eintrag mit korrekter Action und Audit-ID.
2. Negativ: Ein vergleichbarer legitimer Geschäftsprozess bleibt erreichbar und erzeugt keinen unbeabsichtigten MDR-Block.

Ohne echten Vorfall wird nicht künstlich ein MDR-IoC erzeugt. Stattdessen werden Konfiguration, Task-Verarbeitung, Logtransport und der Kommunikationsweg geprüft. Für einen vollständig kontrollierbaren Traffic-Test eignet sich ein eigener Third-Party-Pilot-Feed besser als ein fremdes schädliches Ziel.

MDR-Treffer als Incident behandeln

Ein MDR-Treffer ist ein starkes Signal, aber der Logeintrag allein erklärt noch nicht den vollständigen Angriffspfad. Ein ruhiger Ablauf ist:

1. Zeitpunkt, Action, IoC, Feedname, Event-ID und audit_ID sichern.
2. Betroffenen Host und Benutzer über Source-IP, DHCP, Synchronized Security und Endpoint-Daten bestimmen.
3. In Sophos Central den zugehörigen MDR-Fall, die Detection und weitere Geräteereignisse öffnen.
4. Firewall-, DNS-, Web-, IPS- und Endpoint-Logs im gleichen Zeitfenster korrelieren.
5. Mit dem MDR-Team klären, warum der IoC hinzugefügt wurde und welche Reaktion vorgesehen ist.
6. Bei bestätigter Kompromittierung den internen Incident-Response-Ablauf auslösen.
7. Erst danach über Bereinigung, zusätzliche Regeln oder eine enge Ausnahme entscheiden.

Die Audit-ID identifiziert die MDR-Analystenaktion. Sie ist in der Admin-Detailansicht des Log Viewer und unter My Products > Firewall management > Tasks Queue in Sophos Central sichtbar. Bei einer Rückfrage an MDR gehört sie zusammen mit Firewall-Seriennummer, Zeitpunkt, IoC, Event-ID und Incident-ID in den Fall.

Ausnahmen kontrolliert verwalten

Unter Protect > Active threat response > Add threat exclusions können Host-/Netzwerk- sowie Threat-Ausnahmen angelegt werden. Diese Ausnahmen gelten modulübergreifend. Eine Ausnahme für einen MDR-Treffer kann damit auch X-Ops, NDR oder Third-Party Threat Feeds schwächen.

Vor einer Ausnahme werden IoC, betroffener Geschäftsprozess, MDR-Fall und False-Positive-Bestätigung dokumentiert. Die Ausnahme bleibt so eng wie möglich und erhält Grund, Owner, Ticket sowie Review- oder Ablaufdatum. Ganze Client-Netze oder breite Domainbereiche sind keine geeignete schnelle Reparatur.

Threat-Feed-Konfigurationen lassen sich nicht separat importieren oder exportieren; Threat Exclusions hingegen schon. Die MDR-Feed-Einstellungen können auch nicht über Import existing configuration in die initiale Konfiguration einer neuen Central-Firewall-Gruppe übernommen werden. Nach Migration, Restore oder Austausch werden Funktion, Action, Logging und Central-Zuordnung deshalb explizit neu geprüft.

Wenn kein MDR-Treffer erscheint

Die Prüfung beginnt nicht mit einem Service-Neustart. Zuerst werden die Schichten getrennt:

1. Stimmen MDR-Lizenz, Central-Konto, Firewall-Registrierung und Threat response mode?
2. Ist MDR Threat Feeds lokal aktiv und die Action gespeichert?
3. Wurde der betreffende IoC vom MDR-Team tatsächlich für diese Umgebung übertragen?
4. Zeigt die Central Task Queue Success, Partial Success, Failed oder noch Pending?
5. Sind Active-Threat-Response-Logs lokal, an Syslog oder in Central aktiviert?
6. Läuft der Traffic über die erwartete Firewall, Regel und Inspection?
7. Ist der IoC in Active-Threat-Response-, Web- oder SSL/TLS-Ausnahmen enthalten?
8. Stimmen Zeitfenster und bei HA der untersuchte Node?

Für Engine- und Feedstatus kann atr.log zusammen mit Log Viewer und Central Task Queue zeitlich korreliert werden. Logs werden nur gelesen; undokumentierte Änderungen an Feeddaten, Datenbanken oder Services sind kein Standardschritt. Bleibt die Ursache offen, werden CTR, relevante Logs, Task-ID, Audit-ID, Build und Zeitpunkt für Sophos MDR beziehungsweise Sophos Support gesichert.

Rollback und Änderungskontrolle

Vor der Aktivierung werden vorheriger Schalterstatus, Action, Logziele und vorhandene Ausnahmen dokumentiert. Bei einer unerwarteten Geschäftsbeeinträchtigung wird nicht sofort eine breite Ausnahme gesetzt.

1. Betroffenen Treffer und Business-Impact sichern.
2. MDR-Team über Audit-ID und Incident informieren.
3. Wenn fachlich freigegeben, die lokale Action vorübergehend von Log and drop auf Log only zurücksetzen.
4. Nur wenn auch das nicht genügt und MDR zustimmt, den Feed kontrolliert auf den dokumentierten Vorzustand zurücksetzen.
5. Nach jeder Änderung denselben Geschäftsprozess und die Logwirkung erneut prüfen.
6. Ursache beheben und den produktiven Schutz mit neuem Review-Termin wiederherstellen.

In HA-Umgebungen werden Konfiguration und Status auf dem aktuellen Primary geprüft. Logs liegen auf dem Node, der den Traffic verarbeitet hat. Nach einem kontrollierten Failover werden Central-Verbindung, Feedstatus, neue Logeinträge und echter Traffic erneut abgenommen; eine unterbrechungsfreie MDR- oder Logkontinuität wird nicht vorausgesetzt.

Checkliste

• Xstream Protection Bundle aktiv
• Sophos MDR Essentials oder MDR Complete aktiv
• Firewall im richtigen Central-Konto registriert
• Threat response mode und MDR-Kontaktweg dokumentiert
• Active-Threat-Response-Logziel aktiviert
• MDR Threat Feeds eingeschaltet
• Action bewusst gewählt und Pilot terminiert
• Traffic-Sichtbarkeit für IPv4, Domain und URL geprüft
• Remote source match für DNAT/WAF bei Bedarf aktiviert
• Task Queue und lokaler Status verglichen
• Audit-ID und Incident-Prozess bekannt
• Endpoint-Kontext und Plattformgrenzen geprüft
• Ausnahmen mit Owner und Review-Datum versehen
• Rollback und HA-Prüfung dokumentiert

Häufige Fragen