Threat Feeds für Firewalls: Wirkung, Grenzen und Anbieter im Vergleich

Das Internet ist voll von Systemen, die öffentliche Adressen automatisiert scannen. Sie suchen offene Ports, Login-Seiten, VPN-Portale, bekannte Webanwendungen und verwundbare Dienste. Dahinter stehen sowohl Sicherheitsforscher und Suchmaschinen für Internet-Infrastruktur als auch Bots und Angreifer, die nach verwertbaren Schwachstellen suchen.

Wer einen über eine WAF veröffentlichten Dienst, eine DNAT-Freigabe, ein Mail-Gateway oder ein öffentliches Login betreibt, taucht früher oder später in diesen Scans auf. Eine öffentliche IP-Adresse allein bedeutet noch keine Kompromittierung. Sobald dahinter aber ein Dienst antwortet, wird aus dem Hintergrundrauschen echte Arbeit für Firewall, IPS, WAF, Server, Applikation und Logging.

Für mich als Security Engineer ist dieses Grundmuster nicht neu. Wir sehen bei der Arbeit immer wieder Firewalls, WAFs und öffentlich erreichbare Dienste, die einen beträchtlichen Teil ihrer Zeit mit automatisiertem Rauschen verbringen. Meistens ist das kein spektakulärer Einzelangriff, sondern eine dauerhafte Mischung aus Portscans, Login-Versuchen, Crawlern und Exploit-Checks.

Vor Kurzem war ich im Team an einer Analyse beteiligt, bei der die Größenordnung selbst für uns bemerkenswert war. Es ging um eine Firewall in einem Rechenzentrum mit einem 10-Gbit/s-Uplink und grundsätzlich ordentlichen Leistungsreserven. Trotzdem wirkte das System, als wäre es am Limit. Die Leitung war auffällig stark ausgelastet, die Administration reagierte träge und die exponierten Dienste produzierten fortlaufend neue Ereignisse.

Wir untersuchten den Traffic nach Richtung, Zielsystem, Port, Zeitfenster und wiederkehrender Quelladresse. Dabei fielen zahlreiche automatisierte Zugriffe auf dieselben Web-, Mail- und Login-Dienste auf. Wie viel Last solche Zugriffe verursachen, hängt nicht allein von ihrer Anzahl ab: Ein verworfenes Paket, ein TLS-Handshake und eine aufwendige Anfrage an die Anwendung beanspruchen unterschiedliche Ressourcen.

Wir erklärten dem Kunden anschließend, was bei der Analyse herausgekommen war. Ein erheblicher Teil der Aktivität bestand aus automatisiertem Bot- und Scan-Traffic, der immer wieder dieselben exponierten Dienste beschäftigte. Wir zeigten ihm, was ein Threat Feed an dieser Stelle leisten kann, welche Grenzen er hat und dass die passende Lizenz rund 350 US-Dollar pro Jahr kostet. Nachdem der Kunde den Kosten zugestimmt hatte, installierten wir die Liste mit wenigen Klicks direkt auf der Firewall. Die gesamte Einrichtung dauerte nur einige Minuten.

Nach der Aktivierung reagierte die Verwaltungsoberfläche der Firewall wesentlich schneller. Auch vom Kunden kam eine klare Rückmeldung: Webseiten und Anwendungen luden deutlich schneller. Die Verbesserung war damit sowohl bei der Administration als auch bei der täglichen Nutzung der Dienste spürbar.

Genau dieser Effekt macht den Fall interessant. Nicht weil Threat Feeds für mich neu wären, sondern weil viele Admins ihre Wirkung und ihre Grenzen falsch einschätzen. Für die einen ist ein Feed nur eine lange Textdatei mit IP-Adressen. Andere halten ihn für einen Ersatz für IPS, WAF oder EDR. Entscheidend ist jedoch, woher die Indikatoren kommen, wie schnell sie altern, wie konsequent False Positives entfernt werden und an welcher Stelle der Firewall sie greifen. Deshalb möchte ich die Messwerte nicht nur zeigen, sondern die Thematik technisch von Grund auf erklären.

Das Ergebnis in Zahlen

Die Messwerte stammen von einer produktiv eingesetzten Firewall. Der IP-Threat-Feed wurde am 1. September 2026 um 10:01:05 Uhr wirksam. Der erste Treffer folgte wenige Sekunden später. Bis zum 2. September um 20:30 Uhr CEST hatte die Firewall 516.959 Block-Events protokolliert.

Über den gesamten Zeitraum griff der Feed durchschnittlich 249,9-mal pro Minute ein. Das sind 4,17 Events pro Sekunde oder ein Block alle 0,24 Sekunden. In der stärksten Minute waren es 775 Events. Der Spitzenwert lag bei 107 Events innerhalb einer Sekunde und trat sogar in zwei aufeinanderfolgenden Sekunden auf.

Diese Zahlen sind absichtlich als Block-Events, Treffer oder Verbindungsversuche bezeichnet. 516.959 Events sind nicht automatisch 516.959 voneinander unabhängige, manuell gesteuerte Angriffe. Ein einzelner Scanner kann denselben Dienst oft ansprechen, ein Bot kann schnell mehrere Ports testen und ein fehlgeschlagener Verbindungsaufbau kann Folgepakete erzeugen.

Wer klopfte an die Tür?

Im gesamten Messzeitraum von 34 Stunden und 29 Minuten waren 516.727 Events eingehend. Nur 232 Events betrafen verhinderte ausgehende Verbindungen. Der Feed wirkte in dieser Umgebung damit zu 99,955 Prozent gegen Quellen aus dem Internet.

Insgesamt tauchten 10.518 unterschiedliche gelistete IP-Adressen auf. Bei einer damaligen Feed-Größe von 220.000 IPv4-Indikatoren wurden innerhalb von rund 34 Stunden bereits etwa 4,8 Prozent der gesamten Liste auf dieser einen Firewall relevant. Die aktivste einzelne Adresse erzeugte 4.141 Events. Die zehn aktivsten Adressen kamen zusammen auf ungefähr 31.500 Events, während 767 Adressen nur einmal erschienen.

Die rund 4,8 Prozent sind ein Größenvergleich mit dem damaligen Listenstand, keine Erkennungsquote. Die Liste verändert sich durch Updates, und unbekannte oder nicht gelistete Angreifer fehlen in diesem Zähler.

Die Portauswertung deckt ein rollierendes 24-Stunden-Fenster mit ungefähr 369.000 Detailereignissen ab:

Rund 56 Prozent der Events zielten auf Webdienste, etwa 40 Prozent auf Mailports. Das passt zum Profil des Standorts. Öffentliche Web- und Maildienste sind leicht zu finden, dauerhaft erreichbar und für automatisierte Systeme attraktiv. Innerhalb des Detailfensters wurden 27 interne Zielsysteme angesprochen.

Die Dienstnamen sind anhand der Zielports zugeordnet, nicht durch eine erfolgreiche Protokollanalyse nachgewiesen. Das rollierende Detailfenster ist außerdem nicht identisch mit den ersten 24 Stunden seit Aktivierung; die beiden Summen dürfen deshalb nicht direkt verglichen werden.

Die 232 ausgehenden Treffer sind zahlenmäßig klein, aber sicherheitsrelevant. Zehn interne Systeme versuchten Verbindungen zu 17 gelisteten Zieladressen. Ein solcher Treffer beweist noch keine Infektion, er verdient aber eine Untersuchung. Möglich sind Malware-Kommunikation, eingebettete Drittinhalte, ein veralteter Eintrag oder eine legitime Gegenstelle auf einer inzwischen neu vergebenen IP-Adresse.

Die bessere Reaktionszeit der Firewall-GUI und die vom Kunden berichteten kürzeren Ladezeiten sind konkrete Beobachtungen nach der Umstellung. Welcher Engpass zuvor ausschlaggebend war, haben wir damit allerdings nicht isoliert: die Firewall, die Webserver, die Anwendungen oder die Verbindung dazwischen. Die Block-Events dokumentieren die Filterwirkung, messen aber weder Ladezeiten noch eingesparte Rechenleistung. Eine prozentuale Performance-Steigerung lässt sich daraus nicht berechnen.

In diesem Fall erreichten die automatisierten Anfragen zuvor tatsächlich die Web- und Applikationsserver. Diese mussten sie verarbeiten und beispielsweise für nicht vorhandene Pfade eine Fehlerantwort erzeugen. Mit der frühen IP-Blockierung entfiel diese nachgelagerte Arbeit für die betroffenen Zugriffe. Auch die Firewall konnte diese Verbindungen früher verwerfen, statt sie weiterzuleiten und weiter zu verarbeiten. Der Listenabgleich selbst benötigt weiterhin Ressourcen; die Entlastung entsteht durch die vermiedenen Folgeschritte.

Reihenfolge und Geltungsbereich hängen von Plattform und Konfiguration ab, gerade bei WAF und Diensten auf der Firewall selbst. Das erste Paket erreicht weiterhin das WAN-Interface. Ein lokaler Drop kann Antworten und weitere Sitzungsdaten verhindern, ersetzt aber keinen vorgelagerten Schutz vor volumetrischen DDoS-Angriffen.

Was ein Threat Feed tatsächlich macht

Ein einfacher Firewall-Feed ist meist erstaunlich unspektakulär. Die Firewall lädt über HTTPS eine Textdatei mit den zu blockierenden Indikatoren. Viele Anbieter stellen neben IP-Adressen auch Feeds für Domains und URLs bereit. In den meisten Fällen verwenden wir jedoch nur die IP-Adressen, weil sie für unsere Firewall-Anwendungsfälle die wichtigsten Informationen liefern und beim frühen Blockieren den größten Effekt erzielen. Die Firewall aktualisiert diese Indikatoren nach einem festgelegten Intervall und prüft passenden Traffic gegen die Liste. Bei einem Treffer wird je nach Konfiguration nur protokolliert oder direkt blockiert.

Wie zuverlässig ein Threat Feed im Betrieb ist, hängt davon ab, wie der Anbieter seine Einträge prüft und aktuell hält:

• War das Verhalten wirklich bösartig oder nur ungewöhnlich?
• Wie aktuell ist die Beobachtung?
• Bestätigen voneinander unabhängige Quellen das Signal?
• Wann wird ein veralteter Indikator wieder entfernt?

Eine lange Blockliste ist noch keine gute Threat Intelligence. Entscheidend sind Aktualität, Präzision und konsequente Bereinigung. Je größer und älter eine Liste wird, desto höher ist die Wahrscheinlichkeit, dass dynamische Cloud-, Hosting- oder Provider-Adressen inzwischen legitim genutzt werden. Eine sehr kleine, konservative Liste hat das umgekehrte Problem: kaum False Positives, aber möglicherweise zu wenig Reichweite gegen das alltägliche Scanrauschen.

Threat Feeds für Firewalls

Ich möchte hier nicht künstlich Spannung aufbauen und den Leser bis zum Schluss warten lassen: Der Threat Feed, den viele meiner Kollegen und ich heute verwenden, stammt vom Anbieter Cybora. Auch privat nutze ich ihn, um öffentlich erreichbare Dienste auf meinen eigenen Cloud-Servern zu schützen. Diese Entscheidung beruht nicht auf einer Produktdemo, sondern auf einem Vergleich im realen Betrieb.

Über zwölf Monate testeten wir im Team mehr als 30 kommerzielle Anbieter und öffentliche Quellen auf insgesamt 15 Kundenfirewalls. Wir schlossen die relevanten Abonnements ab, gaben dafür mehrere Tausend US-Dollar aus und prüften Angebote vom kostenlosen Community-Feed bis zu Paketen, die sich 1.000 US-Dollar pro Monat näherten. Einige der teuersten Produkte lieferten deutlich kleinere Listen und begründeten den Preis vor allem mit besonders hoher Aktualität und Präzision.

Für diesen Vergleich installierten wir die zu prüfenden Feeds auf allen 15 Firewalls und stellten sie auf Monitor. Sie sollten Treffer protokollieren, ohne selbst die Verbindungen zu blockieren. So konnten wir die gemeldeten Treffer im Kontext des realen Traffics und der betroffenen Dienste untersuchen. Dieser längerfristige Monitor-Vergleich ist vom oben beschriebenen Block-Einsatz im Rechenzentrum zu unterscheiden.

Wir verglichen, welche Quellen die Feeds erfassten, und prüften auffällige Zugriffe sowie mögliche Fehlalarme anhand der verfügbaren Firewall- und Applikationslogs. Entscheidend waren bestätigte schädliche Aktivitäten, zusätzliche Abdeckung gegenüber anderen Listen, Aktualität und der Aufwand für Ausnahmen. Eine größere Liste oder ein höherer Preis allein war kein Qualitätsnachweis.

Die Logauswertung war Teil unserer täglichen Arbeit im Team. Wiederkehrende Ereignisse müssen dabei zusammen betrachtet werden, damit ein besonders aktiver Scanner nicht das gesamte Ergebnis dominiert. Ebenso wichtig sind legitime Verbindungen, die eine Liste verhindern würde. Auch eine korrekt als problematisch eingestufte IP kann auf diese Weise betriebliche Fehlalarme verursachen.

Das war ein Vergleich im produktiven Alltag, kein standardisierter Labortest. Monitor-Treffer sind nicht automatisch eine vollständige Gegenüberstellung aller Listen: Auswertungsreihenfolge, Überschneidungen und andere aktive Schutzfunktionen können beeinflussen, was eine Firewall protokolliert. Eine fehlende Logmeldung allein beweist deshalb keine Erkennungslücke. Für einen unabhängig reproduzierbaren Benchmark müssten auch zeitgestempelte Listenstände, Auswertungseinstellungen und bestätigte Positiv- und Negativfälle offengelegt werden. Diese vollständigen Vergleichsdaten veröffentliche ich hier nicht.

Diese elf Angebote sind eine redaktionelle Auswahl für den Firewall-Einsatz, keine nach Marktanteilen belegte Beliebtheitsrangliste. Sie verbindet unsere Praxiserfahrungen mit ergänzenden Quellen aus aktueller Dokumentation. AbuseIPDB und IPsum sind zusätzliche Optionen; eigene Testergebnisse dazu werden hier nicht behauptet. Cybora steht wegen unserer Erfahrungen zuerst. Die übrige Reihenfolge ist keine gemessene Rangfolge. Die übrigen Produktinformationen wurden am 8. September 2026 geprüft, die Angaben zu Q-Feeds am 28. September 2026.

Cybora erzielte für unsere Umgebungen das beste Gesamtverhältnis aus Abdeckung, Aktualität, aktiven Treffern, geringer False-Positive-Arbeit, einfacher Einbindung, Support und Preis. Die Einstiegstarife sind im Vergleich sehr fair, während der Ultimate-Plan mit Aktualisierungen alle 15 Minuten auch für größere und stark exponierte Infrastrukturen interessant ist, wie ich sie bei der Arbeit häufig verwalte.

Auch hier gibt es Grenzen: Ein 15-Minuten-Publikationsintervall sagt nichts darüber aus, wie lange Erkennung und Bewertung vorher dauern. Danach kommen Abruf und Übernahme auf der Firewall hinzu. Im gelieferten Messpaket sind zudem zwei HTTP-429-Antworten dokumentiert; die vorhandene Liste blieb lokal aktiv und der nächste Abruf holte das Update nach. Das ist kein Totalausfall, zeigt aber, warum Listenalter und fehlgeschlagene Updates überwacht werden müssen.

CrowdSec Blocklists verbinden eine Open-Source Security Engine mit Community-Signalen und kuratierten Listen, die sich auch direkt an Firewalls und Gateways ausliefern lassen. Produktionstelemetrie aus vielen Umgebungen und spezialisierte Listen sind klare Stärken. Eine Liste für CMS-Angreifer, Proxy-Infrastruktur oder ein bestimmtes CVE ist jedoch nicht automatisch ein universeller Edge-Feed.

GreyNoise bietet auch direkt nutzbare, abfragebasierte IP-Blocklisten für Firewalls. Über GNQL lassen sich jüngst aktive Angreifer oder Quellen zu bestimmten CVEs auswählen. Das ist eine echte Alternative für Teams, die ihre Filterkriterien selbst festlegen möchten. Der Aufwand liegt in der passenden Abfrage, den gebuchten Datenmodulen und der laufenden Prüfung der Auswahl. GreyNoise auf reine Log-Anreicherung zu reduzieren, würde das Angebot unterschätzen.

Q-Feeds gibt an, Indikatoren aus mehr als 2.500 kommerziellen, öffentlichen und staatlichen Quellen zu kuratieren und als IP-, Domain- und URL-Feeds bereitzustellen. Der Anbieter beschreibt eigene Qualitätsprüfungen und eine Bereinigung von False Positives. Unsere Betriebserfahrung fiel kritischer aus: Schon in der ersten Stunde eines Block-Einsatzes gab es mehrere Sperren legitimer Zugriffe. Wir untersuchten die betroffenen Verbindungen und stuften die geprüften Treffer als False Positives ein. Der Support entfernte die gemeldeten Einträge relativ schnell. Weil der Prüf- und Meldeaufwand für uns trotzdem hoch blieb, meldeten wir spätere Fälle nicht mehr systematisch.

Die Zahl der Quellen erklärt diese Fehlalarme für sich genommen nicht. Ohne Einblick in Herkunft, Begründung und Neubewertung der einzelnen IP-Einträge konnten wir die Ursache nicht zuverlässig bestimmen. Für einen breit auf Kundenfirewalls ausgerollten Block-Feed war die beobachtete Ausnahme- und Supportlast aus unserer Sicht zu hoch. Als Monitor- oder Recherchequelle kann Q-Feeds dennoch einen anderen Nutzen haben; unsere Bewertung bezieht sich auf den Block-Einsatz in unseren Umgebungen.

Spamhaus DROP ist eine konservative Liste besonders problematischer Netze und für Edge-Filtering oder Routing-Entscheidungen gedacht. Die hohe Aufnahmeschwelle macht sie verlässlich, sie will jedoch nicht jeden kurzlebigen Scanner im Internet erfassen.

ThreatFox von abuse.ch und Spamhaus konzentriert sich auf Malware-bezogene Indicators of Compromise, darunter Command-and-Control-Infrastruktur. Für Malware-Erkennung und Threat Hunting ist das eine starke Quelle. Der Zweck ist enger als bei einem allgemeinen Firewall-Feed gegen Scanner, Brute Force und automatisierte Exploit-Infrastruktur.

URLhaus von abuse.ch sammelt und verteilt URLs, über die Malware ausgeliefert wird. Diese Daten sind besonders für DNS-Filter, Proxys, Secure Web Gateways und Analyseplattformen wertvoll. Für eine reine IP-Blockierung am Perimeter ist URLhaus naturgemäß nur ein spezialisierter Baustein.

Für die API ist ein Auth-Key erforderlich. Community-Zugang bedeutet nicht uneingeschränkt kostenlose kommerzielle Nutzung; die Fair-Use-Bedingungen müssen zum Einsatz passen.

DShield stellt auf Basis eingereichter Firewall-Logs eine kompakte empfohlene Blockliste bereit. Sie kann eine sinnvolle Zusatzquelle sein. Andere DShield-Datensätze dienen vor allem Forschung und Kontext und sollten nicht ungefiltert als Blockliste übernommen werden.

FireHOL IP Lists aggregiert und beobachtet zahlreiche öffentliche Listen. Das Repository ist sehr hilfreich, um Größe, Aktualisierungsverhalten, Alter und Überschneidungen zu vergleichen. Ein Aggregator übernimmt jedoch auch die Schwächen seiner Quellen, und mehrfach weitergereichte Einträge können länger erhalten bleiben als erwünscht.

AbuseIPDB bietet reportbasierte IP-Reputation und eine als Klartext abrufbare Blockliste mit einstellbarem Confidence-Schwellenwert. Das hilft bei Recherche und automatisierten IP-Prüfungen. Ein hoher Score bewertet gemeldete Aktivität, beweist aber nicht, dass jede aktuelle Verbindung dieser IP bösartig ist. Reportalter, gemeinsam genutzte Adressen und tarifabhängige Abruflimits müssen berücksichtigt werden.

IPsum aggregiert täglich mehr als 30 öffentliche Listen und liefert fertige Schwellen nach der Anzahl übereinstimmender Quellen. Das ist ein transparenter Einstieg in IP-Blocklisten. Drei Listentreffer sind allerdings nicht zwingend drei unabhängige Beobachtungen, wenn Quellen voneinander übernehmen. Die tägliche Aktualisierung begrenzt die Reaktionsgeschwindigkeit. Für eine konservative Zusatzliste ist das brauchbar; eine eigenständige Telemetriequelle erhält man damit nicht.

Kostenlos bedeutet nicht schlecht, und kommerziell bedeutet nicht automatisch gut. Viele öffentliche Feeds sind in ihrer Spezialdisziplin hervorragend. Für eine breite, direkt durchgesetzte Baseline am Firewall-Perimeter sind sie nach unserer Erfahrung aber eher gezielte Bausteine als ein vollständiger Ersatz für einen fortlaufend kuratierten Allround-Feed.

Warum Cybora in unserem Vergleich vorne lag

Zur Transparenz: Ich schreibe hier auf meinem persönlichen Blog und erhalte persönlich keine Provision. Mein Arbeitgeber ist allerdings Cybora-Reseller und bezieht Lizenzen zu vergünstigten Konditionen, um sie mit Marge weiterzuverkaufen. Diese geschäftliche Verbindung gehört zur Einordnung meiner Empfehlung. Ausschlaggebend für unsere Auswahl waren die Erfahrungen aus dem beschriebenen Vergleich, nicht die Reseller-Konditionen.

Im beschriebenen Praxisfall stand Cybora hinter den Messwerten. Wir starteten mit dem Premium-Plan für 349 US-Dollar pro Jahr. Er passte mit seiner stündlichen Aktualisierung und der breiteren Abdeckung zu den exponierten Diensten, ohne gleich den größten verfügbaren Tarif zu wählen.

Nach öffentlicher Produktbeschreibung kombiniert Cybora OSINT, kommerzielle Quellen, Honeypots, Sensoren und reale Firewall-Telemetrie. Indikatoren werden nach Aktualität, Vertrauen und Übereinstimmung mehrerer Quellen bewertet, dedupliziert, gegen Allow- und Ausschlussregeln geprüft und als einfache HTTPS-Liste veröffentlicht. Der Premium-Plan lieferte zum Testzeitpunkt 220.000 IPv4-, 45.000 Domain- und 25.000 URL-Indikatoren mit stündlicher Aktualisierung. Auf der gemessenen Firewall waren IPv4 auf Block und Domains zunächst auf Monitor gesetzt.

Eine Woche nach der Aktivierung wechselte der Kunde vom Premium- auf den Ultimate-Plan. Dieser umfasste zum damaligen Zeitpunkt mehr als 300.000 IPv4-Adressen sowie jeweils mehr als 100.000 Domains und URLs und wurde alle 15 Minuten aktualisiert. Auch nach diesem Wechsel berichtete der Kunde von weiteren Verbesserungen bei der Performance. Der oben ausgewertete Messzeitraum endet allerdings vor diesem Wechsel und belegt deshalb keinen zusätzlichen Performance-Gewinn durch Ultimate.

Der höhere Tarif war in diesem konkreten Fall immer noch deutlich günstiger als der Wechsel auf eine größere Firewall-Appliance einschließlich der dafür notwendigen Lizenzstufe. Das macht Ultimate aber nicht zur Standardempfehlung für jede Umgebung. Eine kleine Niederlassung mit wenigen öffentlichen Diensten braucht nicht automatisch die größte Liste und das kürzeste Aktualisierungsintervall. Bei diesem Kunden im Rechenzentrum mit vielen exponierten Web-, Mail- und Login-Diensten, hoher Anschlussleistung und einer sechsstelligen Zahl von Treffern pro Tag ergab die zusätzliche Abdeckung dagegen technisch und wirtschaftlich Sinn.

Produktive Netze ergänzen künstliche Sensoren um andere Dienste und Traffic-Profile. Daraus folgt aber keine automatische Überlegenheit: Auch andere Anbieter nutzen Produktionstelemetrie. Aussagekräftiger waren für uns die zusätzlich erfassten Quellen und deren tatsächlich beobachtetes Verhalten.

Im Vergleich fielen wiederholt IP-Adressen auf, die zum Prüfzeitpunkt nur in Cybora und in keiner der anderen von uns geprüften Listen enthalten waren. Bei der Untersuchung fanden wir in verfügbaren Firewall- und Applikationslogs auffällige Request-Folgen, ungewöhnliche URL-Pfade sowie automatisierte Login- oder Formularzugriffe. Ein früher IP-Drop selbst liefert allerdings keine HTTP-Pfade. Solche Nachweise müssen aus Beobachtungsphasen oder anderen korrelierbaren Logs stammen. Eine hohe Anfragerate allein beweist ebenfalls keinen Angriff. Für die Bewertung zählen das konkrete Verhalten und der Zeitpunkt der Listeneinträge, nicht nur die Exklusivität eines Treffers.

Ein Supportfall machte die Grenzen der IP-Blockierung besonders deutlich. Ein Kunde konnte eine benötigte Website nicht erreichen, weil ihre Shared-Hosting-IP auf der Liste stand. Die Untersuchung bestätigte eine Kompromittierung der Hosting-Infrastruktur. Die IP-Einstufung war damit nachvollziehbar, die legitime Website wurde aber ebenfalls gesperrt. Beides gehört zur Bewertung: ein begründeter Reputationstreffer und eine unerwünschte Auswirkung auf den Geschäftsbetrieb.

Eine IP-Regel kann verschiedene Websites unter derselben Adresse nicht auseinanderhalten. Solche Fälle zählen wir deshalb zu den betrieblichen Fehlalarmen beziehungsweise zum Ausnahmeaufwand. Eine Freigabe sollte, soweit technisch möglich, auf den benötigten Dienst und die betroffenen Benutzer begrenzt und erneut geprüft werden. Eine pauschale Freigabe der gesamten IP würde auch andere Inhalte derselben Infrastruktur wieder erreichbar machen. Der einzelne Supportkontakt war hilfreich für die Klärung dieses Falls, erlaubt aber keine allgemeine Bewertung von Reaktionszeiten.

Das Ergebnis dieser Aufbereitung ist technisch einfach: eine HTTPS-Adresse und eine Liste. Auf unterstützten Plattformen lässt sich die Übernahme in wenigen Minuten konfigurieren. Die verantwortbare Freigabe zum Blockieren braucht zusätzlich eine Prüfung im eigenen Traffic.

STIX und TAXII sind nicht dasselbe wie eine Blockliste

STIX und TAXII werden bei Threat Intelligence oft gemeinsam genannt, erfüllen aber verschiedene Aufgaben.

STIX, Structured Threat Information Expression, ist ein strukturiertes Datenmodell. Es kann nicht nur eine IP-Adresse beschreiben, sondern auch Malware, Kampagnen, Bedrohungsakteure, Angriffstechniken, Beobachtungen, Zeiträume, Vertrauensstufen und Beziehungen zwischen diesen Objekten. Ein Analyst kann damit ausdrücken, warum ein Indikator relevant ist und in welchem Kontext er beobachtet wurde.

TAXII, Trusted Automated Exchange of Intelligence Information, ist ein Protokoll zum Austausch solcher Cyber-Threat-Intelligence-Daten über HTTPS. Vereinfacht gesagt beschreibt STIX den Inhalt und TAXII den Transport beziehungsweise die API.

Für eine Threat Intelligence Platform, ein SIEM oder ein SOC ist dieser Kontext wertvoll. Eine Firewall benötigt für einen schnellen IP-Abgleich häufig nur eine daraus abgeleitete Adressmenge. Sie lädt die Indikatoren regelmäßig und prüft den Traffic gegen den lokal gehaltenen Bestand; das Austauschformat wird nicht für jedes Paket erneut verarbeitet. STIX/TAXII und eine TXT-Liste unterscheiden sich deshalb vor allem beim Informationsumfang und bei der Integration. Aus strukturierten Threat-Intelligence-Daten lassen sich gezielt einfache Listen für die Durchsetzung am Perimeter ableiten.

Was ein Threat Feed nicht kann

Das Messbeispiel und die hier bewertete IP-Abdeckung beziehen sich auf IPv4. Das entspricht dem Schwerpunkt der von mir betreuten Umgebungen, erlaubt aber keine Aussage über IPv6-Abdeckung. Wer Dienste zusätzlich über IPv6 veröffentlicht, muss deren Filterung gesondert prüfen; eine IPv4-Liste deckt diese Verbindungen nicht ab.

Ein Threat Feed blockiert bekannte Indikatoren. Er erkennt nicht automatisch einen neuen Angreifer auf einer sauberen IP-Adresse, einen legitimen Cloud-Dienst mit bösartigem Kunden, einen Angriff hinter einem CDN oder eine Schwachstelle in der eigenen Anwendung. IP-Adressen wechseln, Domains werden neu registriert und kompromittierte Systeme werden bereinigt oder neu vergeben.

Der Feed ersetzt deshalb weder Patch-Management noch MFA, IPS, WAF, EDR, sichere Firewall-Regeln und gute Protokollierung. Er ist eine zusätzliche, sehr frühe Entscheidungsschicht. Gerade bei DNAT, WAF, VPN-Portalen und Maildiensten kann diese Schicht enorme Mengen bekannten Rauschens abfangen, bevor teurere Kontrollen beginnen.

Ich würde einen neuen Feed immer zuerst beobachten, Ausschlüsse vorbereiten, Update- und Größenlimits der Firewall prüfen und einen klaren Prozess für False Positives definieren. Auch eine gute Liste braucht Vertrauen, das im eigenen Traffic verdient werden muss.

Mein Fazit

Die Messung zeigt nicht, dass eine Feed-Lizenz plötzlich eine 10-Gbit/s-Leitung oder eine größere Firewall ersetzt. Sie zeigt etwas Nützlicheres: Auf dieser einzelnen Firewall wurden in gut 34 Stunden mehr als eine halbe Million bekannte unerwünschte Verbindungsereignisse früh gestoppt.

Für den Kunden zählte die Verbesserung im Alltag: Die Firewall ließ sich wieder deutlich flüssiger administrieren, Webseiten und Anwendungen reagierten nach seiner Rückmeldung wesentlich schneller. Das ist ein relevantes Betriebsergebnis, auch wenn die vorhandenen Daten den ursprünglichen Engpass nicht eindeutig identifizieren. Die dokumentierten Block-Events ergänzen diese Erfahrung um den Nachweis, dass der Feed regelmäßig unerwünschte Quellen abwies.

Cybora war in unserem zwölfmonatigen Vergleich der beste Allround-Feed für diesen Einsatzzweck. CrowdSec, GreyNoise, Spamhaus, abuse.ch und andere Quellen bleiben trotzdem wertvoll, oft sogar besser für ihre jeweilige Spezialdisziplin. Die richtige Frage lautet nicht „Welcher Anbieter hat die längste Liste?“, sondern „Welche Daten sind für meine exponierten Dienste aktuell, präzise und sicher blockierbar?“

Bis zum nächsten Mal,
Euer Joe

FAQ