Sophos Firewall Threat Feeds einrichten und sicher betreiben

Sophos Firewall Threat Feeds importieren bekannte bösartige IP-Adressen, Domains und URLs automatisch als Indicators of Compromise (IoCs). Für einen sicheren Rollout gilt: Feed zuerst im Monitor-Modus beobachten, Treffer und Nebenwirkungen prüfen und erst danach auf Block umstellen.

Dieser Artikel behandelt vor allem Third-Party Threat Feeds wie die Feeds von Cybora. Die Funktion wurde mit Sophos Firewall v21 eingeführt.

Threat Feed einrichten

Third-Party Threat Feeds benötigen das Xstream Protection Bundle, aber keine zusätzliche Sophos-Fusion-Lizenz. Die Firewall muss die Feed-URL per DNS und HTTPS erreichen können.

1. System services > Log settings öffnen.
2. Unter Active threat response mindestens ein unterstütztes Logziel aktivieren. Für den lokalen Log Viewer ist das Local reporting. XGS 87/87w und 107/107w unterstützen kein lokales Reporting; dort Sophos Fusion (ehemals Sophos Central) oder einen Syslog-Server verwenden.
3. Für sichtbare Treffer auf eingehenden DNAT- und WAF-Traffic zusätzlich Remote source match (inbound traffic) aktivieren. Diese Option ist standardmässig ausgeschaltet.
4. Protect > Active threat response > Third-party threat feeds > Add öffnen.
5. Einen eindeutigen Namen und eine Beschreibung eintragen, zum Beispiel:
   • Pilot: Name cybora-premium-ipv4-monitor, Description Cybora Premium IPv4 - Pilot
   • Geprüfter produktiver Feed: Name cybora-premium-ipv4, Description Cybora Feed - Premium
6. Als Indicator type IPv4 address, Domain oder URL wählen. Liefert eine Quelle mehrere Typen, wird pro Typ ein eigener Feed angelegt.
7. Action für die Einführung auf Monitor setzen. Nach einer geprüften Beobachtungsphase kann auf Block umgestellt werden.
8. Unter Position für einen Pilot-Feed Top wählen, damit sein Treffer nicht hinter einem anderen Third-Party Feed verborgen bleibt. Bottom eignet sich für einen nachrangigen Feed, dessen Überschneidungen bereits bekannt sind.
9. Unter External URL die passende Adresse aus der Avanet-Feed-Liste beziehungsweise vom eigenen Anbieter hinterlegen. Die URL muss die Plain-Text-Datei direkt liefern. Antwortet der Endpunkt stattdessen beispielsweise mit HTTP 302, führt SFOS dies als Connection error. Die Datei enthält einen Indikator pro Zeile.
10. Unter Authorization No authentication, API key oder Basic authentication wählen. Ein API-Key kann im Header oder in Query parameters übertragen werden; sein Wert und das Passwort für Basic Authentication unterstützen jeweils höchstens 64 Zeichen. Zugangsdaten gehören nicht in Tickets oder Screenshots.
11. Validate server certificate aktivieren. Bei einem öffentlichen Zertifikat muss die ausstellende CA unter Certificates > Certificate authorities vorhanden sein; bei einer privaten CA wird deren Zertifikat zuerst importiert.
12. Ein Polling interval wählen, das zum Update-Intervall des Anbieters passt.
13. Test connection ausführen und mit Save speichern.

Danach Sync status, Last updated, die Anzahl Threat indicators und die freie Storage quota prüfen. Success bestätigt den Abruf, aber noch nicht, dass der erwartete Traffic tatsächlich erkannt oder blockiert wird. Diese Wirkung muss im Log Viewer separat validiert werden.

Feed und Aktion richtig wählen

Unterstützte Indikatoren

Ein Feed enthält genau einen dieser Typen:

• IPv4 address: Scanner, Botnetze, kompromittierte Systeme oder C2-Server
• Domain: Malware-, Phishing- oder Command-and-Control-Domains
• URL: konkrete schädliche Pfade oder Download-Links

Der Feed muss als Plain-Text-Datei mit einem Indikator pro Zeile vorliegen. IP-Ranges, IPv6-Adressen, Netzwerke, Wildcard-Domains und reguläre Ausdrücke werden in Third-Party Threat Feeds nicht als Ersatz für einzelne unterstützte IoCs verwendet.

SFOS setzt keine feste Anzahl von IoCs pro Third-Party Feed voraus. Die praktisch nutzbare Grösse wird durch die modellabhängige Storage quota begrenzt. Nach dem Import deshalb freie Quota, Anzahl Threat indicators und erfolgreichen Abruf gemeinsam prüfen.

Eine grosse Liste ist nicht automatisch gut. Herkunft, Aktualität, Update-Intervall, False-Positive-Risiko und Treffer in der eigenen Umgebung sind wichtiger als die reine Anzahl. Bleibt ein Feed dauerhaft ohne eigenen Nutzen, belegt er nur Speicher.

Monitor vor Block

Monitor protokolliert Treffer, lässt den Traffic aber zu. Das zeigt, welche Quellen, Ziele und Dienste betroffen wären. Block protokolliert und verwirft den passenden Traffic.

Für einen neuen Feed ist dieser Ablauf sinnvoll:

1. Feed oben in der Third-Party-Liste positionieren.
2. Mit Monitor starten.
3. Treffer und mögliche False Positives während einer repräsentativen Phase prüfen.
4. Verantwortliche Person und Ausnahmeprozess dokumentieren.
5. Erst danach auf Block umstellen.

Ein gut kuratierter IPv4-Feed für stark exponierte Dienste kann schneller produktiv eingesetzt werden als ein Domain- oder URL-Feed. Letztere treffen häufiger auf gemeinsam genutzte Infrastruktur, CDNs oder Weiterleitungen und brauchen deshalb eine besonders sorgfältige Prüfung.

Vor der Umstellung auf Block werden Feedname, IoC-Anzahl, Position und der bisherige Trefferumfang festgehalten. Verursacht die Änderung unerwartete Ausfälle, wird Action im selben Feed sofort wieder auf Monitor gesetzt und der zuvor betroffene Traffic erneut geprüft. Bei einem defekten oder unkontrollierbaren Feed kann er vorübergehend deaktiviert werden. Eine globale Threat Exclusion ist kein gleichwertiger Rollback, weil sie auch MDR, NDR und Sophos X-Ops betrifft.

Reihenfolge und Namen

Active Threat Response verarbeitet die Module in dieser Reihenfolge: MDR, NDR Essentials, Sophos X-Ops und danach Third-Party Threat Feeds. Bei Log and drop beendet ein Treffer in einem früheren Modul die weitere Prüfung. Bei Log only beziehungsweise Monitor protokolliert die Firewall dagegen einzelne Ereignisse für MDR, X-Ops und Third-Party Threat Feeds.

Innerhalb der Third-Party Feeds wertet die Firewall die Listen für Block und Monitor getrennt in der angezeigten Reihenfolge aus. Sie protokolliert den ersten Treffer je Liste und blockiert anhand des ersten Treffers in der Block-Liste. Produktive Feeds, Pilot-Feeds und temporäre Incident-Listen sollten daher klar benannt und geordnet sein:

• cybora-premium-ipv4-block
• cybora-standard-domain-monitor
• incident-2026-06-c2-ipv4

Ein guter Name zeigt Anbieter oder Zweck, Indikatortyp und Aktion. Das spart Zeit bei Loganalysen und Reviews.

Threat-Feed-Module unterscheiden

Unter Active threat response liegen mehrere Funktionen mit unterschiedlichen Aufgaben und Lizenzen:

• Sophos X-Ops Threat Feeds: Sophos-eigene Indikatoren; benötigt Network Protection und für die Umsetzung zusätzlich Web Protection. Beide sind im Standard- oder Xstream-Bundle enthalten oder können einzeln lizenziert werden.
• MDR Threat Feeds: IoCs aus Sophos MDR; benötigt das Xstream Protection Bundle sowie MDR Essentials oder MDR Complete in Sophos Fusion. Der eigene Ablauf erklärt die Sophos-Fusion-Anbindung, lokale Action, Audit-ID, Task Queue und Incident-Prüfung.
• Third-Party Threat Feeds: externe IPv4-, Domain- oder URL-Listen; benötigt das Xstream Protection Bundle.
• NDR Essentials: analysiert Traffic mit Machine Learning und benötigt das Xstream Appliance Bundle.
• NDR Active Threat Intelligence: protokolliert von Sophos kuratierte NDR-Muster, benötigt das Xstream Protection Bundle und muss pro Firewall-Regel über Scan with NDR Active threat intelligence aktiviert werden. XGS 87/87w und 88/88w werden nicht unterstützt.

Für Synchronized Security und den zusätzlichen Endpoint-Kontext in Active-Threat-Response-Logs braucht es ausserdem eine Intercept X-Lizenz in Sophos Fusion. Diese Lizenz ist keine Voraussetzung für den Threat Feed selbst, sondern für die Endpoint-Ergänzung mit Host, Benutzer und Prozess.

Synchronized Security ist für das Threat-Feed-Matching optional. Meldet ein verwalteter Sophos Endpoint bei Kontakt zu einem schädlichen Server einen roten Security Heartbeat, kann eine passend konfigurierte Heartbeat-Regel seinen Traffic blockieren; Lateral Movement Protection kann den kompromittierten Endpoint zusätzlich vom internen Netz isolieren. Diese Endpoint-Reaktion ergänzt den Feed und dessen Logs, ersetzt aber weder Feed-Konfiguration noch Firewall-Regel.

Für NDR passt die separate Anleitung Sophos Firewall NDR und Active Threat Response betreiben.

Wirkung auf den Traffic verstehen

IPv4-, Domain- und URL-Traffic

Für weitergeleiteten IPv4-Traffic braucht es eine Firewall-Regel, die den betreffenden Traffic verarbeitet. Systemgerichteter Traffic zu Diensten unter Administration > Device access, etwa WebAdmin, VPN Portal und VPN, wird separat mit Quell-IP-Indikatoren abgeglichen und läuft nicht durch eine Transit-Firewall-Regel.

DNS-Anfragen, welche die Firewall selbst als DNS-Server beantwortet, werden durch das DNS-Modul mit Domain-IoCs abgeglichen. Verwenden Clients einen anderen DNS-Server, muss IPS den DNS-Verkehr sehen. Ein Domain-Feed allein beweist deshalb noch nicht, dass der tatsächliche Resolverpfad geprüft wird.

Domain-Feeds benötigen für weitergeleiteten Traffic zusätzlich Application Classification oder eine IPS-Policy in der Firewall-Regel. Application Classification ist standardmässig eingeschaltet, sollte im betroffenen Regelpfad aber trotzdem kontrolliert werden.

Bei vollständigen URLs über HTTPS muss die Firewall auch den Pfad sehen. Im Web-Proxy-Pfad werden in der Firewall-Regel unter Web filtering die Optionen Use web proxy instead of DPI engine und Decrypt HTTPS during web proxy filtering aktiviert. Im DPI-Pfad bleibt Use web proxy instead of DPI engine deaktiviert; zusätzlich braucht es eine passende SSL/TLS-Inspection-Regel mit Action: Decrypt. Ohne Entschlüsselung sieht die Firewall über SNI nur die Domain, nicht den vollständigen URL-Pfad.

DNAT und WAF ab SFOS 22

Seit SFOS 22 kann die Firewall die Quell-IP von eingehendem, weitergeleitetem Traffic für DNAT und WAF mit MDR-, NDR- und Third-Party Threat Feeds abgleichen. Dadurch lassen sich bekannte Scanner und Botnetze vor veröffentlichten Diensten erkennen.

Damit diese Treffer im Active-Threat-Response-Log erscheinen, muss unter System services > Log settings > Active threat response die Option Remote source match (inbound traffic) aktiviert sein. Sie ist standardmässig ausgeschaltet. Ohne diese Einstellung kann die Blockwirkung vorhanden sein, während die erwarteten DNAT- oder WAF-Ereignisse im Log Viewer fehlen.

Typische Einsatzgebiete

Threat Feeds helfen nicht nur bei ausgehendem Client-Traffic. Gerade öffentlich erreichbare Dienste werden oft innerhalb kurzer Zeit automatisiert gescannt.

• DNAT auf interne Server: Ein IPv4-Feed kann bekannte schlechte Quellen blockieren, bevor sie den veröffentlichten Server erreichen.
• WAF-Veröffentlichungen: Reputationsdaten ergänzen WAF-Regeln gegen Bot-Traffic, CVE-Scans, CMS-Probes und Credential-Stuffing.
• VPN Portal, User Portal und WebAdmin: Diese Dienste werden zuerst über MFA, Quellnetze sowie Device Access und Local Service ACL geschützt. Threat Feeds reduzieren zusätzlich bekannte Angreiferquellen.
• Ausgehender Client-Traffic: Domain- und URL-Feeds können bekannte Malware-, Phishing- und C2-Ziele blockieren.
• Stark gescannte WAN-Adressen: Ein guter IPv4-Feed reduziert automatisiertes Rauschen und entlastet Firewall und Logs.

Threat Feeds ergänzen die Grundabsicherung, ersetzen sie aber nicht. Veröffentlichte Dienste brauchen weiterhin restriktive DNAT- oder WAF-Regeln, nur notwendige Ports, sinnvolle Quell- oder Ländereinschränkungen, IPS beziehungsweise WAF und aktiviertes Logging. Ein Feed ist kein Freipass für breite Any-Regeln. Der übergeordnete Ablauf steht im Sophos Firewall Hardening Hub.

Synchronisation und Betrieb prüfen

Feedabruf und Traffic-Wirkung getrennt testen

Eine erfolgreiche Verbindung und Sync status: Success beweisen nur, dass die Firewall die Liste abrufen und einlesen konnte. Für eine vollständige Prüfung braucht es drei Ebenen:

1. Abruf: Test connection, Sync status, Last updated und Storage quota sind plausibel.
2. Inhalt: Unter Threat indicators ist ein erwarteter IoC vorhanden.
3. Wirkung: Ein kontrollierter Testtraffic erzeugt im Log viewer > Active threat response oder im konfigurierten Sophos-Fusion-/Syslog-Ziel einen Treffer. Je nach Match sind Feedname, Log/Drop, Matchrichtung, Quelle und Ziel beziehungsweise URL sowie Protokoll und Ports nachvollziehbar.

Für einen reproduzierbaren Test kann ein eigener kurzer Pilot-Feed auf einem kontrollierten HTTPS-Server verwendet werden. Er enthält die IPv4-Adresse eines ebenfalls kontrollierten Testziels. Der Feed bleibt auf Monitor, ein Labor-Client baut eine Verbindung zum Testziel auf, und der Administrator prüft den Logeintrag. Keine produktiven Malware-Ziele oder fremden Systeme für Tests aufrufen.

Synchronisation und Storage Quota

In der Feed-Übersicht sind diese Werte für den laufenden Betrieb wichtig:

• Success, Fetching oder Disabled unter Sync status
• erwarteter Zeitstempel unter Last updated
• plausible Anzahl Threat indicators
• ausreichend freie Storage quota
• erfolgreiche manuelle Aktualisierung über Synchronize now

Die Summary zeigt Active feeds, Total threat indicators und Storage quota. Refresh aktualisiert nur diese angezeigten Zähler. Synchronize now ruft dagegen den ausgewählten Feed sofort ab. Einzelne IoCs lassen sich über Threat indicators oder über die Indikatorzahl des betreffenden Feeds öffnen und durchsuchen.

Bei Authentication error sind API-Key oder Zugangsdaten zu prüfen, bei Connection error DNS, Internetzugriff, HTTP-Status und Feed-Server. SSL/TLS error deutet auf Zertifikat oder Zertifikatskette, Failed häufig auf Feedformat oder ungültige Indikatoren.

Ist der Speicher voll, ruft die Firewall den Feed weiterhin im konfigurierten Polling-Intervall ab, aktualisiert die gespeicherte IoC-Liste aber erst wieder, sobald Platz verfügbar ist. Deshalb Feedumfang, Qualität und Priorität prüfen, statt weitere Listen hinzuzufügen. Bei XGS 87/87w, 88/88w und 107/107w stehen für Third-Party Threat Feeds nur 24h, 7d und 30d als Polling-Intervalle zur Verfügung. Ein häufiger aktualisierter Anbieterfeed macht diese Appliance-Grenze nicht unwirksam.

Wenn keine Treffer erscheinen

Sinnvolle Prüfreihenfolge:

1. Feed aktiv, Sync status: Success und erwarteter IoC unter Threat indicators
2. höher priorisierte MDR-, NDR- oder X-Ops-Erkennung für denselben IoC
3. Active-Threat-Response-Logging und bei DNAT/WAF Remote source match
4. passende Firewall-Regel und deren Logging
5. bei Domains Application Classification oder IPS-Policy
6. bei URLs Web Proxy beziehungsweise DPI und SSL/TLS Inspection
7. Threat Exclusions, Web Exclusions und SSL/TLS Exclusion Lists

Um einen erlaubten Domain- oder URL-IoC bis zur verantwortlichen Regel zurückzuverfolgen, unter Log viewer > Web filter nach dem IoC in Category oder direkt nach der Domain suchen und die Detailansicht öffnen. Dort stehen die Firewall Rule ID und die in dieser Regel ausgewählte Web policy. Lautet die passende Policy-Aktion Allow, Regel- und Policy-Reihenfolge prüfen. Eine bewusst gewünschte Sperre wird mit einer eng begrenzten URL Group in einer blockierenden Web Policy umgesetzt, die einer höher priorisierten LAN-to-WAN-Regel zugewiesen ist. Danach denselben Traffic erneut testen.

Beim DPI-Pfad zusätzlich Log viewer > SSL/TLS inspection öffnen, nach der URL in Server name suchen und Action sowie SSL/TLS rule prüfen. Ein URL-IoC benötigt Decrypt. Steht der Treffer auf Don't decrypt, zeigt die Rule ID, welche Ausnahme oder Regel den Traffic an der Entschlüsselung vorbeiführt. Eine schmale URL Group darf erst nach dieser Zuordnung in eine höher priorisierte Decrypt-Regel aufgenommen werden. Der kontrollierte Aufbau ist unter TLS Inspection schrittweise ausrollen beschrieben.

Bleibt ein Feed über eine repräsentative Beobachtungsphase ohne relevanten Treffer, sollte sein Nutzen neu bewertet werden.

False Positives behandeln

Bei einer Fehlblockierung zuerst den Logeintrag öffnen und Feedname, Log/Drop, Matchrichtung, Quelle und Ziel beziehungsweise URL sowie Protokoll und Ports dokumentieren. Danach prüfen, ob der Traffic fachlich legitim ist, den betroffenen Indikator beim Feedanbieter melden und nur eine möglichst enge Ausnahme mit Grund, Verantwortlichem und Review-Datum setzen.

Eine breite Ausnahme für ganze Netze ist keine saubere Lösung. Bei Domain- oder URL-Treffern kann zusätzlich TLS Inspection, Web Policy, DNS Protection oder eine andere Sicherheitsfunktion beteiligt sein.

Eine kontrollierte Ausnahme wird unter Protect > Active threat response > Add threat exclusions angelegt. Host and network exclusions übernehmen vorhandene Host- oder Netzwerkobjekte. Unter Threat exclusions wird eine einzelne IP-Adresse, Domain oder URL eingegeben; ein Eintrag darf höchstens 128 Zeichen lang sein. Nach Add und Apply denselben Traffic erneut testen und im Log Viewer bestätigen, dass nur der erwartete Treffer ausbleibt.

⚠️ Eine Threat Exclusion gilt für alle Active-Threat-Response-Module, nicht nur für den Feed, der den False Positive ausgelöst hat. Vor Apply deshalb Auswirkungen auf MDR, NDR, Sophos X-Ops und Third-Party Threat Feeds prüfen. Eintrag, Grund, Owner und Review-Datum dokumentieren und die Ausnahme wieder entfernen, sobald sie nicht mehr benötigt wird.

Backup und Restore

Ein Firewall-Backup enthält die Third-Party-Feed-Konfiguration, aber nicht die heruntergeladenen Listen. Nach dem Restore ruft die Firewall die Quellen sofort neu ab und wendet die konfigurierte Aktion an. DNS, Internetzugriff, Zertifikatsprüfung und Zugangsdaten müssen deshalb direkt nach der Wiederherstellung funktionieren.

Threat-Feed-Konfigurationen lassen sich nicht separat importieren oder exportieren; Threat Exclusions hingegen schon. Nach einem Restore sollten Feedabruf, IoC-Anzahl und Traffic-Wirkung erneut geprüft werden.

Cybora Threat Feeds für Sophos Firewall

Cybora liefert seine IPv4-, Domain- und URL-Feeds als HTTPS-Textdateien mit einem Indikator pro Zeile. Laut öffentlicher Produktbeschreibung werden dafür OSINT und Community-Quellen, kommerzielle Threat Intelligence, Honeypots, Sensorik und Firewall-Signale zusammengeführt. Das Format passt damit direkt zur Third-Party-Schnittstelle von SFOS; über die tatsächliche Qualität im eigenen Netz entscheidet dennoch der Monitor-Pilot.

Cybora dient hier als konkretes Anbieterbeispiel. Für die technische Auswahl gelten dieselben Kriterien wie bei jedem anderen Anbieter: passende Indikatortypen, direkt abrufbare Datei, Aktualität, vertretbare False Positives, nachvollziehbare Treffer und ein erreichbarer Prozess für Korrekturen.

Pläne vergleichen

Free (Basic) liefert nur IPv4 und wird alle 24 Stunden aktualisiert; damit lässt sich die Zustellung und SFOS-Kompatibilität vor einem Kauf prüfen. Standard liefert IPv4 und eine kleinere Domain-Auswahl im 6-Stunden-Takt. Premium liefert IPv4, Domains und URLs stündlich, Ultimate dieselben Indikatortypen alle 15 Minuten. Auf XGS 87/87w, 88/88w und 107/107w bleibt der kürzeste auswählbare SFOS-Abruf jedoch 24h, unabhängig vom Anbieterplan.

Neben Anzahl und Preis zählen Aktualität, unterstützte Indikatortypen, Quellenqualität, Update-Intervall, False-Positive-Risiko und die Nachvollziehbarkeit im Log Viewer. Der passende Feed ist derjenige, der in der eigenen Umgebung relevante Treffer mit vertretbaren Nebenwirkungen liefert.

Avanet Firewall Network

Ein Teil des Premium Feeds stammt aus einem verteilten Firewall-Netzwerk. Dieser Blick hilft bei Angriffsmustern, die auf einer einzelnen Firewall kaum auffallen.

Bei verteilten Brute-Force-Angriffen führt jeder Bot nur wenige fehlgeschlagene Anmeldeversuche aus und bleibt lokal oft unter einem Schwellwert. Die Zusammenführung anonymisierter Signale macht IP-Adressen sichtbar, die über mehrere Systeme hinweg gezielt Infrastruktur angreifen. Daraus entsteht ein laufend aktualisierter Threat Intelligence Feed für die automatische Abwehr.