Comment lancer un DDoS à 65 Gbit / s et comment en arrêter un – Resoudre les problemes d’un serveur MineCraft
Hier, j'ai publié un post mortem sur une panne que nous avons eue samedi. La panne a été provoquée lorsque nous avons appliqué une limite de taux trop agressive au trafic sur notre réseau tout en luttant contre un attaquant DDoS déterminé. En train de l'écrire, j'ai mentionné que nous avions vu un DDoS à 65 Gbit / s plus tôt samedi. J'ai reçu plusieurs questions depuis que tout va quelque chose comme: "DDoS 65Gbps!? Qui lance une telle attaque et comment vous défendre contre elle?!" J'ai donc pensé donner un peu plus de détails.
Sommaire
Qu'est-ce qui constitue un gros DDoS?
Un DDoS à 65 Gbps est une grosse attaque, facilement dans le top 5% des plus grosses attaques que nous voyons. Le graphique ci-dessous montre le volume de l'attaque frappant nos centres de données de l'UE (la ligne verte représente le trafic entrant). Lorsqu'une attaque est à 65 Gbit / s, cela signifie que chaque seconde, 65 gigabits de données sont envoyés à notre réseau. C'est le volume de données équivalent à regarder 3 400 chaînes de télévision HD en même temps. C'est une tonne de données. La plupart des connexions réseau sont mesurées en 100 Mbit / s, 1 Gbit / s ou 10 Gbit / s, de sorte que des attaques comme celle-ci satureraient rapidement même une grande connexion Internet.
Chez CloudFlare, une attaque doit dépasser les 5 Gbit / s pour déclencher des alarmes avec notre équipe d'opérations. Même dans ce cas, nos défenses de réseau automatisées arrêtent généralement les attaques sans intervention manuelle. Lorsqu'une attaque se lève dans les dizaines de gigabits de données par seconde, notre équipe d'opérations commence à surveiller l'attaque: appliquer des filtres et déplacer le trafic pour s'assurer que le site du client attaqué reste en ligne et qu'aucun autre reste de notre réseau n'est affecté.
Vous voulez donc lancer un DDoS
Alors, comment un attaquant génère-t-il 65 Gbps de trafic? Il est très peu probable que l'attaquant dispose d'une seule machine avec une connexion Internet suffisamment grande pour générer à elle seule autant de trafic. Une façon de générer autant de trafic est via un botnet. Un botnet est une collection de PC qui ont été compromis par un virus et peuvent être contrôlés par ce qu'on appelle un éleveur de botnet.
Les éleveurs de botnets louent souvent l'accès à leurs botnets, facturant souvent par incréments de 15 minutes (tout comme les avocats). Les prix de location dépendent de la taille des botnets. Traditionnellement, les spammeurs d'e-mails achetaient du temps sur des botnets afin d'envoyer leurs messages semblant provenir d'un grand nombre de sources. Comme le spam par courrier électronique est devenu moins rentable avec la montée de meilleurs filtres anti-spam, les éleveurs de botnet se sont de plus en plus tournés vers la location de leurs réseaux de machines compromises à des attaquants souhaitant lancer une attaque DDoS.
Pour lancer une attaque à 65 Gbit / s, vous auriez besoin d'un botnet avec au moins 65 000 machines compromises chacune capable d'envoyer 1 Mbit / s de données en amont. Étant donné que bon nombre de ces ordinateurs compromis se trouvent dans le monde en développement où les connexions sont plus lentes, et bon nombre des machines qui font partie d'un botnet peuvent ne pas être en ligne à un moment donné, la taille réelle du botnet nécessaire pour lancer cette attaque serait doivent probablement avoir au moins 10 fois cette taille. Bien que jamais inconnu, c'est un grand botnet
et en utilisant toutes ses ressources pour lancer un DDoS, les FAI risquent de détecter de nombreuses machines compromises et de les mettre hors ligne.
Amplifier les attaques
Étant donné que la location d'un grand botnet peut être coûteuse et difficile à gérer, les attaquants recherchent généralement des moyens supplémentaires pour amplifier la taille de leurs attaques. L'attaque de samedi a utilisé une telle technique d'amplification appelée réflexion DNS. Pour comprendre leur fonctionnement, vous devez comprendre un peu le fonctionnement du DNS.
Lorsque vous vous inscrivez pour la première fois à une connexion Internet, votre FAI vous fournira un serveur DNS récursif, également appelé résolveur DNS. Lorsque vous cliquez sur un lien, votre ordinateur envoie une recherche au résolveur DNS de votre FAI. La recherche pose une question, comme: quelle est l'adresse IP du serveur pour cloudflare.com? Si le résolveur DNS que vous interrogez connaît la réponse, car quelqu'un l'a déjà posée récemment et que la réponse est mise en cache, il répond. Si ce n'est pas le cas, il transmet la demande au DNS faisant autorité pour le domaine.
En règle générale, les résolveurs DNS d'un FAI sont configurés pour répondre uniquement aux demandes des clients du FAI. Malheureusement, il existe un grand nombre de résolveurs DNS mal configurés qui accepteront les requêtes de n'importe qui sur Internet. Ceux-ci sont connus comme des «résolveurs ouverts» et ils sont une sorte de mine terrestre latente sur Internet qui ne demande qu'à exploser lorsqu'ils sont mal utilisés.
Les requêtes DNS sont généralement envoyées via le protocole UDP. UDP est un protocole de tir et d'oubli, ce qui signifie qu'il n'y a pas de poignée de main pour établir que d'où un paquet dit qu'il vient en fait est d'où il vient. Cela signifie que si vous êtes un attaquant, vous pouvez forger l'en-tête d'un paquet UDP pour dire qu'il provient d'une adresse IP particulière que vous souhaitez attaquer et envoyer ce paquet falsifié à un résolveur DNS ouvert. Le résolveur DNS répondra en répondant à l'adresse IP falsifiée en répondant à la question posée.
Pour amplifier une attaque, l'attaquant pose une question qui se traduira par une réponse très large. Par exemple, l'attaquant peut demander tous les enregistrements DNS pour une zone particulière. Ou ils peuvent demander les enregistrements DNSSEC qui, souvent, sont extrêmement volumineux. Étant donné que les résolveurs ont généralement des connexions à bande passante relativement élevées à Internet, ils n'ont aucun problème à pomper des tonnes d'octets. En d'autres termes, l'attaquant peut envoyer une demande UDP relativement petite et utiliser des résolveurs ouverts pour riposter sur une cible prévue avec une quantité de trafic paralysante.
Atténuation des attaques de réflexion DNS
L'une des grandes ironies lorsque nous traitons ces attaques est que nous recevons souvent un e-mail du propriétaire du réseau où un résolveur ouvert est en cours d'exécution nous demandant de mettre fin à l'attaque que notre réseau lance contre eux. Ils voient un grand nombre de paquets UDP avec l'une de nos adresses IP comme source arrivant sur leur réseau et supposent que nous sommes ceux qui le lancent. En fait, c'est en fait leur réseau qui est utilisé pour lancer une attaque contre nous. Ce qui est génial, c'est que nous pouvons répondre en toute sécurité et leur demander de bloquer toutes les demandes DNS provenant de notre réseau, car nos adresses IP ne doivent jamais envoyer de demande DNS à un résolveur. Non seulement cela résout leur problème, mais cela signifie qu'il existe un plus petit pool de résolveurs ouverts qui peuvent être utilisés pour cibler des sites sur
Réseau de CloudFlare.
Il y a eu un certain nombre d'efforts pour nettoyer les résolveurs ouverts qui sont actuellement actifs. Malheureusement, c'est lent et l'installation par défaut de nombreux clients DNS les a toujours ouverts par défaut. Alors que nous tendons la main activement aux pires contrevenants pour protéger notre réseau, pour protéger Internet en général, il faudra un effort concerté pour nettoyer les résolveurs DNS ouverts.
Pour arrêter ces attaques, CloudFlare utilise un certain nombre de techniques. Cela commence par notre architecture réseau. Nous utilisons Anycast, ce qui signifie que la réponse d'un résolveur, tout en ciblant une adresse IP particulière, atteindra le centre de données le plus proche. Cela dilue intrinsèquement l'impact d'une attaque, répartissant ses effets dans les 23 centres de données. Compte tenu des centaines de gigaoctets de capacité que nous avons sur notre réseau, même une grosse attaque sature rarement une connexion.
Dans chacune de nos installations, nous prenons des mesures supplémentaires pour nous protéger. Nous savons, par exemple, que nous n'avons envoyé aucune requête DNS depuis notre réseau. Nous pouvons donc filtrer en toute sécurité les réponses des résolveurs DNS: supprimer les paquets de réponses des résolveurs ouverts sur nos routeurs ou, dans certains cas, même en amont sur l'un de nos fournisseurs de bande passante. Le résultat est que ces types d'attaques sont relativement facilement atténués.
Ce qui était amusant à regarder, c'est que tandis que le client attaqué était ciblé par 65 Gbit / s de trafic, pas un seul paquet de cette attaque n'a atteint son réseau ou affecté ses opérations. En fait, CloudFlare a arrêté toute l'attaque sans que le client sache qu'il y avait un problème. Sur le graphique du réseau, vous pouvez voir après environ 30 minutes que l'attaquant a abandonné. Nous pensons que c'est plutôt cool et, comme nous continuons à étendre notre réseau, nous deviendrons encore plus résistants aux attaques comme celle-ci.
Commentaires
Laisser un commentaire