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 % visaient des ports web et 40 % des ports mail, ce qui correspond aux services publiés. Vingt-sept systèmes internes ont été visés pendant cette fenêtre. Les noms des services sont déduits des ports de destination, pas confirmés par une analyse du protocole. La fenêtre glissante diffère des premières 24 heures suivant l’activation ; leurs totaux ne doivent pas être comparés directement.

Les 232 correspondances sortantes sont peu nombreuses, mais méritent une enquête. Dix systèmes internes ont tenté de joindre 17 destinations listées. Ce n’est pas la preuve d’une infection : communication malveillante, contenu tiers, entrée périmée ou IP réattribuée à un service légitime sont des possibilités.

La réactivité accrue de l’interface et la baisse des temps de chargement signalée par le client sont des observations après changement. Nous n’avons pas isolé le goulot d’étranglement initial, qu’il se soit trouvé dans le pare-feu, les serveurs, les applications ou la liaison. Les événements prouvent le filtrage, sans mesurer les temps de chargement ni la puissance économisée. Aucun pourcentage de gain de performance n’en découle.

Dans ce cas, les requêtes automatisées atteignaient auparavant les serveurs web et applicatifs. Ils devaient les traiter et, par exemple, répondre par une erreur pour un chemin inexistant. Le blocage précoce a supprimé ce travail pour les requêtes concernées. Le pare-feu pouvait également les rejeter avant de les transférer et de poursuivre leur traitement. La consultation de la liste coûte elle-même des ressources ; le gain vient des étapes suivantes évitées.

L’ordre et la portée du filtrage dépendent de la plate-forme et de la configuration, notamment pour le WAF et les services hébergés sur le pare-feu. Le premier paquet arrive toujours sur l’interface WAN. Le rejet local peut éviter les réponses et le trafic ultérieur, sans remplacer une protection en amont contre les DDoS volumétriques.

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.

Threat Feeds pour les pare-feu

Autant le dire d’emblée : le fournisseur que beaucoup de mes collègues et moi utilisons est Cybora. Je l’emploie aussi sur les services publics de mes propres serveurs cloud. Ce choix repose sur une comparaison en production, pas sur une démonstration commerciale.

Pendant douze mois, nous avons testé plus de 30 fournisseurs commerciaux et sources publiques sur 15 pare-feu de clients. Nous avons souscrit les abonnements utiles, dépensé plusieurs milliers de dollars et comparé des listes gratuites à des offres approchant 1 000 dollars par mois. Certains produits chers avaient des listes plus petites et mettaient surtout en avant leur fraîcheur et leur précision.

Tous les feeds étudiés ont été installés sur les 15 pare-feu en mode Monitor : ils signalaient les correspondances sans bloquer eux-mêmes. Nous pouvions les examiner dans le trafic réel et le contexte du service concerné. Cette comparaison prolongée est distincte du blocage déployé dans le centre de données.

Nous avons comparé les sources détectées et étudié requêtes suspectes et faux positifs possibles à l’aide des journaux disponibles. Nous recherchions les activités malveillantes confirmées, la couverture supplémentaire, l’actualité et le coût des exceptions. Taille et prix ne suffisent pas. Nous avons regroupé les événements répétés pour qu’un scanner très actif ne fausse pas le résultat et examiné les connexions légitimes qui auraient été empêchées.

Il s’agit d’une expérience en production, pas d’un essai de laboratoire standardisé. L’ordre d’évaluation, les recoupements entre listes et d’autres défenses peuvent influencer les logs. L’absence d’un événement ne prouve pas un défaut de détection. Un benchmark reproductible demanderait des instantanés datés des listes, les paramètres d’évaluation et des cas positifs et négatifs confirmés ; nous ne publions pas toutes ces données.

Ces onze offres forment une sélection éditoriale, pas un classement de popularité ni de performances. AbuseIPDB et IPsum sont des options documentées sans résultats pratiques revendiqués. Cybora apparaît en premier du fait de notre expérience ; l’ordre suivant n’est pas mesuré. Les données Q-Feeds ont été vérifiées le 28 septembre 2026, celles des autres produits le 8 septembre 2026.

Cybora nous a offert le meilleur équilibre entre couverture, fraîcheur, correspondances utiles, faux positifs, intégration, support et prix. Les premiers forfaits sont abordables ; Ultimate propose une publication toutes les 15 minutes pour des infrastructures très exposées. Cet intervalle ne dit rien du temps nécessaire à la détection initiale, puis s’ajoutent téléchargement et importation. Deux réponses HTTP 429 figurent dans les données : la liste locale est restée active et la récupération suivante a abouti. Il faut surveiller l’âge de la liste et les échecs de mise à jour.

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 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 dit organiser des indicateurs de plus de 2 500 sources commerciales, ouvertes et gouvernementales en listes IP, domaines et URL, avec contrôles de qualité et suppression de faux positifs. Notre expérience a été moins bonne : dès la première heure d’un déploiement bloquant, plusieurs accès légitimes ont été refusés. Nous avons examiné les flux concernés et jugé les cas vérifiés comme des faux positifs. Le support a retiré assez vite les entrées signalées. La charge d’analyse et de signalement restait telle que nous avons cessé de remonter systématiquement les cas ultérieurs.

Le nombre de sources n’explique pas à lui seul ces erreurs. Sans connaître l’origine, la justification et la réévaluation de chaque IP, nous ne pouvions pas déterminer leur cause. Pour un blocage généralisé sur des pare-feu de clients, la charge d’exceptions et de support observée nous a semblé trop importante. Q-Feeds peut avoir un autre intérêt pour la surveillance ou l’enquête ; notre jugement porte sur le blocage dans nos environnements.

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

Par transparence : c’est mon blog personnel et je ne touche aucune commission. Mon employeur revend toutefois Cybora et achète des licences à tarif réduit pour les revendre avec une marge. Cette relation commerciale aide à interpréter ma recommandation. Notre choix venait de l’expérience décrite, pas des conditions de revente.

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.

La télémétrie de réseaux réels complète les capteurs artificiels par d’autres services et profils de trafic. Elle ne garantit pas la supériorité, et d’autres fournisseurs l’utilisent aussi. Nous avons surtout examiné les sources supplémentaires trouvées et leur comportement. Des IP présentes alors uniquement chez Cybora apparaissaient dans des séquences de requêtes suspectes, chemins URL inhabituels et tentatives automatisées de connexion ou de formulaire. Un rejet IP précoce ne révèle pas de chemins HTTP ; il faut des phases Monitor ou d’autres journaux corrélables. Une cadence élevée ne suffit pas non plus à prouver une attaque : comportement et date d’inscription comptent.

Un cas de support a montré une limite : un site nécessaire partageait une IP d’hébergement avec une infrastructure compromise. La réputation de l’IP était justifiée, mais le site légitime a été bloqué. Une règle IP ne distingue pas plusieurs sites à la même adresse. Nous comptons donc ces cas comme faux positifs opérationnels ou charges d’exception. Il faut, si possible, limiter une exception au service et aux utilisateurs concernés puis la revoir ; autoriser toute l’IP rétablirait aussi d’autres contenus. Un seul échange avec le support ne permet pas de juger ses délais habituels.

Le résultat technique reste simple : une adresse HTTPS et une liste, configurables en quelques minutes sur les plateformes compatibles. L’application responsable des blocages exige cependant une vérification sur son propre trafic.

STIX et TAXII ne sont pas une liste de blocage

STIX (Structured Threat Information Expression) est un modèle structuré pour décrire IP, malwares, campagnes, acteurs, techniques, observations, périodes, confiance et relations. Il donne le contexte d’un indicateur. TAXII (Trusted Automated Exchange of Intelligence Information) est le protocole HTTPS servant à échanger ces données : STIX décrit le contenu et TAXII le transport ou l’API.

Cette richesse aide les plateformes de renseignement, SIEM et SOC. Pour vérifier vite des IP, le pare-feu peut n’utiliser qu’un ensemble d’adresses dérivé de ces données, téléchargé régulièrement et conservé localement. Il ne traite pas STIX/TAXII à chaque paquet. Une liste TXT contient moins de contexte, mais peut servir à appliquer au périmètre une sélection issue de données structurées.

Les limites d’un Threat Feed

Notre mesure et la couverture IP évaluée concernent IPv4, majoritaire dans les environnements que je gère. Elles ne démontrent rien sur IPv6. Des services également publiés en IPv6 exigent une vérification distincte : une liste IPv4 ne les couvre pas.

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