Sur cette page
À retenir
- Le risque est avant le serveurLe trafic peut être détourné avant d’atteindre l’infrastructure.
- DDoS et hijack se combinentUn attaquant peut exploiter le routage pour contourner ou amplifier l’impact.
- La prévention est mesurableRPKI, monitoring BGP et procédures de retrait réduisent le risque.
Définition du problème
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.
Pourquoi c’est important
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.
Les solutions possibles
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.
- Hygiène BGP
- IRR, AS-SET, prefix-limits et filtres évitent beaucoup d’erreurs.
- RPKI/ROA
- Réduit les annonces invalides quand la validation est appliquée.
- Monitoring externe
- 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 |
Cas concret ou exemple d’usage
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.
Erreurs fréquentes
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.
- Créer un ROA avec une longueur maximale trop large ou incohérente.
- Oublier de maintenir les objets IRR et AS-SET après un changement de client.
- Ne pas configurer de prefix-limit sur les sessions BGP.
- Surveiller uniquement les serveurs et pas la visibilité route globale.
- Attendre l’incident pour chercher qui contacter chez le transitaire.
FAQ
Un route hijack est-il forcément malveillant ?
Non. Beaucoup d’incidents viennent d’erreurs de configuration ou de route leaks.
RPKI empêche-t-il tous les hijacks ?
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.
Quel lien avec le DDoS ?
Un hijack peut contourner la mitigation ou créer une panne qui ressemble à une attaque.
Que surveiller en priorité ?
Origine du préfixe, more-specifics, visibilité depuis plusieurs collecteurs et chute anormale du trafic sur le chemin protégé.
