18 octobre 2026
·
8 min de lecture
Saisissez votre numéro d'AS et vérifiez si vos préfixes peuvent être redirigés vers un scrubbing center pendant une attaque DDoS, ce qui ne va pas dans votre AS-SET et qui d'autre a inscrit votre AS dans le sien. Corrections pas à pas pour les cinq RIR, dix langues, sans compte.
Nous publions un outil gratuit qui indique à un opérateur de réseau ou à un centre de données, à partir de son seul numéro d’AS, si ses préfixes sont prêts à être redirigés vers un scrubbing center pendant une attaque DDoS, et qui le guide dans chaque correction auprès de son registre. Il vérifie aussi l’hygiène de l’AS-SET que vos opérateurs de transit utilisent pour filtrer vos routes. Il fonctionne en dix langues et son code est ouvert.
Ouvrir le test de préparation au scrubbing center · Code source sur GitHub
Nous rentrons de PLNOG 2026 à Cracovie (15–16 octobre). Après notre présentation, nous avons ajouté plusieurs contrôles à l’outil, inspirés d’interventions données lors d’autres NOG que nous avons regardées pendant la conférence. Merci à leurs auteurs : grâce à eux, ces connaissances sont publiques. Toutes les sources sont listées à la fin de cet article, avec le lien vers la présentation et le nom de l’auteur.
Un problème qui n’apparaît qu’en pleine attaque
Quand une attaque dépasse la capacité de vos liens, le trafic est redirigé vers un scrubbing center : des préfixes /24 (en IPv6, /48) découpés dans vos blocs plus larges y sont annoncés, le trafic est nettoyé puis renvoyé vers votre réseau. Pour que cela fonctionne, les registres doivent être prêts à l’avance. Le ROA doit autoriser ces /24, un objet route doit exister dans la base du RIR, l’AS-SET doit contenir les bons réseaux et, si l’espace d’adressage appartient à quelqu’un d’autre, le scrubbing center demandera une LOA.
L’erreur la plus fréquente : un ROA créé exactement sur l’agrégat, sans maxLength. Tout fonctionne tant que seul l’agrégat est annoncé. Pendant une attaque, chaque /24 qui en est extrait devient RPKI-invalid et les réseaux qui valident RPKI le rejettent. La correction prend quelques minutes, mais elle met des heures, parfois deux jours, à atteindre les filtres. Le RFC 9319 le dit clairement : le ROA destiné à un service de mitigation DDoS doit exister avant l’attaque.
Ce qu’il faut vérifier, et ce qu’il faut corriger
| Ce que vérifie le test | Ce que vous obtenez pour corriger | |
|---|---|---|
| 🛡️ | ROA — chaque /24 (/48) extrait de vos blocs sera-t-il RPKI-valid ? | des ROA prêts à coller : un par /24 (RFC 9319) ou un maxLength sur l’agrégat |
| 📒 | Objets route — sont-ils dans une base de RIR, et pas seulement dans RADB ou un autre registre que les opérateurs n’acceptent pas ? Reste-t-il d’anciens objets avec une autre origine ? | des objets route prêts en RPSL ; les objets à supprimer |
| 📝 | LOA — l’espace d’adressage appartient-il à une autre organisation, ou s’agit-il d’espace PA fourni par un LIR ? | un modèle de LOA avec la liste des préfixes et de leurs titulaires |
| 🧹 | Hygiène de l’AS-SET — combien d’AS votre ensemble inclut-il réellement ? Des listes de membres d’IXP ou de pairs s’y cachent-elles ? Des membres partis ? | ce qu’il faut élaguer, et la règle simple : le réannonceriez-vous en BGP ? |
| 🕵️ | Qui inclut votre AS — quels réseaux sans relation BGP avec vous ont inscrit votre AS dans leurs AS-SET ? | la liste des ensembles à examiner, à qui demander le retrait, ASPA et surveillance |
| 🔗 | ASPA, contact abuse, PeeringDB, opérateurs de transit — y compris l’AS du scrubbing center, si vous le saisissez | l’endroit exact où configurer chacun d’eux dans votre registre |
| 📏 | Longueur des préfixes — y a-t-il des préfixes plus longs que /24 ou /48 qui seront filtrés ? | les préfixes à remplacer |
| 🧾 | Ce qui ne peut pas être vérifié de l’extérieur — rédaction de la LOA, tunnel et MSS, temps de propagation, annonce et retrait, boucles de routage, filtrage côté clients, test à blanc | une liste de contrôle à parcourir avec votre scrubbing center |
Tout se termine par un verdict — ✅ prêt, ⚠️ prêt avec réserves, ❌ pas prêt — et un 🔧 plan d’action dans l’ordre conseillé, avec les instructions pour votre registre.
Votre AS-SET est un objet de sécurité, pas de la documentation
Vos opérateurs de transit, comme les scrubbing centers, construisent le filtre des routes qu’ils acceptent de vous à partir de votre AS-SET. Les ROA RPKI ne valident que l’AS d’origine ; la partie transit du chemin est protégée par ces filtres issus des registres. L’AS-SET est donc un objet de sécurité. L’outil l’examine sous trois angles.
La taille. Si votre AS-SET s’étend à des milliers de réseaux, une fuite de routes de l’un de vos clients passe le filtre de votre opérateur de transit. Nous comparons l’ensemble déployé aux clients réellement visibles en BGP et signalons les ensembles beaucoup plus grands, profondément imbriqués ou dominés par un seul ensemble membre.
Le contenu. Un ensemble utilisé pour le filtrage doit lister votre cône de clients, et rien d’autre. Les listes de membres d’IXP et les listes de pairs le font exploser. La règle est simple : le réannonceriez-vous en BGP ? Si non, cela n’a rien à faire dans votre AS-SET. L’outil liste aussi les membres qui ne sont plus visibles comme vos clients.
Qui vous inclut. N’importe qui peut ajouter votre AS à son AS-SET. Avec une origine usurpée, l’annonce est valide au regard du ROA et passe les filtres de transit issus des registres. L’outil liste tous les AS-SET qui contiennent votre AS, signale ceux des réseaux sans relation BGP avec vous et indique quoi faire : demander le retrait, publier un ASPA et surveiller les registres.
Cinq registres, dix langues
Les étapes diffèrent d’un registre à l’autre, et l’outil en tient compte. Chez APNIC, un seul formulaire crée le ROA et l’objet route ; chez LACNIC, les objets route sont générés à partir des ROA, donc un objet route /24 exige un ROA par /24 ; chez ARIN, l’IRR n’a pas d’objets maintainer et l’accès suit les contacts de votre organisation. Les instructions couvrent RIPE NCC, ARIN, APNIC, AFRINIC et LACNIC, chacune avec un lien vers la documentation du registre.
L’interface fonctionne en polonais, anglais, allemand, français, espagnol, portugais, italien, néerlandais, tchèque et roumain, en thème clair et sombre.
Exécutez-le sur votre propre ordinateur
L’outil tourne dans le navigateur et n’a pas de serveur : le navigateur interroge directement des services publics — la base RIPE, RIPEstat, les registres des RIR (RDAP), IRR Explorer et PeeringDB. Vous pouvez aussi le télécharger et l’exécuter localement : start.bat sous Windows, start.sh sous Linux et macOS, ou Docker. Avec bgpq4 installé (il est déjà dans l’image Docker), la version locale ajoute des listes de préfixes construites à partir de vos AS-SET : nombre de préfixes, une prefix-list Junos et la liste complète dans un fichier.
Le code est publié sous licence AGPL-3.0, le contenu sous CC BY-SA 4.0. Les instructions de téléchargement et d’exécution se trouvent dans le README (en anglais).
Sur quoi reposent les tests
Chaque contrôle suit une source publiée : les RFC de l’IETF (6811, 9319, 9582, 7454, 6483, 2622 et les drafts ASPA), les documents du RIPE NCC et la documentation des cinq RIR, MANRS, ainsi que les exigences publiques d’intégration de scrubbing centers connus. Les contrôles d’AS-SET s’appuient sur les présentations de Lasse Jarlskov (Telia Company) — « Securing your AS-set » à BalticNOG 2025 et « Prelude to a BGP hijack? » à DKNOG15 — et sur « The Scourge of Excessive AS-SETs » de Doug Madory et Job Snijders. La liste complète, avec les auteurs et les liens, figure dans la section des sources du README.
Quand nous appeler
L’outil montre ce qu’il faut corriger dans les registres. La redirection n’est qu’une partie de la protection : l’attaque doit d’abord être détectée en quelques secondes et filtrée en bordure de votre propre réseau, et le passage au scrubbing center exige une procédure convenue à l’avance. Si vous souhaitez la préparer avec nous avant la première attaque, contactez-nous.
