Un route hijack peut détourner, intercepter ou couper le trafic avant même qu’il n’arrive chez vous. Une stratégie DDoS doit inclure sécurité du routage, monitoring et procédures de retrait rapide.
Le trafic peut être détourné avant d’atteindre l’infrastructure.
Un attaquant peut exploiter le routage pour contourner ou amplifier l’impact.
RPKI, monitoring BGP et procédures de retrait réduisent le risque.
Le route hijacking est un incident où un réseau annonce, volontairement ou non, des routes qu’il ne devrait pas annoncer. Dans un contexte DDoS, le résultat peut être aussi destructeur qu’une attaque volumétrique : les utilisateurs n’arrivent plus au bon service, le trafic prend un mauvais chemin, ou une mitigation censée protéger devient contournée. Le sujet est souvent traité comme un problème de sécurité BGP séparé, alors qu’il doit faire partie du plan Anti-DDoS. Quand l’attaque ou l’erreur se produit au niveau du routage, les firewalls et serveurs applicatifs ne voient parfois même pas les paquets.
Un bon transit protégé doit cadrer BGP, AS-SET, RPKI, limites de préfixes et relivraison. La mitigation n’est utile que si le trafic arrive réellement au bon endroit.
Un hijack d’origine se produit lorsqu’un AS annonce un préfixe qui appartient à un autre réseau. Un hijack plus spécifique annonce un sous-préfixe, par exemple un /24 à l’intérieur d’un bloc plus large, et attire souvent plus de trafic. Une route leak n’est pas forcément malveillante : un réseau réannonce des routes à de mauvais voisins et crée des chemins inattendus.
Dans tous les cas, le problème est le même pour l’entreprise touchée : les paquets ne suivent plus le chemin prévu. Ils peuvent disparaître, passer par un réseau non autorisé, contourner une plateforme Anti-DDoS ou créer une latence extrême. Le support client voit une panne, mais l’origine se trouve dans le contrôle-plane BGP.
C’est critique parce que beaucoup de stratégies DDoS supposent que le trafic arrive bien au réseau de mitigation. Si un préfixe est détourné par une route plus spécifique, le trafic peut éviter entièrement le scrubbing center. Même sans attaquant sophistiqué, une mauvaise annonce d’un partenaire peut créer le même résultat.
Le risque commercial est élevé : indisponibilité partielle selon les pays, pertes de sessions, incohérence DNS apparente, dashboards DDoS qui ne montrent rien parce que le trafic ne passe plus par eux. Une équipe qui ne surveille que ses serveurs peut perdre de précieuses minutes avant de comprendre que le problème est BGP.
La première défense est l’hygiène de routage : objets IRR corrects, AS-SET maintenu, limites de préfixes chez les transitaires, filtres entrants et sortants, et documentation claire des préfixes autorisés.
La seconde défense est RPKI/ROA. Les ROA indiquent quels AS sont autorisés à annoncer un préfixe et avec quelle longueur maximale. Ils ne résolvent pas tout, mais ils réduisent fortement la surface des annonces invalides quand les réseaux appliquent la validation.
La troisième défense est la surveillance active : alertes sur changement d’origine, apparition d’un more-specific, baisse brutale du trafic sur le chemin protégé, changement de visibilité depuis plusieurs collecteurs. En incident, il faut aussi savoir retirer, corriger ou faire escalader une annonce rapidement.
IRR, AS-SET, prefix-limits et filtres évitent beaucoup d’erreurs.
Réduit les annonces invalides quand la validation est appliquée.
Détecte ce que vos serveurs ne peuvent pas voir.
| Risque | Symptôme | Défense |
|---|---|---|
| Origin hijack | Mauvais AS visible | ROA + alertes origine |
| More-specific | Trafic attiré ailleurs | Max-length prudent + monitoring |
| Route leak | Chemins inattendus | Filtres et AS-SET propre |
Peeryx intègre ce sujet dans la discussion transit protégé. Protéger un préfixe ne consiste pas seulement à avoir de la capacité DDoS ; il faut aussi vérifier que le préfixe est annoncé correctement, que les objets de routage existent et que le client sait quel AS doit être visible.
Dans un modèle avec BGP client, under-ASN ou AS-SET, les limites de préfixes et les informations IRR/RPKI doivent être propres avant l’activation. Cela évite les blocages chez les transitaires et limite les erreurs pendant une attaque.
Peeryx recommande également de surveiller la visibilité depuis l’extérieur. Si le trafic baisse brutalement côté scrubbing alors que les utilisateurs signalent une panne, le diagnostic ne doit pas rester bloqué sur le firewall : il faut vérifier le plan de routage.
Le design inclut préfixes, ASN, AS-SET, ROA et limites de route.
Les prérequis BGP sont vérifiés avant que le client dépende de la mitigation.
Le modèle prévoit escalade transitaire, retrait d’annonce et diagnostic externe.
Un hébergeur annonce son /24 via un réseau Anti-DDoS. Pendant une attaque, un autre AS annonce par erreur le même /24 ou un sous-préfixe plus spécifique. Une partie des utilisateurs n’arrive plus chez l’hébergeur, mais les graphs du scrubbing center ne montent pas. Sans monitoring BGP, l’équipe cherche du côté serveur alors que le trafic est ailleurs.
Avec des ROA corrects, des filtres chez les transitaires et des alertes sur changement d’origine, l’incident est détecté plus vite. L’équipe peut contacter le réseau fautif, demander filtrage, ajuster ses annonces ou activer un plan de secours. Le gain principal est le temps : comprendre en minutes au lieu d’heures.
Les erreurs fréquentes viennent d’une séparation artificielle entre sécurité BGP et protection DDoS. En production, l’utilisateur ne voit pas cette séparation : il voit seulement que le service ne répond plus.
Non. Beaucoup d’incidents viennent d’erreurs de configuration ou de route leaks.
Non. Il réduit les annonces invalides, mais dépend de la création correcte des ROA et de la validation par les réseaux.
Un hijack peut contourner la mitigation ou créer une panne qui ressemble à une attaque.
Origine du préfixe, more-specifics, visibilité depuis plusieurs collecteurs et chute anormale du trafic sur le chemin protégé.
Le route hijacking rappelle une vérité simple : avant de filtrer le trafic, il faut le recevoir. Une protection DDoS sérieuse doit donc inclure la sécurité du routage, la validation des annonces, le monitoring externe et des procédures d’escalade. Sinon, une erreur BGP peut provoquer la même indisponibilité qu’une attaque réussie.
Envoyez-nous vos préfixes, vos transitaires actuels, votre trafic moyen et vos contraintes de latence. On cadrera d’abord le modèle de relivraison propre avant de parler tarif.
