Détournement BGP : comment un FAI peut protéger ses préfixes IP contre le hijacking

RPKI/ROV, filtrage de préfixes, protection du plan de contrôle et surveillance des annonces — une méthodologie d'audit complète pour les opérateurs réseau, à partir d'un détournement BGP réel.

24 octobre 2026 · Équipe SunuCyberSecurity · Niveau expert · Administrateurs réseau, opérateurs télécoms, FAI, ingénieurs BGP, responsables sécurité

Source : incident réel Softaculous/Virtualizor, 28-30 août 2026 — détail et sources en section 2

Le Border Gateway Protocol (BGP) est l'un des mécanismes fondamentaux du fonctionnement d'Internet. Il permet aux systèmes autonomes (AS) d'échanger des informations de routage et de déterminer comment atteindre les préfixes IP annoncés par les autres réseaux.

Mais cette fonction essentielle constitue également une surface d'attaque. Une annonce de route incorrecte ou malveillante peut détourner le trafic destiné à un réseau légitime, rendre un service inaccessible ou, dans certaines conditions, exposer des communications à une infrastructure contrôlée par un attaquant.

Fin août 2026, un détournement BGP réel a visé une plage d'adresses utilisée par l'infrastructure de Softaculous (hébergée chez Hetzner) et a servi, pendant la fenêtre de détournement, un paquet logiciel Virtualizor modifié à certaines installations qui vérifiaient une mise à jour. L'incident, documenté par Virtualizor et Softaculous eux-mêmes puis repris par plusieurs médias spécialisés en sécurité, illustre concrètement l'importance de RPKI, de la validation des origines de routes, du filtrage BGP et de la vérification cryptographique des mises à jour logicielles.

Pour les fournisseurs d'accès à Internet, cet incident rappelle une règle fondamentale : la sécurité du routage doit être assurée à la fois dans le plan de contrôle BGP, dans les politiques d'annonces et dans les systèmes qui consomment le trafic routé.

Cet article présente les principaux scénarios de détournement BGP, les mécanismes de défense à déployer et une méthodologie d'audit adaptée aux infrastructures des FAI.

1. Comprendre le BGP hijacking

Le BGP hijacking, ou détournement de routes BGP, désigne une situation dans laquelle un système autonome annonce des routes qui entraînent l'acheminement d'une partie du trafic vers un chemin non légitime.

Chaque préfixe IP est associé à une annonce de routage. Les routeurs BGP évaluent plusieurs attributs et politiques pour sélectionner le meilleur chemin. Contrairement à une idée répandue, BGP ne dispose pas, à lui seul, d'un mécanisme cryptographique universel permettant de prouver que chaque annonce est légitime.

Un incident peut notamment résulter de trois scénarios.

1.1. Annonce d'un préfixe plus spécifique

Un réseau légitime annonce par exemple 203.0.112.0/23. Un autre AS annonce un sous-préfixe tel que 203.0.112.0/24 sans autorisation.

Sur les routeurs qui acceptent cette annonce, la règle du plus long préfixe peut conduire le trafic destiné à cette plage plus spécifique vers le mauvais réseau, même si le chemin initial paraît préférable selon d'autres attributs BGP.

Le scénario exact dépend toutefois des politiques des opérateurs et de la propagation de l'annonce.

1.2. Annonce d'un préfixe existant avec un chemin trompeur

Un attaquant peut annoncer un préfixe légitime en présentant un chemin AS qui influence les décisions de routage. La route ne sera pas nécessairement acceptée partout : les politiques des fournisseurs, les filtres de préfixes, la validation RPKI et les autres attributs BGP influencent son traitement.

1.3. Fuite de routes (route leak)

Une fuite de routes survient lorsqu'un réseau propage des routes au-delà de la politique de routage prévue, par exemple en redistribuant vers un fournisseur des routes apprises auprès d'un autre fournisseur.

Une fuite peut être accidentelle ou malveillante. Elle peut provoquer une congestion, une redirection de trafic ou une interruption de connectivité, sans nécessairement résulter d'une intrusion informatique.

Il est donc important de distinguer le détournement malveillant, l'erreur de configuration et la fuite de routes. Les mesures de défense se recoupent, mais l'investigation et l'attribution ne sont pas identiques.

2. Pourquoi l'incident d'août 2026 est important

Entre le 28 août 2026 à 20h57 UTC et le 30 août à 6h10 UTC — environ 33 heures — un sous-préfixe 162.55.80.0/24, qui fait partie de l'espace d'adresses utilisé par les services de Softaculous chez Hetzner, a été annoncé par l'AS62390 (identifié par Softaculous comme NexonHost) via le transitaire AS6204. Cette annonce, plus spécifique que la route légitime 162.55.0.0/16, a détourné le trafic vers un serveur contrôlé par l'attaquant — qui avait obtenu un certificat Let's Encrypt valide pour la destination détournée, évitant ainsi tout avertissement de certificat côté client.

Pendant cette fenêtre, un paquet de mise à jour Virtualizor modifié a été servi à une partie des installations qui interrogeaient le service de mise à jour au même moment. Softaculous indique ne pas pouvoir établir de liste définitive des installations touchées. Un hébergeur ayant audité son propre parc a rapporté une compromission avec accès root confirmée sur 5 de ses 34 hyperviseurs vérifiés. Virtualizor a publié la version corrigée 3.2.9.9, incluant un nouvel outil d'analyse de sécurité, dès le 1er septembre, et recommande la rotation des identifiants API ainsi qu'un audit des serveurs pour toute installation ayant pu être exposée durant la fenêtre.

Cet exemple met en évidence une chaîne de risque :

1. Une annonce BGP incorrecte ou malveillante modifie le chemin du trafic.
2. Des requêtes légitimes atteignent une infrastructure non prévue.
3. Les mécanismes de confiance du système consommateur sont mis à l'épreuve.
4. Si la vérification cryptographique des paquets est insuffisante, un paquet altéré peut être accepté.
5. Une compromission logicielle peut alors survenir au-delà du routeur qui a subi ou propagé l'incident de routage.

Il faut toutefois éviter une conclusion excessive : un détournement BGP ne déchiffre pas automatiquement le trafic HTTPS et ne garantit pas qu'un paquet malveillant sera accepté. Le résultat dépend de la configuration TLS, de la validation des certificats, de la signature des paquets et des contrôles de sécurité de l'application.

Sources : Virtualizor — Security Incident · Softaculous — Security Incident · The Hacker News · BleepingComputer.

3. Les risques spécifiques pour un FAI

Pour un fournisseur d'accès à Internet, une anomalie BGP peut avoir des conséquences bien au-delà d'un seul serveur.

Indisponibilité de services

Une annonce incorrecte peut provoquer une perte de connectivité vers des services, des plateformes de paiement, des DNS, des systèmes d'authentification ou des applications hébergées à l'étranger.

Redirection du trafic

Un trafic détourné peut arriver sur un chemin imprévu. Selon le protocole et les contrôles de sécurité, cela peut entraîner des erreurs de connexion, une dégradation des performances ou une exposition accrue à des attaques intermédiaires.

Compromission de la chaîne d'approvisionnement

Les systèmes de gestion, les hyperviseurs, les plateformes de facturation ou les serveurs de mise à jour peuvent dépendre de services externes. Une modification du chemin réseau peut donc devenir un facteur de risque pour la chaîne d'approvisionnement logicielle.

Atteinte à la confiance des abonnés

Une panne ou une redirection affectant plusieurs destinations peut être interprétée par les abonnés comme une défaillance générale de l'accès Internet. L'opérateur doit pouvoir distinguer une panne locale, un problème de transit, un incident DNS et une anomalie de routage global.

4. RPKI et ROV : une défense essentielle contre les annonces illégitimes

La Resource Public Key Infrastructure (RPKI) permet aux détenteurs de ressources IP d'autoriser cryptographiquement des systèmes autonomes à annoncer certains préfixes. Ces autorisations sont publiées sous forme de ROA (Route Origin Authorizations).

La Route Origin Validation (ROV) permet ensuite à un réseau de comparer l'origine AS d'une route BGP aux autorisations RPKI disponibles.

Les résultats habituels sont :

• Valid : l'origine et la longueur du préfixe correspondent à une autorisation valide.
• Invalid : l'annonce contredit une autorisation, par exemple parce que l'origine AS n'est pas autorisée ou que le préfixe est plus spécifique que le maximum autorisé.
• NotFound : aucune autorisation RPKI correspondante n'est disponible.

Ce que RPKI/ROV protège — et ce qu'il ne protège pas

ROV permet de rejeter ou de déprioriser des annonces dont l'origine est invalide, selon la politique de l'opérateur. Il réduit donc une classe importante de détournements.

Cependant, ROV ne prouve pas que chaque chemin AS est légitime et ne détecte pas toutes les fuites de routes. Une annonce provenant d'un AS autorisé peut toujours être associée à un problème de politique ou à une compromission.

Il ne remplace donc pas les filtres de préfixes, les contrôles d'AS-path, la surveillance des routes et les procédures de réponse aux incidents.

Recommandations de mise en œuvre

Pour les préfixes détenus par l'opérateur :

1. Inventorier tous les préfixes IPv4 et IPv6 effectivement annoncés.
2. Créer ou vérifier les ROA correspondants auprès du registre Internet régional approprié.
3. Vérifier l'AS d'origine autorisé et la longueur maximale du préfixe.
4. Déployer des validateurs RPKI redondants.
5. Appliquer une politique ROV documentée aux routes reçues.
6. Surveiller les changements d'état des routes et les erreurs de validation.

Une ROA erronée peut rendre une annonce légitime invalide. Il est donc nécessaire de vérifier les autorisations avant d'appliquer une politique de rejet stricte en production.

5. Filtrage BGP : limiter les annonces aux routes attendues

Le filtrage des préfixes doit être appliqué aux sessions eBGP, en entrée et en sortie.

En sortie

Un FAI doit annoncer uniquement les préfixes qu'il est autorisé à annoncer. Les politiques de sortie doivent être explicites et adaptées à chaque voisin.

En entrée

La politique dépend de la relation avec le voisin :

• Transit complet : accepter les routes Internet attendues selon la politique convenue, tout en rejetant les préfixes interdits et les annonces manifestement incorrectes.
• Fournisseur de routes par défaut : n'accepter que la route par défaut si c'est bien le service convenu.
• Peer de peering : limiter les annonces aux préfixes attendus de ce pair.
• Client : appliquer les filtres de routes correspondant aux préfixes autorisés du client et aux politiques de propagation convenues.

Les filtres doivent être générés ou vérifiés à partir de sources fiables, puis testés. Une liste blanche mal construite peut interrompre le routage légitime ; un filtre trop permissif laisse passer des annonces indésirables.

Mesures complémentaires

• Appliquer des limites de nombre de préfixes cohérentes avec chaque session.
• Contrôler les chemins AS-path selon la relation commerciale et la politique de routage.
• Rejeter les préfixes spéciaux, non routables ou appartenant à l'espace propre de l'opérateur lorsqu'ils ne doivent pas être reçus par cette session.
• Contrôler les annonces de sous-préfixes non autorisés.
• Documenter les exceptions et leur durée de validité.

Le filtrage AS-path est utile, mais il ne constitue pas à lui seul une preuve cryptographique de légitimité : un chemin annoncé peut être trompeur ou manipulé.

6. Protéger les sessions BGP et le plan de contrôle

BGP utilise TCP, généralement sur le port 179. Les sessions doivent être établies uniquement avec les voisins prévus et à travers les interfaces de transport appropriées.

Les mesures de protection incluent :

• filtrer le trafic destiné au plan de contrôle ;
• autoriser les sessions BGP uniquement depuis les adresses des pairs attendus ;
• utiliser les mécanismes d'authentification de voisin disponibles et compatibles ;
• envisager GTSM/TTL Security lorsque cela convient à la topologie ;
• appliquer des politiques Control Plane Policing (CoPP) adaptées ;
• superviser les changements d'état des sessions et les réinitialisations inhabituelles ;
• protéger les accès d'administration par des réseaux de gestion dédiés.

L'authentification d'une session BGP contribue à protéger la connexion entre voisins, mais ne valide pas à elle seule la légitimité de chaque préfixe annoncé. Elle doit être associée aux politiques de routage et à la validation des origines.

7. Surveiller les annonces de routes en temps réel

Un FAI ne doit pas attendre les plaintes des abonnés pour détecter un détournement. Il doit surveiller les changements de préfixes, les chemins AS, les origines et les variations inhabituelles du routage.

Indicateurs à surveiller

• apparition d'un sous-préfixe inattendu ;
• changement soudain d'AS d'origine ;
• route devenue RPKI Invalid ;
• hausse inhabituelle des annonces ou retraits ;
• variation anormale du nombre de préfixes reçus d'un voisin ;
• réinitialisations répétées d'une session BGP ;
• modification du chemin vers des destinations critiques ;
• augmentation des pertes de paquets ou des erreurs de connexion vers plusieurs réseaux.

Les plateformes de surveillance de routage global et les flux de collecte BGP peuvent compléter les données locales du routeur. Les alertes doivent être corrélées avec les changements de configuration, les événements de maintenance et les incidents des fournisseurs de transit.

Distinguer un incident de routage d'un problème DNS ou applicatif

Une destination inaccessible n'implique pas nécessairement un détournement BGP.

L'investigation doit comparer :

1. la résolution DNS ;
2. les routes vers les adresses de destination ;
3. les chemins observés depuis plusieurs réseaux ;
4. les états RPKI ;
5. la connectivité TCP et TLS ;
6. les incidents signalés par les fournisseurs de transit.

Un changement d'annonce observé depuis plusieurs collecteurs, accompagné d'un sous-préfixe inattendu et d'une origine non autorisée, constitue un signal plus significatif qu'un simple échec de connexion.

8. Procédure de réponse à un détournement BGP suspecté

Phase 1 — Confirmer l'anomalie

• Identifier le préfixe touché et son origine attendue.
• Comparer les routes vues localement avec les observations de plusieurs collecteurs externes.
• Vérifier les ROA et le résultat RPKI.
• Examiner les changements de politique et les événements des voisins.
• Déterminer si l'incident est local, limité à un fournisseur ou visible à l'échelle d'Internet.

Phase 2 — Contenir l'incident

• Contacter le fournisseur de transit ou le pair concerné par les canaux d'incident convenus.
• Demander la validation ou le retrait d'une annonce non autorisée lorsque cela est justifié.
• Corriger les filtres ou politiques défectueux après validation.
• Éviter les annonces de sous-préfixes improvisées : elles peuvent aggraver l'incident ou être filtrées par d'autres réseaux.

Phase 3 — Évaluer les systèmes dépendants

Si des serveurs de mise à jour, des hyperviseurs, des systèmes de facturation ou des services d'administration ont pu être atteints via le chemin détourné :

• examiner les journaux et l'historique des mises à jour ;
• vérifier les signatures et sommes de contrôle publiées par l'éditeur via un canal de confiance ;
• rechercher les modifications de configuration ou les mécanismes de persistance ;
• révoquer ou renouveler les secrets potentiellement exposés ;
• isoler les systèmes suspectés d'être compromis selon le plan de réponse à incident.

Phase 4 — Restaurer et tirer les enseignements

• confirmer la stabilité des annonces légitimes ;
• vérifier le retour du trafic sur les chemins attendus ;
• documenter les causes et les décisions ;
• corriger les filtres et les procédures ;
• améliorer les alertes et effectuer un exercice de validation.

La restauration du routage ne signifie pas que les systèmes qui ont reçu du trafic détourné sont automatiquement sains.

9. Plan d'action recommandé pour un FAI

Ces délais sont des objectifs de mise en œuvre indicatifs. Les réseaux exposés à un incident en cours doivent traiter immédiatement les mesures pertinentes, sans attendre le calendrier proposé.

Conclusion

Le détournement BGP est un risque systémique : une anomalie dans le routage peut affecter des destinations, des fournisseurs de services et des chaînes de mise à jour logicielle qui semblent indépendants les uns des autres.

Pour les FAI, la défense repose sur plusieurs couches complémentaires : RPKI/ROV pour la validation de l'origine, filtrage strict des préfixes, protection des sessions BGP, contrôle du plan de contrôle et surveillance des annonces à l'échelle locale et mondiale.

L'incident Softaculous/Virtualizor d'août 2026 rappelle également qu'une sécurité réseau robuste ne suffit pas si les systèmes dépendants acceptent des mises à jour sans vérification cryptographique appropriée.

Un réseau résilient ne se contente pas d'acheminer les routes : il vérifie lesquelles il doit accepter, surveille leurs changements et dispose d'une procédure opérationnelle pour réagir rapidement.

Références

1. Virtualizor — Security Incident (avis officiel), 31 août 2026
   virtualizor.com/blog/security-incident-bgp-hijacking
2. Softaculous — Security Incident (avis officiel), août 2026
   softaculous.com/blog/security-incident-bgp-hijacking-update
3. The Hacker News — BGP Hijack Delivers Malicious Virtualizor Update That Establishes Persistent Root Access, septembre 2026
   thehackernews.com/2026/09/bgp-hijack-delivers-malicious.html
4. BleepingComputer — Hackers push malicious Virtualizor update in BGP hijacking attack
   bleepingcomputer.com/.../hackers-push-malicious-virtualizor-update-in-bgp-hijacking-attack
5. Cisco — Protecting Border Gateway Protocol for the Enterprise
   sec.cloudapps.cisco.com/security/center/resources/protecting_border_gateway_protocol
6. Internet Society — Continued Progress in African DNS Security, pour le contexte plus large de la résilience des infrastructures Internet africaines
   pulse-dev.internetsociety.org/.../continued-progress-in-african-dns-security

Note : les événements et indicateurs de l'incident d'août 2026 sont rapportés d'après les avis officiels de Virtualizor et Softaculous, recoupés avec la couverture de The Hacker News et BleepingComputer. Les recommandations générales BGP s'appuient sur la documentation Cisco et les bonnes pratiques de sécurisation du routage. Toute configuration appliquée en production doit être adaptée à la topologie et testée avant déploiement.

À lire aussi

Vérifiez votre propre exposition

Un scan gratuit, en quelques minutes, sans carte bancaire.