Sophos Firewall ATP: X-Ops Threat Feeds konfigurieren

Die frühere Advanced Threat Protection (ATP) heisst in aktuellen SFOS-Versionen Sophos X-Ops Threat Feeds. Die Firewall gleicht ausgehenden Traffic mit einer von Sophos gepflegten Datenbank bekannter schädlicher IP-Adressen, Domains und URLs ab. So kann sie beispielsweise verhindern, dass ein infizierter Client einen bekannten Command-and-Control-Server erreicht.

Für den produktiven Einsatz ist Log and drop das Ziel. Die Funktion ist standardmässig ausgeschaltet und blockiert nach dem Aktivieren nur dann, wenn diese Aktion ausgewählt wurde.

X-Ops Threat Feeds einrichten

Vor dem Aktivieren müssen Network Protection und Web Protection lizenziert sein. Beide Funktionen sind im Standard- und Xstream-Protection-Bundle enthalten; eine zusätzliche Sophos-Central-Lizenz ist für X-Ops nicht erforderlich.

1. System services > Log settings öffnen.
2. In der Zeile Active threat response mindestens Local reporting aktivieren. Je nach Betrieb zusätzlich das gewünschte Syslog-Ziel und Central reporting auswählen.
3. Protect > Active threat response > Sophos X-Ops threat feeds öffnen.
4. Sophos X-Ops threat feeds einschalten.
5. Als Action entweder Log only für einen kurzen kontrollierten Pilot oder Log and drop für den produktiven Schutz wählen.
6. Unter Advanced security settings zwischen Inspect untrusted content und Inspect all content entscheiden.
7. Mit Apply speichern.
8. Danach Einstellung, Logziele und vorhandene Ausnahmen kontrollieren.

XGS 87/87w und 107/107w unterstützen kein lokales Reporting. Auf diesen Modellen wird stattdessen Central Reporting oder ein Syslog-Server verwendet. Die Spalte Central reporting erscheint erst, nachdem unter Sophos Central die Option Send reports and logs to Sophos Central aktiviert wurde.

Sophos empfiehlt, bekannte IoCs zu blockieren und nicht nur zu protokollieren. Für eine neue oder bisher nicht überwachte Umgebung kann Log only trotzdem für eine kurze, klar terminierte Beobachtungsphase sinnvoll sein. Diese Phase braucht einen Verantwortlichen und ein Umstellungsdatum; sonst bleibt die Funktion leicht dauerhaft ohne Blockwirkung aktiv.

Was X-Ops schützt – und was nicht

X-Ops prüft bekannte schädliche Ziele im ausgehenden, weitergeleiteten Traffic. Ein typischer Treffer entsteht, wenn ein Client oder Server eine bekannte Malware-, Phishing- oder C2-IP, -Domain oder -URL aufrufen will. Je nach Aktion wird der Versuch nur protokolliert oder direkt verworfen.

X-Ops unterstützt dagegen keine lokalen oder entfernten Source-Matches. Es blockiert daher nicht automatisch bekannte Angreifer-IP-Adressen, die als Quelle auf eine DNAT- oder WAF-Veröffentlichung, das WebAdmin oder ein VPN-Portal zugreifen. Für solche Einsatzfälle passen MDR-, NDR- oder Third-Party Threat Feeds sowie restriktive Firewall-, WAF- und Device-Access-Regeln.

Auch IPS, Malware Scanning und Zero-Day Protection lösen andere Aufgaben. X-Ops arbeitet indikatorbasiert: Ein Ziel muss bereits als schädlicher IoC bekannt sein. IPS erkennt dagegen bekannte Angriffsmuster im Traffic. Beide Funktionen ergänzen sich, ersetzen einander aber nicht.

Welche Voraussetzungen für Treffer gelten

Die Aktivierung allein garantiert noch nicht, dass die Firewall jeden IP-, Domain- oder URL-Indikator sehen kann. Entscheidend ist, welche Information im jeweiligen Netzwerkpfad sichtbar ist.

IP-Adressen

Für einen Ziel-IP-Treffer muss der ausgehende Traffic durch eine passende Firewall-Regel laufen. Die Firewall kann die Zieladresse direkt mit dem X-Ops-Feed vergleichen; eine TLS-Entschlüsselung ist dafür nicht erforderlich.

Domains

Für Domain-Erkennung muss in der betroffenen Firewall-Regel Application Classification aktiv oder eine IPS-Policy ausgewählt sein. Fehlt beides, kann die notwendige Klassifizierung im betreffenden Traffic-Pfad ausbleiben.

Vollständige URLs über HTTPS

Eine URL enthält neben der Domain auch einen Pfad, zum Beispiel https://example.invalid/download/payload.exe. Bei verschlüsseltem HTTPS-Traffic sieht die Firewall ohne Entschlüsselung über SNI normalerweise nur die Domain, nicht den Pfad /download/payload.exe.

Soll der vollständige URL-Indikator geprüft werden, braucht es Web Proxy mit aktivierter HTTPS-Entschlüsselung oder eine passende SSL/TLS-Inspection-Regel mit Decrypt. TLS Inspection sollte nicht nur für X-Ops unkontrolliert global aktiviert werden: Zertifikatsverteilung, Datenschutz, Ausnahmen, Applikationskompatibilität und Performance gehören in einen eigenen Rollout.

Prüfumfang bewusst wählen

Unter Advanced security settings legt man fest, wie breit X-Ops den Traffic untersucht:

• Inspect untrusted content beschränkt die Prüfung auf Traffic mit nicht vertrauenswürdigen Quellen oder Zielen. Diese Einstellung benötigt weniger Ressourcen und ist ein sinnvoller Startpunkt, wenn Last und Nebenwirkungen noch nicht bekannt sind.
• Inspect all content prüft vertrauenswürdigen und nicht vertrauenswürdigen Traffic. Das bietet mehr Abdeckung, kann aber besonders in stark ausgelasteten Umgebungen die Performance beeinflussen.

Für besonders schützenswerte Client-, Server- oder Administrationsnetze kann Inspect all content sinnvoll sein, wenn die Appliance genügend Reserve besitzt. Die Änderung sollte in einem Wartungsfenster erfolgen. Anschliessend werden CPU-Auslastung, Latenz, Durchsatz und Helpdesk-Rückmeldungen mit dem vorherigen Zustand verglichen.

Aktion und Prüfumfang sollten bei einer Einführung möglichst nicht gleichzeitig mehrfach verändert werden. Ändert man zuerst die Sichtbarkeit und danach die Blockaktion, lässt sich bei einem Problem besser nachvollziehen, welche Einstellung die Ursache war.

Wirkung und Logging kontrollieren

Nach dem Speichern reicht es nicht, nur den aktiven Schalter zu prüfen. Eine belastbare Betriebskontrolle umfasst drei Ebenen:

1. Konfiguration: X-Ops ist eingeschaltet, die gewünschte Action und der Prüfumfang sind gespeichert.
2. Sichtbarkeit: Firewall-Regel, Application Classification beziehungsweise IPS und bei vollständigen HTTPS-URLs die TLS-Entschlüsselung passen zum Indikatortyp.
3. Nachweis: Unter Log viewer > Active threat response beziehungsweise im konfigurierten Central- oder Syslog-Ziel sind Treffer auffindbar.

Für eine lokale Zusammenfassung öffnet man Reports > Network & threats > Active threat response. Das gleichnamige Widget im Control Center zeigt Status und Anzahl blockierter Threats; die konkrete Aktion und die Verbindungsdetails prüft man im Report oder Log Viewer.

Der technische Syslog-Logtyp heisst weiterhin ATP, obwohl die Oberfläche heute X-Ops und Active Threat Response verwendet. Je nach Verarbeitungspfad kann log_component auf Firewall, DNS, IPS oder Web zeigen. Für eine Untersuchung sind Zeitstempel, Aktion, Source, Destination, Ports, Domain oder URL, Threat-Name, Feedname und Event-ID besonders hilfreich.

In der Advanced Shell ist ips.log das wichtigste Engine-Log für Active Threat Response. garner.log hilft bei der Verarbeitung und Weiterleitung von Events, insbesondere wenn Central Reporting unvollständig wirkt. Die Einordnung dieser Dateien und der sichere SSH-Zugriff stehen in der Übersicht der Sophos-Firewall-Dienste und Logdateien.

Es gibt keinen allgemein dokumentierten harmlosen X-Ops-Testindikator. Deshalb sollte man nicht absichtlich eine echte Malware-Domain oder bekannte schädliche IP aufrufen. Wenn ein reproduzierbarer Funktionstest nötig ist, ist ein eigener Third-Party-Pilot-Feed mit einem kontrollierten Testziel die sicherere Methode. Für X-Ops selbst werden Konfiguration und Sichtbarkeit geprüft; die tatsächliche Blockwirkung bestätigt der nächste reale, sorgfältig untersuchte Treffer.

X-Ops-Alarm untersuchen

Ein blockierter IoC ist ein starkes Signal, aber noch keine vollständige Incident-Analyse. Die Zieladresse kann beispielsweise durch Malware, einen Phishing-Link, eine kompromittierte Browser-Erweiterung oder einen legitimen, aber falsch eingestuften Dienst kontaktiert worden sein.

Ein sinnvoller Ablauf ist:

1. Zeitstempel, Firewall beziehungsweise HA-Knoten, Aktion und vollständige Logdetails sichern.
2. Source-IP, Ziel-IP, Domain oder URL, Ports, Protokoll, Threat-Name und Feedname erfassen.
3. Im selben Zeitfenster Firewall-, DNS-, IPS- und Web-Logs korrelieren.
4. Den internen Client über DHCP-Lease, Benutzerzuordnung oder Endpoint-Daten identifizieren.
5. Auf dem betroffenen System nach zugehörigem Prozess, Browser-Verlauf, Download und weiteren Security-Events suchen.
6. Bei bestätigter Kompromittierung das System isolieren und nach dem internen Incident-Response-Runbook behandeln.
7. Erst nach der Analyse entscheiden, ob Bereinigung, ein zusätzlicher Block oder eine eng begrenzte Ausnahme nötig ist.

Mit Synchronized Security können bei unterstützten Windows-Endpoints zusätzlich Prozessbenutzer, Endpoint-ID und Ausführungspfad erscheinen. Auf macOS stehen diese Prozessdetails nicht zur Verfügung; dort bleibt die Source-IP für die Zuordnung besonders wichtig.

Bekannter HA-Fehlalarm NC-170292

Auf einem HA-System mit SFOS 21.5.1 MR1 Build 261 kann NC-170292 in Sophos Central einen falschen Advanced threat detected-Alarm mit Raw Logs auslösen. Eine E-Mail der Firewall kann gleichzeitig ohne verwertbare Details eintreffen.

Diese Einschränkung gilt nicht pauschal für andere Builds oder Standalone-Firewalls. Ein Alarm wird deshalb zuerst wie oben beschrieben gesichert und untersucht. Passt das System exakt zum betroffenen Build und fehlen belastbare Trefferdetails, nennt Sophos den Neustart des Garner-Dienstes als temporären Workaround. Da die Known-Issues-Liste für diesen Fehler keinen konkreten CLI-Befehl nennt, sollte der Neustart nur nach freigegebenem Support- oder Wartungsablauf erfolgen. Bei wiederkehrenden Meldungen gehören HA-Status, Firmware-Build, Zeitstempel und garner.log in den Sophos-Supportfall.

Ausnahmen nur nach bestätigter Analyse

Unter Protect > Active threat response > Add threat exclusions können Host and network exclusions sowie Threat exclusions für IP-Adressen, Domains oder URLs angelegt werden. Eine solche Ausnahme gilt nicht nur für X-Ops, sondern für alle Active-Threat-Response-Module. Eine schnelle Ausnahme kann daher gleichzeitig den Schutz durch MDR, NDR oder Third-Party Threat Feeds schwächen.

Wenn ein False Positive bestätigt ist, sollte nur der kleinste erforderliche Indikator ausgenommen werden. Zur Ausnahme gehören Grund, Ticket, verantwortliche Person und Review-Datum. Ganze Client-Netze oder breite Domainbereiche vorsorglich auszuschliessen, beseitigt zwar den sichtbaren Alarm, aber auch einen grossen Teil der Schutzwirkung.

Nach der Änderung wird derselbe Geschäftsprozess erneut geprüft und im Log Viewer kontrolliert, ob nur der beabsichtigte Treffer ausbleibt. Andere X-Ops-Ereignisse müssen weiterhin protokolliert beziehungsweise blockiert werden.