Threat Feeds pour pare-feu : efficacité, limites et fournisseurs comparés

Internet regorge de systèmes qui analysent automatiquement les adresses publiques. Ils cherchent des ports ouverts, des pages de connexion, des portails VPN, des applications web connues et des services vulnérables. Certains appartiennent à des chercheurs en sécurité ou à des moteurs d’inventaire d’Internet ; d’autres sont des bots et des attaquants à la recherche de failles exploitables.

Quiconque publie un service derrière un WAF, une règle DNAT, une passerelle de messagerie ou un portail de connexion apparaîtra tôt ou tard dans ces analyses. Une IP publique ne signifie pas qu’un système est compromis. Mais dès qu’un service répond, ce bruit de fond crée du travail pour le pare-feu, l’IPS, le WAF, le serveur, l’application et la journalisation.

Pour moi, ingénieur sécurité, ce phénomène est quotidien. Nous rencontrons régulièrement des pare-feu, des WAF et des services publics qui consacrent une part notable de leurs ressources aux scans, tentatives de connexion, robots d’indexation et recherches automatisées d’exploits. Il s’agit rarement d’une attaque unique et spectaculaire.

J’ai récemment participé à l’analyse d’un cas dont l’ampleur nous a surpris. Un pare-feu dans un centre de données disposait d’une liaison montante de 10 Gbit/s et, en principe, de bonnes réserves de performance. Il semblait pourtant saturé : la liaison était très sollicitée, l’administration lente et les services exposés produisaient continuellement des événements.

Nous avons étudié les flux par sens, destination, port, période et adresse source récurrente. De nombreuses requêtes automatisées visaient les mêmes services web, mail et de connexion. Leur coût ne se résume pas à leur nombre : rejeter un paquet, négocier TLS et traiter une requête applicative complexe consomment des ressources différentes.

Nous avons expliqué au client qu’une part importante de l’activité provenait de bots et de scanners revenant sans cesse vers ses services. Nous lui avons présenté l’apport possible d’un Threat Feed, ses limites et le coût d’environ 350 dollars américains par an. Après son accord, nous avons installé la liste sur le pare-feu en quelques clics. La configuration a pris quelques minutes.

L’interface d’administration est alors devenue nettement plus réactive. Le client nous a également indiqué que ses sites et applications chargeaient bien plus vite. La différence était sensible pour les administrateurs comme pour les utilisateurs.

L’intérêt du cas tient à cet effet concret. Un feed n’est pas une nouveauté pour moi, mais beaucoup d’administrateurs en comprennent mal la portée : simple fichier d’IP pour les uns, substitut à l’IPS, au WAF ou à l’EDR pour les autres. Il faut examiner l’origine et l’âge des indicateurs, le retrait des faux positifs et l’endroit où le pare-feu applique la décision. Voici donc les mesures et leur explication technique.

Le résultat en chiffres

Les mesures proviennent d’un pare-feu en production. Le feed IP a pris effet le 1er septembre 2026 à 10:01:05 ; le premier événement a suivi quelques secondes plus tard. Au 2 septembre à 20:30 CEST, 516 959 événements de blocage étaient enregistrés.

La moyenne sur toute la période est de 249,9 événements par minute, soit 4,17 par seconde ou un toutes les 0,24 seconde. La minute la plus chargée comptait 775 événements. Le maximum, 107 événements en une seconde, s’est produit pendant deux secondes consécutives.

Je parle délibérément d’événements de blocage, de correspondances ou de tentatives de connexion. Ils ne représentent pas 516 959 attaques indépendantes et manuelles. Un scanner peut solliciter souvent le même service ; un bot peut essayer plusieurs ports ; une connexion échouée peut produire des paquets supplémentaires.

Qui frappait à la porte ?

Sur 34 heures et 29 minutes, 516 727 événements étaient entrants et 232 concernaient des connexions sortantes empêchées. Dans cet environnement, 99,955 % de l’activité du feed portait donc sur des sources Internet.

On compte 10 518 IP listées distinctes. Le feed contenait alors 220 000 indicateurs IPv4 : environ 4,8 % de la liste se sont révélés pertinents sur ce seul pare-feu en quelque 34 heures. L’adresse la plus active a généré 4 141 événements, les dix premières environ 31 500 ensemble, tandis que 767 adresses n’apparaissaient qu’une fois.

Ces 4,8 % comparent des volumes, ce n’est pas un taux de détection. La liste évolue et le compteur ignore les attaquants inconnus ou absents du feed.

La répartition par port couvre une fenêtre glissante de 24 heures et environ 369 000 événements détaillés :

Environ 56 % des événements visaient des ports web et 40 % des ports de messagerie. La fenêtre détaillée couvrait 27 destinations internes. Les noms des services sont déduits des ports, sans confirmation par analyse du protocole. Cette fenêtre glissante de 24 heures ne correspond pas aux premières 24 heures après activation : les totaux ne sont pas directement comparables.

Les 232 correspondances sortantes concernaient dix systèmes internes et 17 adresses de destination listées. Elles ne prouvent pas une infection, mais méritent une enquête : malware, contenu tiers, entrée périmée ou service légitime sur une IP réattribuée.

Après le changement, l’interface du pare-feu a mieux répondu et le client a signalé des chargements plus rapides. L’ancien goulot pouvait se trouver dans le pare-feu, les serveurs, les applications ou le lien. Les événements prouvent le filtrage, pas les ressources économisées ni un gain de performance en pourcentage.

Auparavant, les requêtes automatisées atteignaient effectivement les serveurs web et applicatifs, qui répondaient même aux chemins inexistants. Le blocage précoce a évité ce travail en aval. La recherche dans la liste consomme aussi des ressources ; le bénéfice vient des traitements ultérieurs évités. L’ordre dépend de la plateforme et de sa configuration. Le premier paquet atteint toujours le WAN : une attaque DDoS volumétrique exige une protection en amont.

Ce que fait réellement un Threat Feed

Un feed simple est souvent un fichier texte téléchargé par HTTPS. Les fournisseurs proposent des listes d’IP, mais aussi de domaines et d’URL. Dans la plupart de nos déploiements, nous utilisons surtout les IP, car elles produisent l’effet le plus utile pour le blocage précoce sur pare-feu. Celui-ci actualise les indicateurs à intervalle défini et vérifie le trafic correspondant. Selon la configuration, il journalise ou bloque.

La fiabilité dépend des décisions prises avant la publication :

• Le comportement était-il malveillant ou seulement inhabituel ?
• L’observation est-elle récente ?
• Des sources indépendantes la confirment-elles ?
• Quand retire-t-on un indicateur périmé ?

Une longue liste n’est pas forcément une bonne intelligence. Actualité, précision et retrait régulier comptent davantage. Une IP dynamique de cloud ou d’hébergement peut retrouver un usage légitime. À l’inverse, une liste très prudente limite les faux positifs, mais peut manquer une grande partie des scans quotidiens.

Comparaison des Threat Feeds pour pare-feu

Autant donner le nom d’emblée : beaucoup de mes collègues et moi utilisons un feed de Cybora. Je protège aussi ainsi les services publics de mes propres serveurs cloud. Ce choix vient d’une comparaison en exploitation, pas d’une démonstration commerciale.

Pendant douze mois, nous avons évalué plus de 30 sources commerciales et publiques sur 15 pare-feu de clients. Nous avons dépensé plusieurs milliers de dollars pour des offres allant du gratuit à près de 1 000 dollars par mois. Un prix élevé ne garantissait pas une liste plus large : certaines offres chères étaient nettement plus petites.

Tous les feeds tournaient en mode Monitor sur les 15 pare-feu : ils journalisaient les correspondances sans bloquer. Cette comparaison est distincte du déploiement bloquant dans le centre de données. Les journaux du pare-feu et des applications nous ont permis d’évaluer activité malveillante, couverture supplémentaire, fraîcheur et faux positifs possibles. Nous regroupions les événements répétés et examinions aussi les connexions légitimes qui auraient été bloquées.

Il s’agit d’un retour d’expérience, pas d’un benchmark reproductible. Chevauchements, ordre d’évaluation et autres protections influencent les journaux Monitor ; l’absence de trace ne prouve pas une lacune. Je ne publie pas tous les états horodatés des listes, réglages et cas vérifiés.

Ces onze offres ne sont pas un classement de popularité. Cybora figure en premier en raison de notre expérience.

Cybora

Cybora nous a offert le meilleur équilibre entre couverture, fraîcheur, correspondances utiles, gestion des faux positifs, intégration, support et prix. Les premiers forfaits sont abordables ; Ultimate publie toutes les 15 minutes, ce qui intéresse les infrastructures très exposées.

Cybora se spécialise dans les feeds pour pare-feu. Selon l’entreprise, son analyse associe aux données de honeypots des signaux issus de pare-feu de production de clients qui choisissent de fournir ces signaux. Ces équipements observent des attaques contre de vrais services accessibles sur Internet. Dans notre comparaison, nous avons régulièrement trouvé des IP suspectes qui ne figuraient alors que chez Cybora. Pour plusieurs IP liées à des tentatives de force brute dans nos journaux, Cybora les avait inscrites quelques jours avant d’autres feeds qui les ont ajoutées ensuite. Cette couverture supplémentaire et plus précoce représentait pour nous une différence de qualité tangible.

CrowdSec Blocklists

CrowdSec Blocklists associe moteur open source, signaux communautaires et listes organisées distribuables aux pare-feu. La télémétrie de production et les listes spécialisées sont précieuses, mais un feed sur les CMS, les proxies ou un CVE ne couvre pas forcément tous les risques à la périphérie.

GreyNoise

GreyNoise fournit des listes IP utilisables sur pare-feu et construites par requêtes GNQL. On peut sélectionner une activité récente ou liée à certains CVE. Il faut concevoir et revoir les requêtes, ainsi que disposer des modules nécessaires. GreyNoise ne se limite pas à l’enrichissement des journaux.

Q-Feeds

Q-Feeds annonce regrouper plus de 2 500 sources commerciales, ouvertes et publiques et proposer des feeds IP, domaines et URL avec contrôle qualité. Lors de notre essai en Monitor, plusieurs connexions légitimes ont correspondu à la liste dès la première heure ; elles auraient été bloquées en mode actif. Nous avons vérifié les journaux et signalé ces faux positifs potentiels. Le support a retiré les entrées assez vite, mais la charge d’analyse nous a conduits à ne plus signaler systématiquement les cas suivants.

Le nombre de sources ne suffit pas à expliquer ces correspondances. Sans connaître l’origine et l’évaluation de chaque IP, nous n’avons pas pu établir la cause. Pour un blocage généralisé chez nos clients, la charge prévisible d’exceptions et de support était trop forte. Q-Feeds peut néanmoins servir à la surveillance ou à l’enquête.

Spamhaus DROP

Spamhaus DROP est une liste prudente de réseaux particulièrement dangereux, destinée au filtrage en bordure ou au routage. Son seuil d’inscription élevé inspire confiance, mais ne couvre pas tous les scanners éphémères.

ThreatFox

ThreatFox d’abuse.ch et Spamhaus se concentre sur les indicateurs de malware, notamment les infrastructures de commande et contrôle. Excellent pour la détection et le threat hunting, il est plus ciblé qu’un feed général contre les scans, la force brute et les exploits automatisés.

URLhaus

URLhaus d’abuse.ch recense les URL qui distribuent des malwares. Il est utile aux filtres DNS, proxies, passerelles web et outils d’analyse, mais plus spécialisé pour le seul blocage IP. Son API exige une clé ; l’accès communautaire n’autorise pas nécessairement un usage commercial illimité.

DShield

DShield publie une liste recommandée compacte issue de logs de pare-feu transmis. Les autres jeux de données DShield servent surtout à l’analyse et ne doivent pas devenir des listes de blocage sans sélection.

FireHOL IP Lists

FireHOL IP Lists agrège et surveille de nombreuses listes publiques. Il facilite la comparaison de leur taille, âge, rythme de mise à jour et chevauchement, mais hérite aussi de leurs défauts : des entrées reprises par plusieurs sources peuvent durer trop longtemps.

AbuseIPDB

AbuseIPDB propose une réputation IP fondée sur les signalements et une liste texte à seuil de confiance réglable. Un score élevé ne prouve pas que toute connexion actuelle est malveillante. L’âge des rapports, les IP partagées et les limites de requêtes selon l’offre comptent.

IPsum

IPsum agrège quotidiennement plus de 30 listes et offre des seuils selon leur nombre de correspondances. Trois listes concordantes ne sont pas forcément trois observations indépendantes si elles se recopient. Son rythme quotidien limite la réactivité ; c’est un complément transparent, pas une source autonome de télémétrie.

Gratuit n’est pas synonyme de mauvais, ni commercial de bon. Certaines sources publiques excellent dans leur domaine. Pour une protection générale appliquée directement au périmètre, notre expérience favorise un feed continuellement organisé, complété au besoin par des sources spécialisées.

Pourquoi Cybora est arrivé en tête

C’est mon blog personnel et je ne touche aucune commission. Mon employeur revend toutefois des licences Cybora avec une marge ; je signale ce lien. Notre choix découle de la comparaison pratique décrite.

Dans le cas présenté, nous avons commencé avec Premium, à 349 dollars par an et des mises à jour horaires. Selon sa documentation publique, Cybora associe OSINT, sources commerciales, honeypots, capteurs et télémétrie réelle de pare-feu. Les indicateurs sont évalués selon leur fraîcheur, confiance et concordance, dédupliqués et soumis à des exclusions avant publication en liste HTTPS. Premium contenait alors 220 000 IPv4, 45 000 domaines et 25 000 URL. Sur le pare-feu mesuré, les IP étaient en Block, les domaines initialement en Monitor.

Une semaine plus tard, le client a choisi Ultimate : plus de 300 000 IPv4 et plus de 100 000 domaines et URL de chaque catégorie, avec publication toutes les 15 minutes. Il a signalé d’autres améliorations de performance, mais la fenêtre analysée précède ce changement et ne démontre aucun gain supplémentaire dû à Ultimate. Ce forfait coûtait néanmoins bien moins qu’un pare-feu plus puissant avec sa licence. Ce n’est pas une recommandation générale : ici, le nombre de services web, mail et de connexion exposés, la liaison rapide et les centaines de milliers de correspondances quotidiennes rendaient le choix pertinent.

Nous avons retrouvé à plusieurs reprises des IP présentes, au moment de la vérification, uniquement chez Cybora. Les journaux disponibles montraient des séquences de requêtes inhabituelles, des chemins URL et des tentatives automatisées sur les connexions ou formulaires. Un blocage IP précoce ne révèle pas les chemins HTTP : ces preuves viennent d’une phase d’observation ou d’autres journaux corrélables. Une fréquence élevée ne prouve pas non plus une attaque ; le comportement et la date d’inscription comptent.

Un cas a illustré la limite du blocage IP : un site nécessaire à un client partageait une adresse listée avec une infrastructure d’hébergement compromise. Le classement se justifiait, mais le site légitime était également inaccessible. Une règle IP ne distingue pas les sites d’une même adresse. Nous comptons donc ces cas dans la charge d’exceptions : si possible, il faut limiter l’autorisation au service et aux utilisateurs concernés, puis la réexaminer. L’enjeu n’est pas seulement de justifier une entrée, mais de pouvoir appliquer la liste sans charge opérationnelle excessive.

Les limites d’un Threat Feed

Nos mesures concernent IPv4. Les services également accessibles en IPv6 exigent une protection distincte : une liste IPv4 ne filtre pas ces connexions.

Un feed bloque des indicateurs connus. Il ne repère pas automatiquement un nouvel attaquant utilisant une IP propre, un client malveillant sur une plateforme cloud légitime, une attaque derrière un CDN ou une faille applicative. Les adresses changent, les domaines naissent et les systèmes compromis sont nettoyés ou réattribués. Il ne remplace donc ni correctifs, MFA, IPS, WAF, EDR, règles sûres ni bons journaux. Il ajoute une décision précoce particulièrement utile pour DNAT, WAF, VPN et messagerie.

Je commencerais toujours par observer un nouveau feed, préparer les exclusions, vérifier limites de taille et mises à jour du pare-feu, puis définir une procédure pour les faux positifs. La confiance se gagne avec le trafic local.

Mon bilan

Ces mesures ne prouvent pas qu’une licence remplace une liaison de 10 Gbit/s ou un pare-feu plus grand. Elles montrent que cet équipement a arrêté tôt plus d’un demi-million d’événements indésirables connus en un peu plus de 34 heures. Le client a constaté une administration plus fluide et des services plus rapides. Nous ne savons pas quel était le goulot initial ; les logs démontrent l’action du feed, pas un pourcentage de gain.

Cybora a été notre meilleur feed général pour cet usage pendant les douze mois d’essais. CrowdSec, GreyNoise, Spamhaus, abuse.ch et les autres restent utiles, parfois meilleurs dans leur spécialité. La vraie question est de savoir quels indicateurs sont récents, précis et peuvent être bloqués sans risque excessif pour ses services.

À la prochaine,
Joe

FAQ