Reputation d'adresse : les listes, et ce qu'on en fait¶

Ce document evalue les listes de blocage proposees par la console CrowdSec, et definit comment la reputation entre dans notre decision. Il complete docs/scoring.md : la reputation est un a priori, pas un verdict.

Le catalogue, tel qu'il est propose¶

La console presente quatorze listes en acces libre, avec trois abonnements gratuits par moteur, et un choix de remediation au moment de l'abonnement : ban, captcha, ou une action personnalisee. Le rafraichissement est de deux heures, et l'activation peut prendre jusqu'a deux heures de plus.

Les quatorze, classees par ce qu'elles valent reellement sur un bord HTTP :

Deux constats qui se degagent du tableau. Les listes comportementales non-HTTP (force brute SSH, VoIP) n'ont pas de sens a l'edge web : elles bloqueraient des adresses qui n'attaquent pas votre service. Et les listes CVE sont les plus rentables du lot : elles ciblent une tentative d'exploitation precise, donc leur taux de faux positifs est structurellement faible, et elles se periment vite, ce qui est une bonne chose.

Les tailles reelles, mesurees¶

Releve du 19 octobre 2026, en comptant les entrees des fichiers publics :

• noeuds de sortie Tor (liste officielle du projet Tor, relevee par tools/addr_lists.py) : 1 221 adresses, compactees en 558 plages ;
• firehol_level1, l'agregat a faible bruit de FireHOL : 4 635 entrees ;
• firehol_anonymous, les proxys anonymes : 2 906 430 entrees ;
• firehol_proxies : 2 904 505 entrees.

Le dernier chiffre est le plus important, et c'est celui qu'on ne voit pas dans la console : une liste de proxys, c'est pres de trois millions d'adresses. Ce n'est pas un detail d'implementation, c'est un choix d'architecture. Il faut un magasin en memoire, un parcours par prefixe, et un chargement incremental. Une correspondance par expression reguliere ou par balayage de liste tiendrait le chemin chaud a l'arret.

En memoire, trois millions de plages tiennent dans quelques dizaines de megaoctets compresses en intervalle, ce qui est acceptable sur un noeud de bord, mais ce n'est pas gratuit.

Le probleme de licence, qu'il faut regarder avant de vendre¶

FireHOL agrege plus de trois cent cinquante sources, et son propre README est explicite : plusieurs de ces listes portent une licence particuliere, et il faut verifier la source avant usage. Autrement dit, l'agregation ne confere aucun droit : chaque fichier garde le regime de son producteur.

Consequence directe pour un produit revendu : on ne peut pas embarquer « FireHOL » en bloc et le presenter comme un composant maison. Il faut, pour chaque source retenue, verifier si la redistribution et l'usage commercial sont permis. Certaines le permettent, d'autres demandent une licence, d'autres interdisent l'usage commercial.

Les listes CVE et scanners diffusees par CrowdSec meritent le meme examen. Elles sont produites par l'editeur et livrees par sa plateforme : les conditions d'usage sont celles de CrowdSec, pas celles du hub, qui ne couvre que les scenarios.

Donc, pour une offre en marque blanche, la regle de conduite est simple : toute liste tierce doit avoir sa licence verifiee et archivee avec le produit, et les listes sans licence claire sont exclues.

Ou placer la reputation dans la decision¶

Trois niveaux de confiance, trois traitements differents. Confondre les trois est l'erreur classique, celle qui produit des blocages inexplicables.

Niveau 1, certitude. L'adresse appartient a une liste d'attaquants sur une CVE precise, ou a un scanner vu sur un pot de miel dans les dernieres heures. Traitement : drop, directement, sans passer par le score. Ces listes sont petites, fraiches, et une adresse qui scanne n'a rien a faire sur votre site.

Niveau 2, presomption. L'adresse est un proxy ouvert, un noeud Tor, un hote sur DNS dynamique. Traitement : points dans le score, jamais un refus direct. Ce sont des adresses de vrais utilisateurs, y compris des personnes qui choisissent un proxy pour des raisons legitimes. Un captcha est le bon niveau, parce qu'il coute peu a un humain et beaucoup a un parc automatise.

Niveau 3, indice. Surveillance de l'appartenance a un hebergeur, a un systeme autonome atypique, ou a un pays en decalage avec le reste du trafic. Traitement : poids faible, agrege avec le reste, jamais decisif seul.

Deux garde-fous, dans tous les cas :

• Jamais un blocage sur une seule source. Une adresse residentielle infectee hier et nettoyee aujourd'hui reste un vrai client. Une confirmation par un second signal, ou par le comportement observe, est la condition d'un blocage.
• Une duree sur chaque decision. Une liste rafraichie toutes les deux heures ne dit rien sur ce que fera l'adresse dans une semaine. Une decision de reputation doit expirer, et un score doit decroitre avec le temps.

Le reseau (ASN), desormais branche¶

Le niveau 2 et le niveau 3 ne sont plus une intention : cinq listes de prefixes, generees depuis les ASN annonces, entrent dans le score. Le detail des poids et leur justification sont dans docs/scoring.md, section « La reputation du reseau ». Ce qui compte ici, c'est la provenance et la limite.

La selection d'ASN est ecrite a la main dans tools/asn_lists.py, regroupee en cinq categories : hebergement pare-balles (refus), VPN (40), Tor (45), services de proxy (40), cloud et hebergeurs a risque (15), puis le cloud en libre-service (12). Les prefixes viennent des routes annoncees, interrogees une fois par ASN (RIPEstat), et le resultat est versionne : le bord ne depend d'aucun reseau au demarrage, et une revision de la liste se relit en diff.

La source de la selection est publique : bad-asn-list (github.com/bountyyfi/bad-asn-list), qui nomme les reseaux et leur categorie. Le fichier n'est pas recopie : seuls les numeros d'ASN servent, et les prefixes sont regeneres depuis les donnees de routage. Un ASN peut disparaitre de la liste sans que nos fichiers changent de nature.

La limite est celle de toute reputation de reseau, et l'exemple de Yandex la resume : un groupe peut annoncer un ASN pour son moteur de recherche et un autre pour son cloud. Le premier est un robot legitime, le second heberge des scanners. Traiter « Yandex » comme une entite unique ferait bloquer l'indexation ; traiter l'ASN du cloud comme un indice faible deplace le probleme sans punir les visiteurs. C'est le choix retenu : Yandex.Cloud a quinze points, Yandex Search n'est pas dans la liste.

Ce qui manque encore : une source fraiche. Regenerees a la main, ces listes vieillissent. Un collecteur qui relit les prefixes annonces chaque semaine, et qui signe le resultat, est la prochaine etape.

Le mecanisme d'ingestion¶

Le chemin chaud ne fait aucun appel reseau. La mise a jour se fait a cote.

listes  ──►  collecteur (hors chemin critique)  ──►  magasin en memoire
                     │                                   │
                     └── rafraichissement, licences       └── consultation O(log n)
                                                              par le moteur de scoring

Deux sources possibles, et il faut choisir consciemment :

• Le flux de decisions de CrowdSec (/v1/decisions/stream) : on s'abonne et on recoit des decisions avec leur duree de vie, ce qui evite de reinventer la gestion d'expiration. En echange, on depend d'un composant de plus, et on accepte ses conditions d'usage.
• Le telechargement direct des fichiers : plus simple, mais il faut gerer soi-meme le rafraichissement, les listes qui disparaissent, et les licences.

Pour un premier jet, le telechargement direct de deux ou trois listes bien choisies suffit, et evite d'installer un moteur complet pour une fonction qui tient en un fichier recharge periodiquement.

Ce qui est vraiment vendable¶

Les listes sont un produit de base : tout le monde y a acces, y compris les attaquants, qui savent s'en retirer. Elles n'apportent pas de differenciation, et elles apportent encore moins de defensibilite a un produit en marque blanche.

Ce qui est defendable, c'est ce que le bord voit et que personne d'autre ne voit : le comportement agrege de vos clients. Une adresse qui a resolu trois challenges en dix minutes chez un client et qui se presente chez un autre dans la minute est un signal qu'aucune liste publique ne peut fournir. C'est le seul actif qui s'ameliore avec le nombre de clients, et c'est donc le seul qui merite d'etre construit en priorite.

Concretement, l'ordre de construction que je recommande :

1. Deux listes CVE et scanners, en drop, avec duree de vie courte. Effet immediat, risque de faux positif quasi nul, licence a verifier puis archiver.
2. Les proxys ouverts en captcha, avec un magasin en memoire et un parcours par prefixe. C'est la que se trouve le volume, donc c'est la que le cout d'implementation se justifie.
3. La telemetrie inter-organisations : compteurs partages, adresses vues sur plusieurs clients, resolution de challenge anormalement rapide ou repetee. C'est le debut d'un vrai produit, et cela ne depend de la licence de personne.

Les listes SSH, VoIP et cybercrime peuvent rester dans la console sans etre branchees : les afficher dans une offre alors qu'elles ne filtrent rien d'utile serait de la decoration.

Ce qui reste a verifier¶

• Les conditions d'usage exactes des listes CrowdSec pour une offre revendue.
• La licence de chaque source FireHOL retenue, fichier par fichier.
• Le cout memoire reel d'un magasin de trois millions de plages sur un noeud de bord, mesure et non estime.
• Le taux de faux positifs des listes de proxys sur notre propre trafic : c'est le chiffre qui decide si elles restent en captcha ou descendent en simple indice.

References¶

• Liste des noeuds de sortie Tor : https://check.torproject.org/torbulkexitlist
• FireHOL IP lists et tailles : http://iplists.firehol.org/
• Avertissement de licence de l'agregateur : https://github.com/firehol/blocklist-ipsets
• Blocklists CrowdSec, fonctionnement et abonnement : https://docs.crowdsec.net/u/getting_started/post_installation/console_blocklists