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. Local reporting speichert Ereignislogs lokal für den Log Viewer; diese Logs sind keine On-Box-Reports. Alternativ Sophos Fusion (ehemals Sophos Central) oder einen Syslog-Server als Logziel 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 gemäss Anbieter wählen. Bei API key werden der vom Anbieter vorgegebene Header- oder Parametername und der geheime Wert getrennt eingetragen; anschliessend Header oder Query parameters als Übertragungsort wählen. Verlangt ein Anbieter beispielsweise den Header X-API-Key, ist dies der Name und nicht der geheime Schlüssel. Bei Basic authentication Benutzername und Passwort eintragen. Der API-Key-Wert und das Passwort 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 eine erfolgreiche Verbindung oder HTTP-GET-Anfrage, aber weder die vollständige Auswertung der Liste noch, dass der erwartete Traffic tatsächlich erkannt oder blockiert wird. Inhalt und Wirkung müssen separat validiert werden.

Feed und Aktion richtig wählen

Unterstützte Indikatoren

Jede Feed-Konfiguration wertet genau einen dieser Indikatortypen aus:

• 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. Enthält die Anbieterdatei mehrere Typen, berücksichtigt SFOS nur den ausgewählten Indicator type. Für jeden gewünschten Typ braucht es deshalb eine eigene Konfiguration; eine gemischte Datei muss nicht allein wegen dieser Mischung aufgeteilt werden. 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.

Ein reines IPv4-Formatbeispiel sieht so aus:

192.0.2.10
198.51.100.20

Diese Dokumentationsadressen zeigen nur das Format, nicht echte Bedrohungen oder erreichbare Testziele. Für den kontrollierten Test weiter unten wird stattdessen die einzelne IPv4-Adresse des eigenen Testziels verwendet, nicht dessen Netzwerk mit CIDR-Suffix. Bei Cybora werden die bereitgestellten Feeddateien direkt genutzt.

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. Die Integration ist nicht auf eine feste Anbieter-Auswahlliste beschränkt: Jeder Third-Party Feed kann eingebunden werden, wenn er die beschriebenen Dateianforderungen erfüllt. Sophos nennt beispielsweise GreyNoise Intelligence, CrowdSec und Q-Feeds als Anbieter; diese Nennung ersetzt weder die Prüfung des konkreten Endpunkts noch den eigenen Monitor-Pilot.

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. Die Modul-Lizenzübersicht nennt das Xstream Appliance Bundle, die Konfigurationshilfe dagegen das Xstream Protection Bundle. Den konkreten Lizenz- und Quellenabgleich für NDR Essentials vor Kauf oder Rollout heranziehen und das Entitlement für die eigene Firewall verbindlich bestätigen.
• 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- und URL-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.

Der zuständige Prüfpfad ist dabei das Web-Modul für den Web Proxy beziehungsweise IPS für die DPI Engine mit SSL/TLS-Inspection-Regeln. Das gilt für verschlüsseltes und entschlüsseltes HTTPS; welche IoCs erkennbar sind, hängt weiterhin davon ab, ob nur die Domain oder auch der URL-Pfad sichtbar ist.

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

Sync status: Success bestätigt eine erfolgreiche Verbindung oder HTTP-GET-Anfrage zur External URL, nicht die Vollständigkeit oder erfolgreiche Auswertung aller erwarteten Indikatoren. Test connection ist ebenfalls nur ein Verbindungscheck. 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 als Anzahl aktiver und insgesamt konfigurierter Feeds, Total threat indicators als Anzahl der IPv4-, Domain- und URL-Indikatoren sowie Storage quota als belegten Speicher im modellabhängigen Kontingent. Grössere Appliances haben mehr Platz als Desktop-Modelle. Refresh aktualisiert nur diese angezeigten Zähler. Synchronize now unter Manage ruft dagegen den ausgewählten Feed sofort ab. Einzelne IoCs lassen sich über Threat indicators oder über die Zahl in Total indicators des betreffenden Feeds öffnen und durchsuchen. Fetching bedeutet, dass der Download läuft; Disabled bedeutet, dass der Feed ausgeschaltet ist.

Bei Authentication error zuerst API-Key-Name, geheimen Wert, Übertragungsort beziehungsweise Benutzername und Passwort prüfen. Stimmen diese Angaben, auch einen fehlgeschlagenen TLS-Handshake untersuchen: Zertifikat und Vertrauenskette des Feedservers kontrollieren und bei Bedarf mit dem Anbieter klären. Nicht jeder Authentifizierungsfehler ist ein TLS-Fehler. Validate server certificate bleibt aktiviert; fehlendes CA-Vertrauen wird durch das korrekte CA-Zertifikat behoben, nicht durch Abschalten der Prüfung.

Bei Connection error DNS, Internetzugriff, Feedserver und HTTP-Status prüfen; auch 404, 500 und 302 sind mögliche Ursachen. SSL/TLS error ist ein eigener Status für Zertifikatsprobleme. Bei Failed die tatsächlich gelieferte Datei auf Plain Text, einen Indikator pro Zeile und passende unterstützte Typen prüfen; auch andere Fehler sind möglich. Nach der Korrektur Test connection und Synchronize now erneut ausführen, Zeitstempel und erwarteten IoC kontrollieren und erst danach den kontrollierten Traffic-Test wiederholen. Bleibt der Fehler bestehen, Status, Zeitpunkt und bereinigte Feedangaben ohne Geheimnisse für Anbieter oder Support festhalten.

Storage full bedeutet, dass nicht genügend Platz für die vollständige Liste vorhanden ist. Die Firewall ruft 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 und URLs 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. Zuerst den funktionierenden Abruf und Prüfpfad bestätigen und prüfen, ob MDR, NDR oder X-Ops dieselben IoCs bereits erkennen. Ein kurzer Test ohne Treffer ist kein Löschgrund. Ist der Feed danach tatsächlich redundant, vor dem Löschen Name, URL, Indikatortyp, Aktion, Position, Polling-Intervall und die sichere Ablage der Zugangsdaten dokumentieren. Unter Protect > Active threat response > Third-party threat feeds den geprüften Feed löschen, um Speicher freizugeben. Anschliessend Refresh, Storage quota und Active feeds prüfen und einen zuvor an Storage full gescheiterten Feed mit Synchronize now erneut abrufen. Für einen Rückweg wird der gelöschte Feed mit den dokumentierten Werten neu angelegt, zunächst auf Monitor. Das temporäre Deaktivieren für einen Rollback bleibt davon getrennt; es wird nicht als Nachweis für freigegebenen Speicher behandelt.

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. Unter Host and network exclusions > Add new item vorhandene Host- oder Netzwerkobjekte auswählen. 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.

ThirdPartyFeed per XML automatisieren

Für die Automatisierung derselben Feed-Konfiguration verwendet die XML-Schnittstelle das Objekt ThirdPartyFeed. Es konfiguriert den Abruf und die Aktion, nicht die einzelnen heruntergeladenen IoCs. Zugriff, explizite Schreiboperation, versionsabhängiger Request-Aufbau und sichere Antwortauswertung werden unter XML-API-Zugriff absichern erklärt. Die folgenden Feldnamen und Grenzen betreffen SFOS 22 und 23; für einen Schreibzugriff ist ein vollständiger, buildbezogen bestätigter Request erforderlich. Vor dem Einsatz die konkrete Add-/Edit-Operation und deren Payload in API help des installierten Builds bestätigen. Bei ungeklärter Syntax oder einem Quellenkonflikt nicht schreiben, sondern mit Support klären.

Vor einer Änderung den bestehenden Feed über seinen Name in WebAdmin zuordnen und Name, Indikatortyp, URL, Aktion, Aktivierung, Position und Polling-Intervall sichern. Der Name bezeichnet die Feed-Konfiguration, nicht den Anbieter oder einen einzelnen IoC. Derselbe Anbieter kann mehrere getrennt benannte Konfigurationen für IPv4, Domains und URLs haben. Aus dem Objektnamen keine ungeprüfte Rename-, Upsert- oder Überschreibsemantik ableiten.

• Identität und Quelle: Name ist erforderlich, erlaubt höchstens 63 Zeichen und nur Buchstaben, Zahlen, Unterstriche und Bindestriche. Description ist optional und auf 255 Zeichen begrenzt. ExternalURL ist erforderlich und auf 1024 Zeichen begrenzt; weiterhin einen direkt erreichbaren HTTPS-Plain-Text-Feed mit einem Indikator pro Zeile verwenden.
• Aktion und Reihenfolge: Action verlangt exakt block oder monitor, entsprechend Block beziehungsweise Monitor in der UI. monitor protokolliert Treffer ohne Feed-Sperre; block protokolliert und blockiert. Die Bezeichnungen Log only und Log and drop anderer Module sind keine Ersatzwerte für dieses Feld. Position erlaubt top oder bottom, entsprechend Top oder Bottom. Damit wird die Position innerhalb der Third-Party Feeds gewählt, nicht deren Vorrang vor MDR, NDR Essentials oder Sophos X-Ops. Block- und Monitor-Listen bleiben getrennt; der erste Treffer je Liste ist massgebend.
• Indikatortyp: IndicatorType verlangt ip, domain oder url, entsprechend IPv4 address, Domain oder URL. ip ist hier kein IPv6-, Netzwerk- oder Range-Typ. Pro gewünschtem Indikatortyp eine eigene Konfiguration anlegen.
• Authentifizierung: Authorization verlangt noAuthentication, basicAuthentication oder apiKey. Nur bei Basic Authentication gehören Username und Password dazu, jeweils höchstens 64 Zeichen. Nur bei API-Key-Authentifizierung gehören Key, Value und AddTo dazu: Key-Name und geheimer Wert sind getrennt und jeweils auf 64 Zeichen begrenzt; der Übertragungsort ist exakt header oder queryParam, entsprechend Header oder Query parameters. Die Anbieteranforderung entscheidet, nicht ein angenommener Default. Nur die zum Verfahren gehörenden Felder verwenden; Secrets aus einem geschützten Secret Store beziehen und aus XML-Dateien im Repository, URLs in Tickets, Shell-History, Screenshots und Logs fernhalten. Bei Query-Parametern besonders auf das Maskieren geloggter Feed-URLs achten.
• Zertifikatsprüfung: ValidateServerCertificate ist erforderlich; das Objektbeispiel zeigt true und false. Für den sicheren Betrieb die Prüfung ausdrücklich aktivieren und das passende CA-Vertrauen vorher herstellen. Ein TLS- oder Authentifizierungsfehler rechtfertigt nicht das Abschalten der Prüfung.
• Abrufintervall: PollingInterval ist erforderlich und erlaubt ausschliesslich 5m, 15m, 30m, 1h, 6h, 24h, 7d oder 30d. Dies sind feste Tokens, keine frei wählbare Minutenzahl. Auf XGS 87/87w, 88/88w und 107/107w bleibt die Auswahl auf 24h, 7d und 30d beschränkt. Beispielsweise passt 1h zu einem stündlichen Anbieterupdate nur auf einem Modell, das dieses Intervall unterstützt.
• Aktivierung und Defaults: Für Enabled nennt die Parametertabelle 1 und 0, das Objektbeispiel dagegen true und false. Das ist ein ungelöster Darstellungsunterschied, kein Nachweis austauschbarer Schreibweisen. Vor einem Schreibversuch die gültige Form im installierten Build klären. Die Tabelle nennt ausserdem monitor, top, ip und noAuthentication als Defaults der entsprechenden Felder. Den tatsächlichen Zustand am Zielobjekt prüfen. Aktion, Position, Typ und Authentifizierung bewusst festlegen statt auf ausgelassene Werte zu vertrauen.

Add-/Edit-Antworten sicher einordnen

Für Add Third-party threat feed und Edit Third-party threat feed sind folgende Zuordnungen dokumentiert. Die Message.*-Werte sind ungelöste Meldungssymbole, keine wörtlichen Fehlertexte und keine alleinige Handlungsanweisung:

Insbesondere gehören 409 / Message.CPResourceConflict zu Add und 404 / Message.CPRecordNotFound zu Edit. Diese objektspezifischen Zuordnungen nicht mit allgemeinen XML-Codes oder einem HTTP-Transportstatus gleichsetzen; entscheidend sind die tatsächliche Antwort und Status Message Information im Build. Nach jeder Änderung den gespeicherten Feed in WebAdmin mit den Sollwerten abgleichen und den Audit Trail prüfen. Bei Fehler, Timeout oder unklarer Antwort zuerst den tatsächlich gespeicherten Zustand kontrollieren, bevor ein Add oder Edit erneut gesendet wird. Keine automatische Wiederholung, Umbenennung oder vermeintliche Fehlerbehebung aus einem Symbol ableiten.

Eine passende Konfigurationsantwort beweist weder Feedabruf noch IoC-Inhalt oder Traffic-Wirkung. Danach weiterhin Test connection, Synchronize now, Last updated, Storage quota, einen erwarteten IoC und einen kontrollierten Monitor-Traffic-Test prüfen. Erst nach dieser Prüfung auf Block umstellen; bei unerwarteten Ausfällen die gesicherte Aktion wiederherstellen beziehungsweise den Feed wie oben beschrieben kontrolliert deaktivieren, nicht eine globale Threat Exclusion als Ersatz setzen.

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.