
Une attaque par déni de service distribué (DDoS) consiste à saturer un service à l’aide d’un trafic massif et réparti, provoquant ainsi son « plantage » et empêchant l’accès des utilisateurs légitimes. Imaginez des milliers de voitures bloquant une autoroute : non parce qu’elles sont en panne, mais parce que la circulation est totalement paralysée.
Ce déluge de trafic provient généralement d’un « botnet » — un vaste ensemble d’ordinateurs ou d’appareils IoT infectés par des malwares et contrôlés à distance pour lancer des requêtes coordonnées. Les cibles typiques incluent les sites d’échange, les API de données de marché ou de trading, les nœuds RPC blockchain, ainsi que les connexions peer-to-peer (P2P) entre validateurs.
La différence essentielle réside dans l’échelle et la répartition : une attaque DDoS provient de multiples sources simultanées, tandis qu’une attaque DoS classique émane généralement d’une seule origine. Les attaques DDoS sont beaucoup plus difficiles à bloquer et à retracer, car le trafic malveillant est diffusé mondialement, à l’image de dizaines de robinets ouverts en même temps.
Pour les défenseurs, une attaque DoS peut parfois être contenue en bloquant une seule adresse IP. À l’inverse, faire face à une attaque DDoS requiert un filtrage en amont et une redirection du trafic dès l’entrée du réseau, associés à des limitations de débit applicatives et des stratégies de dégradation contrôlée.
Les attaques DDoS se classent généralement en deux grandes catégories :
Floods réseau : ces attaques saturent la bande passante et les ressources de connexion via l’envoi massif de paquets. Exemples : SYN floods ou UDP floods, qui génèrent d’énormes volumes de paquets sans logique métier. On retrouve aussi l’« amplification par réflexion », où les attaquants usurpent l’adresse IP de la victime et interrogent plusieurs services ouverts (DNS, NTP, etc.), lesquels renvoient alors un trafic amplifié vers la cible — comme si l’on utilisait un mégaphone pour crier sur la victime.
Épuisement applicatif : ces attaques simulent des utilisateurs légitimes effectuant des requêtes complexes pour saturer le CPU ou les connexions aux bases de données. Exemples : HTTP floods ou abus de WebSocket. Dans le Web3, les endpoints d’abonnement aux données de marché ou de passage d’ordres sont souvent des cibles de choix. Lorsque le trafic d’attaque imite fidèlement le comportement des utilisateurs, il contourne les filtres réseau et épuise directement les threads applicatifs, le cache et les pools de connexions base de données.
Dans l’écosystème Web3, les attaques DDoS visent fréquemment les points d’entrée critiques comme les sites d’échange et les API de trading ou de données de marché, les nœuds RPC blockchain, les ports P2P des nœuds complets, les cross-chain bridges et les block explorers.
Par exemple, sur une plateforme d’échange comme Gate, des attaques DDoS sur les API spot et dérivés peuvent provoquer des latences de chargement, des interruptions des flux de chandeliers et carnets d’ordres, des délais ou des échecs lors de la passation/annulation d’ordres, ainsi qu’un durcissement des limites de taux et une augmentation des codes d’erreur pour les utilisateurs API. Au niveau RPC, les attaques sur les nœuds publics peuvent entraîner des délais sur les requêtes de blocs/comptes, des échecs de rafraîchissement de solde de portefeuille et des appels de smart contracts ralentis.
Pour les nœuds validateurs, un excès de sondes P2P peut perturber la propagation des blocs et compromettre la production et la stabilité de la synchronisation. Si des bridges cross-chain exposent des interfaces publiques, les services de signature ou de preuve off-chain peuvent devenir inaccessibles en cas d’attaque.
Un signe caractéristique est une « dégradation soudaine des performances sans évolution des métriques métier » : hausse de la latence, augmentation des timeouts et erreurs 5xx, pics de trafic sans progression des conversions ou des transactions.
Côté réseau, on constate une utilisation anormale de la bande passante aux points d’entrée, une saturation des files SYN et une diversification géographique rapide des IP sources. Côté applicatif, surveillez les QPS (requêtes par seconde) inégaux, la hausse de la latence p95, l’épuisement des pools de connexions base de données, la baisse du taux de cache hit et les pics soudains de sessions WebSocket.
Dans les logs, les signatures typiques sont : chaînes User-Agent répétitives ou malformées, vagues de requêtes sans Referrer, une même IP sollicitant de nombreuses URLs en peu de temps, ou ciblage direct des endpoints dynamiques au lieu des ressources statiques. Pour les services de nœuds et RPC, on observe souvent des appels de contrats homogènes ou des requêtes à haute fréquence et faible valeur.
Déclencher le filtrage en amont et la limitation de débit : si nécessaire, isolez temporairement (« blackhole ») les IP de destination les plus ciblées ou redirigez-les via des centres de nettoyage pour protéger les bases de données et moteurs de matching centraux contre la saturation.
Activer la dégradation fonctionnelle et les modes lecture seule : privilégiez les moteurs de matching et la sécurité des actifs tout en réduisant les fonctions non essentielles — par exemple, chargement différé des graphiques, suspension des APIs batch non critiques ou réduction de la période d’historique des chandeliers.
Basculer rapidement vers Anycast ou des domaines de secours : Anycast permet de déployer une même IP sur plusieurs sites mondiaux, connectant les utilisateurs au nœud le plus proche et répartissant naturellement le trafic. Les domaines de secours isolent les points d’entrée fortement ciblés.
Renforcer les challenges applicatifs et l’authentification : ajoutez des CAPTCHAs sur les endpoints anonymes ; appliquez des limitations de débit granulaires par token bucket et des contrôles de pics sur les clés API ; imposez des vérifications de signature ou des caches pré-initialisés pour les requêtes coûteuses.
Coordonner avec les FAI et les prestataires de sécurité : ajustez dynamiquement les seuils et schémas de filtrage tout en assurant une bonne observabilité — veillez à ce que les métriques, logs et alertes clés restent opérationnels.
Publier des mises à jour de statut et des alertes de risque pour les utilisateurs : par exemple, la page de statut de Gate peut informer sur l’étendue de l’impact et les délais de rétablissement prévus. Recommandez aux utilisateurs de définir des paramètres de protection de prix et de risque lors des ordres pour éviter les erreurs en période d’instabilité réseau.
Une défense pérenne nécessite une approche intégrée — combinant « déviation, absorption, filtrage, dégradation » du trafic. Au niveau réseau, mettez en place de la redondance haut débit et des centres de nettoyage aux points d’entrée. Associez Anycast à des Content Delivery Networks (CDN) pour absorber les pics de trafic au plus près des utilisateurs ; fermez les ports de réflexion inutiles ou appliquez des contrôles d’accès sur les services amplifiables.
Côté applicatif, déployez une mise en cache multi-niveaux et la séparation lecture/écriture ; statisez ou pré-calculez les endpoints à fort trafic ; utilisez des Web Application Firewalls (WAF) pour détecter les comportements anormaux ; limitez les APIs par token bucket avec des paliers QPS par utilisateur et des contrôles de burst ; proposez des passerelles privées, du whitelisting et des quotas par source pour les endpoints RPC.
D’un point de vue ingénierie et organisation : organisez des exercices et formalisez des playbooks de réponse pour définir qui active quels contrôles selon la situation ; concentrez la surveillance sur les SLO critiques (Service Level Objectives) comme la disponibilité, la latence p95 et les taux d’erreur ; évaluez les bénéfices marginaux des réserves de bande passante, des services de nettoyage et de la redondance de calcul selon les pics d’activité et l’exposition au risque.
Les attaques DDoS ne dérobent pas directement les actifs mais déstabilisent le trading et les requêtes — amplifiant la slippage, générant des erreurs opérationnelles et augmentant les risques de latence. Pour les développeurs, il est crucial de concevoir des défenses multicouches et de mettre en place des procédures d’urgence efficaces couvrant le réseau et l’applicatif. Pour les utilisateurs : en cas d’accès anormal, consultez les pages de statut officielles, privilégiez les portails de confiance comme Gate, utilisez des paramètres de limitation/risque lors des transactions et évitez les opérations importantes ou à fort effet de levier pendant les perturbations. Les rapports du secteur montrent que les attaques DDoS à fort volume et au niveau applicatif continuent d’augmenter en 2024 — avec des pics atteignant le niveau Tbps (sources : rapports annuels et trimestriels Cloudflare, Akamai). Une préparation et des exercices proactifs sont presque toujours plus rentables qu’une récupération post-incident.
Le qualificatif « distribué » désigne des attaques lancées depuis des milliers d’appareils compromis, et non depuis un seul. Le trafic d’un ordinateur isolé est limité et facile à bloquer par les firewalls. Mais lorsque le trafic malveillant est réparti mondialement sur de nombreux appareils, il devient impossible pour les défenseurs de bloquer une simple adresse IP. Cette répartition accroît considérablement la réussite et la discrétion de l’attaque.
Un portefeuille ou un compte n’est généralement pas compromis lors d’une attaque DDoS (les fonds ne sont donc pas volés directement), mais les plateformes d’échange ou de wallet peuvent devenir inaccessibles, empêchant toute opération de trading ou de retrait. De fortes latences réseau durant une attaque peuvent entraîner du slippage ou des transactions échouées. Parfois, les attaquants profitent de cette fenêtre pour d’autres actions malveillantes. Il est conseillé de privilégier des plateformes bien protégées (comme Gate) et d’activer l’authentification à deux facteurs.
La durée d’une attaque DDoS varie de quelques minutes à plusieurs heures, voire plusieurs jours — selon les objectifs des attaquants et la réactivité des défenseurs. Les attaques de taille moyenne sont souvent atténuées en 30 minutes à 2 heures ; les plus importantes peuvent nécessiter plusieurs heures pour un retour à la normale. Une protection CDN professionnelle et des équipes de réponse spécialisées réduisent nettement les temps d’indisponibilité.
Les hackers peuvent avoir plusieurs motivations pour lancer des attaques DDoS : extorsion (demande de rançon), sabotage par des concurrents, objectifs politiques ou simple amusement. Dans le secteur crypto, les attaquants cherchent parfois à empêcher la mise en ligne d’une plateforme ou à exploiter une indisponibilité pour d’autres activités criminelles. Comprendre ces motivations permet d’adapter plus efficacement les stratégies de défense.
Les attaques DDoS visent principalement les plateformes, mais il existe des mesures de précaution : optez pour des plateformes dotées d’une infrastructure de protection solide (comme Gate), évitez les transactions importantes en période d’instabilité, activez l’authentification multi-facteur, surveillez régulièrement vos comptes pour détecter toute activité suspecte — et diversifiez vos actifs sur plusieurs plateformes afin de limiter le risque global.


