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-Central-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 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 External URL die passende Adresse aus der Avanet-Feed-Liste beziehungsweise vom eigenen Anbieter hinterlegen. Die Datei muss einen Indikator pro Zeile enthalten.
9. Bei Bedarf API-Key oder Basic Authentication konfigurieren. Zugangsdaten gehören nicht in Tickets oder Screenshots.
10. 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.
11. Ein Polling interval wählen, das zum Update-Intervall des Anbieters passt.
12. 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.

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.

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 Central. Der eigene Ablauf erklärt Central-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 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.

Domain-Feeds benötigen für weitergeleiteten Traffic zusätzlich Application Classification oder eine IPS-Policy in der Firewall-Regel.

Bei vollständigen URLs über HTTPS muss die Firewall auch den Pfad sehen. Dafür braucht es entweder Web Proxy mit HTTPS-Entschlüsselung oder DPI mit passender SSL/TLS-Inspection-Regel. 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 Central-/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

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, sollten Feedumfang, Qualität und Priorität geprüft werden, 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

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.

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 stellt kuratierte Feeds bereit, damit Administratoren nicht mehrere OSINT-Listen selbst sammeln, normalisieren und laufend prüfen müssen. Die Daten stammen unter anderem aus Community- und OSINT-Quellen, kommerzieller Threat Intelligence, Honeypots und anonymisierten Angriffs- und Anomalie-Logs aus betriebenen Sophos-Firewall-Umgebungen.

Avanet hat mehrere Threat-Feed-Anbieter in realen Firewall-Umgebungen getestet. Cybora bietet für Sophos Firewall aus unserer Sicht aktuell das beste Preis-Leistungs-Verhältnis. Bewertet wurden Feedqualität, Abdeckung, Aktualisierungsintervalle und Kosten. Auch einen solchen Feed sollte man zuerst im eigenen Monitor-Pilot prüfen.

Pläne vergleichen

Free (Basic) eignet sich für Home User, Proof of Concept und Kompatibilitätstests. Standard ergänzt den IPv4-Feed um Malware- und Phishing-Domains. Premium erweitert die Abdeckung um Domains und URLs mit stündlichen Updates. Ultimate richtet sich mit 15-Minuten-Updates an kritische Infrastruktur und High-Risk-Perimeter.

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.