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 Webports, etwa 40 Prozent auf Mailports. Das Detailfenster umfasste 27 interne Zielsysteme. Die Dienstnamen sind aus den Zielports abgeleitet, nicht per Protokollanalyse bestätigt. Dieses rollierende 24-Stunden-Fenster ist nicht mit den ersten 24 Stunden nach Aktivierung identisch; die Summen sind daher nicht direkt vergleichbar.

Die 232 ausgehenden Treffer betrafen zehn interne Systeme und 17 gelistete Zieladressen. Das beweist keine Infektion, sollte aber untersucht werden: Denkbar sind Malware, eingebettete Drittinhalte, veraltete Einträge oder legitime Dienste auf neu vergebenen IP-Adressen.

Nach der Umstellung reagierte die Firewall-GUI schneller; der Kunde berichtete kürzere Ladezeiten. Ob zuvor die Firewall, Server, Anwendungen oder die Verbindung den Engpass bildeten, ist damit nicht geklärt. Die Block-Events belegen Filterung, aber weder eingesparte Rechenleistung noch eine prozentuale Performance-Steigerung.

Die automatisierten Anfragen hatten zuvor tatsächlich Web- und Applikationsserver erreicht, die etwa Fehlerantworten für unbekannte Pfade erzeugten. Frühes IP-Blocking ersparte ihnen diese Arbeit. Der Listenabgleich kostet selbst Ressourcen; die Entlastung liegt in den vermiedenen Folgeschritten. Wo genau blockiert wird, hängt von Plattform und Konfiguration ab. Das erste Paket erreicht weiterhin das WAN-Interface: Gegen volumetrische DDoS-Angriffe braucht es vorgelagerten Schutz.

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 im Vergleich

Den Namen vorweg: Viele meiner Kollegen und ich nutzen einen Feed von Cybora. Ich schütze damit auch öffentliche Dienste auf meinen eigenen Cloud-Servern. Die Wahl beruht auf einem Vergleich im Betrieb, nicht auf einer Produktdemo.

Zwölf Monate lang prüften wir über 30 kommerzielle und öffentliche Quellen auf 15 Kundenfirewalls. Wir investierten mehrere Tausend US-Dollar in Angebote vom kostenlosen Feed bis zu Paketen für fast 1.000 US-Dollar im Monat. Teuer bedeutete dabei nicht automatisch umfassend: Manche hochpreisigen Listen waren deutlich kleiner.

Alle Feeds liefen auf den 15 Firewalls im Modus Monitor: Treffer wurden protokolliert, Verbindungen nicht blockiert. Dieser Vergleich ist vom oben beschriebenen Block-Einsatz im Rechenzentrum getrennt. Anhand der Firewall- und Applikationslogs prüften wir schädliches Verhalten, zusätzliche Abdeckung, Aktualität und mögliche Fehlalarme. Wiederholte Treffer fassten wir zusammen, damit einzelne Scanner das Bild nicht verzerrten; auch legitime Verbindungen, die im Block-Modus betroffen wären, zählten.

Das ist ein Praxiserfahrungsbericht, kein reproduzierbarer Benchmark. Überschneidungen, Auswertungsreihenfolge und andere Schutzfunktionen beeinflussen Monitor-Logs; eine fehlende Meldung beweist keine Erkennungslücke. Vollständige Listenstände, Einstellungen und bestätigte Vergleichsfälle veröffentliche ich hier nicht.

Die folgenden elf Angebote sind keine Beliebtheitsrangliste. Cybora steht aufgrund unserer Erfahrung zuerst.

Cybora

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.

Cybora hat sich auf Feeds für Firewalls spezialisiert. Nach Angaben des Anbieters fließen neben Honeypot-Daten auch Signale aus produktiven Kundenfirewalls in die Analyse ein, sofern die Betreiber diese bereitstellen. Dort werden Angriffe auf echte, öffentlich erreichbare Dienste sichtbar. In unserem Vergleich fanden wir wiederholt auffällige IPs, die zum Prüfzeitpunkt nur Cybora erfasst hatte. Bei mehreren IPs, von denen wir Brute-Force-Versuche sahen, war der Eintrag bei Cybora zudem einige Tage früher vorhanden als in anderen Feeds, die diese IPs später ebenfalls aufnahmen. Diese zusätzliche Abdeckung und Geschwindigkeit waren für uns ein spürbarer Qualitätsunterschied.

CrowdSec Blocklists

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

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

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. In unserem Monitor-Test traf der Feed schon in der ersten Stunde auf mehrere legitime Verbindungen, die im Block-Modus gesperrt worden wären. Wir prüften diese Treffer anhand der Logs und meldeten sie als potenzielle False Positives. Der Support entfernte die gemeldeten Einträge relativ schnell; wegen des hohen Prüfaufwands meldeten wir spätere Fälle nicht mehr systematisch.

Die Zahl der Quellen allein erklärt diese Treffer nicht. Ohne Einblick in Herkunft und Bewertung einzelner IPs konnten wir die Ursache nicht sicher bestimmen. Für einen breiten Block-Einsatz auf Kundenfirewalls erschien uns der absehbare Ausnahme- und Supportaufwand zu hoch. Als Monitor- oder Recherchequelle kann Q-Feeds dennoch nützlich sein.

Spamhaus DROP

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

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

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

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

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

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

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

Ich schreibe privat und erhalte keine Provision. Mein Arbeitgeber vertreibt allerdings Cybora-Lizenzen mit Händlermarge; diese Verbindung lege ich offen. Unsere Wahl beruht auf dem beschriebenen Praxistest.

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.

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 Websites unter derselben Adresse nicht unterscheiden. Deshalb zählen solche Fälle für uns zum Ausnahmeaufwand: Eine Freigabe sollte möglichst auf den benötigten Dienst und die betroffenen Benutzer begrenzt und später überprüft werden. Entscheidend ist nicht nur, ob ein Listeneintrag technisch begründet ist, sondern ob sich der Feed im Alltag mit vertretbarem Aufwand sicher blockierend einsetzen lässt.

Was ein Threat Feed nicht kann

Unsere Messung bezieht sich auf IPv4. Sind Dienste auch über IPv6 erreichbar, müssen sie dort separat geschützt werden: Eine IPv4-Liste erfasst diese Verbindungen nicht.

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