À des fins éducatives uniquement ; ne constitue ni un conseil en investissement ni une recommandation d’investissement. Les investissements peuvent entraîner des pertes.
Réponse directe
Une attaque par éclipse isole un nœud cible des pairs honnêtes en contrôlant toutes ses connexions réseau, ou un nombre suffisant d’entre elles. L’attaquant peut ensuite retarder, supprimer ou relayer sélectivement des blocs et des transactions, de sorte que la victime perçoive une vision du réseau façonnée par l’attaquant.
La victime peut continuer à valider les signatures, la preuve de travail et toutes les autres règles de consensus. Cela ne rend pas sa vision complète ni à jour. Un nœud qui effectue une validation complète peut rejeter les données non valides tout en étant maintenu sur une branche valide mais obsolète, empêché de voir une transaction contradictoire ou induit en erreur sur ce que le reste du réseau a accepté.
Cette attaque diffère d’une attaque majoritaire visant l’ensemble du réseau. L’attaquant cible un nœud ou un ensemble limité de nœuds au niveau pair à pair et n’a pas besoin de contrôler la majeure partie de la puissance de minage ou des participations du réseau. Une attaque Sybil peut faciliter une attaque par éclipse en fournissant de nombreuses identités ou adresses contrôlées par l’attaquant, mais ces notions ne sont pas identiques : Sybil décrit la multiplication des identités ; l’éclipse décrit l’isolement réussi de la vision informationnelle d’une victime.
Fonctionnement de l’isolement
Les clients pair à pair découvrent des adresses candidates, les stockent, sélectionnent des pairs sortants, acceptent certains pairs entrants et se reconnectent après une défaillance ou un redémarrage. Les algorithmes exacts varient selon le client et sa version. L’attaquant cherche un moyen d’orienter suffisamment de ces décisions vers l’infrastructure qu’il contrôle.
Un scénario d’attaque type comporte 4 étapes :
- Préparer des pairs contrôlés par l’attaquant. L’attaquant exploite des nœuds ou des identités accessibles à des adresses que les règles de sélection des pairs de la victime sont susceptibles de considérer comme distinctes.
- Influencer l’ensemble des candidats. Des pairs malveillants annoncent des adresses contrôlées par l’attaquant ou tentent par d’autres moyens d’évincer les entrées honnêtes du gestionnaire d’adresses de la victime. La faisabilité pratique dépend de la conception des compartiments, des règles de regroupement réseau, des limites de débit et de la qualité des adresses déjà stockées.
- Provoquer ou attendre une reconnexion. Un redémarrage, le renouvellement des connexions, un déni de service ou une perturbation du routage peuvent amener la cible à remplacer ses pairs honnêtes. L’isolement est plus facile lorsque la cible dispose de peu de chemins indépendants ou démarre avec une base d’adresses de mauvaise qualité.
- Monopoliser et filtrer. Une fois que les connexions pertinentes de la victime mènent à l’attaquant, celui-ci ne relaie que les blocs et les transactions choisis, tout en respectant souvent les règles de consensus afin d’éviter un rejet immédiat.
L’étude USENIX de 2015 a démontré cette catégorie d’attaque contre l’implémentation pair à pair de Bitcoin en vigueur à l’époque et décrit notamment des doubles dépenses fondées sur les confirmations, une aide au minage égoïste et des bifurcations adverses. Ses estimations précises des ressources nécessaires et les détails du client sont des données historiques, non des constantes universelles applicables à la version actuelle de Bitcoin Core ou à d’autres réseaux.
Les clients modernes peuvent augmenter le coût de l’isolement grâce au stockage aléatoire et segmenté des adresses, à la diversité des sources de pairs, aux connexions de test, aux connexions sortantes ou de relais de blocs protégées, aux ancrages conservés entre les redémarrages, aux règles d’éviction et aux limites de relais des adresses. Il s’agit de mesures d’atténuation à plusieurs niveaux, et non de preuves que les attaques par éclipse sont impossibles.
Exemple de paiement et réponse
Supposons que le nœud d’un commerçant reçoive un paiement et affiche 6 confirmations. Un attaquant qui a isolé ce nœud peut lui présenter une branche valide maintenue en privé et contenant le paiement, tandis qu’une transaction contradictoire est acceptée sur le réseau honnête. Si le commerçant livre des biens non récupérables en se fiant uniquement au nœud isolé, le nombre affiché ne prouve pas que le réseau honnête a confirmé le paiement.
La réponse à l’incident doit préserver les preuves avant toute modification perturbatrice :
- Consignez la pointe de chaîne signalée, le travail cumulé, les hachages des blocs récents, la liste des pairs, le sens des connexions, le type de réseau, le système autonome associé lorsqu’il est disponible et l’horodatage du dernier bloc reçu.
- Comparez la pointe et l’état de la transaction avec des nœuds exploités indépendamment, joints par des chemins réseau et administratifs réellement distincts. Les explorateurs publics ne sont utiles que si leur infrastructure est elle aussi indépendante.
- Suspendez le règlement de montants élevés ou la livraison automatisée lorsque les visions indépendantes divergent. Des confirmations supplémentaires issues de la même vision isolée ne résolvent pas le problème.
- Passez à des logiciels et à une configuration reconnus fiables, examinez le DNS, le routage, le pare-feu, le proxy et une éventuelle compromission de l’hôte, puis reconstruisez l’état des pairs selon la procédure de récupération documentée par le client.
- Reconnectez-vous progressivement et vérifiez que les pairs, les groupes réseau, l’arrivée des blocs, le travail de la chaîne et les observations des transactions se diversifient. Ne restaurez pas aveuglément une base de données de pairs potentiellement contaminée.
- Conservez les journaux et transmettez l’incident à l’équipe chargée de la sécurité du nœud ou du protocole. Une suspicion d’éclipse peut coïncider avec des pannes ordinaires, des incidents de routage ou une compromission plus large de l’hôte.
Dans Bitcoin Core 30.0, getpeerinfo expose des champs tels que network, mapped_as, inbound, last_block, synced_headers, synced_blocks et connection_type. Ces champs facilitent l’enquête, mais aucun ne prouve à lui seul l’isolement. La surveillance doit établir une référence normale et mettre en relation la concentration des pairs avec des observations indépendantes de la chaîne.
Risques et contrôles
- Double dépense aux dépens d’un destinataire : la victime peut voir des confirmations sur une branche contrôlée par l’attaquant. Exigez une observation indépendante pour les livraisons de grande valeur ou irréversibles et fixez des limites adaptées au risque de règlement.
- Perturbation des mineurs ou des validateurs : un opérateur isolé peut travailler à partir d’informations obsolètes, perdre des revenus ou favoriser une branche adverse. Surveillez le travail de la chaîne, la fraîcheur de la pointe et la diversité des pairs en dehors du nœud de production.
- Censure sélective : l’attaquant peut masquer des transactions ou retarder des blocs sans envoyer de données non valides. Déclenchez des alertes en cas d’intervalles inhabituels entre les blocs et de désaccord entre des observateurs indépendants.
- Défaillance d’un pont, d’un oracle ou d’un RPC : les services hors chaîne qui font confiance à un seul nœud en amont peuvent relayer un état obsolète ou manquer une réorganisation. Utilisez plusieurs sources de données administrées et mises en réseau indépendamment, avec des règles explicites de quorum et de fraîcheur.
- Fausse confiance inspirée par le nombre de connexions : 20 pairs contrôlés par une même organisation, un même réseau ou une même source d’adresses peuvent offrir moins d’indépendance qu’un ensemble diversifié plus petit. Mesurez la diversité, pas seulement la quantité.
- Centralisation par des pairs fixes : un unique pair de confiance configuré manuellement peut contourner un ensemble de candidats contaminé, mais crée un point de défaillance unique. Si des ancrages fixes sont appropriés, utilisez plusieurs chemins exploités indépendamment et conservez des connexions aléatoires.
Les opérateurs de nœuds doivent maintenir à jour les versions prises en charge du client, comprendre les paramètres par défaut de gestion des pairs propres au client, protéger l’accès administratif et surveiller la topologie entrante comme sortante. Les opérateurs de paiements et de protocoles doivent séparer la signature, la diffusion, l’observation de la chaîne et les décisions de livraison afin qu’un seul nœud isolé ne puisse pas autoriser à lui seul une action irréversible.
Idées reçues
- Un nœud complet ne peut pas être trompé. Un nœud complet rejette les données contraires au consensus ; il ne sait pas automatiquement que des pairs honnêtes lui cachent une meilleure chaîne valide.
- Un nombre élevé de confirmations est toujours suffisant. Les confirmations n’ont de sens que par rapport à la vision observée de la chaîne. L’indépendance du chemin d’observation compte lorsqu’un isolement est plausible.
- Ajouter des pairs résout toujours le problème. Les pairs supplémentaires ne sont utiles que si leurs propriétaires, leurs chemins réseau, leurs sources de découverte et leurs modes de défaillance sont suffisamment indépendants.
- Les attaques par éclipse et Sybil sont identiques. Les ressources Sybil peuvent faciliter l’isolement, mais une attaque par éclipse désigne la prise de contrôle qui en résulte sur la vision des pairs de la victime.
- Un explorateur de blocs concordant prouve que le nœud est sain. L’explorateur peut partager avec le système touché un fournisseur en amont, un chemin réseau ou un domaine administratif.
- Tout nœud obsolète est attaqué. Les défauts logiciels, la congestion, la maintenance, les erreurs de routage et l’épuisement des ressources peuvent produire des symptômes similaires. Considérez l’éclipse comme une hypothèse à vérifier au moyen de plusieurs signaux.
Sujets connexes
Sources
- Eclipse Attacks on Bitcoin’s Peer-to-Peer Network - USENIX Association (consulté : 2026-08-20)
- Bitcoin Core RPC: getpeerinfo - Bitcoin Core (consulté : 2026-08-20)
- Bitcoin Core: connection_types.cpp - Bitcoin Core (consulté : 2026-08-20)