Comment Cloudflare a atténué automatiquement une attaque DDoS de 3,8 Tb/s, le nouveau record mondial

Depuis le début du mois de septembre, les systèmes de protection contre les attaques DDoS de Cloudflare ont lutté contre une campagne d'un mois d'attaques DDoS hypervolumétriques sur les couches 3 et 4. Tout au long du mois, les défenses de Cloudflare ont ainsi atténué plus d'une centaine de ces attaques, dont beaucoup ont dépassé les 2 milliards de paquets par seconde (Mds p/s) et les 3 térabits par seconde (Tb/s). L'attaque la plus volumineuse a culminé à 3,8 Tb/s, soit un chiffre qui en fait l'attaque la plus volumineuse jamais divulguée publiquement par une entreprise. La détection et l'atténuation se sont effectuées de manière parfaitement indépendante. Les graphiques ci-dessous représentent deux événements distincts d'attaques ciblant le même client Cloudflare et atténués de manière autonome.

Une attaque DDoS atténuée de 3,8 Tb/s et d'une durée de 65 secondes

Une attaque DDoS atténuée de 2,14 Mds p/s et d'une durée de 60 secondes

Les clients Cloudflare qui utilisent les services de proxy inverse HTTP de Cloudflare (p. ex. les solutions Cloudflare WAF et Cloudflare CDN) sont automatiquement protégés.

Les clients Cloudflare qui utilisent les services Spectrum et Magic Transit sont, eux aussi, automatiquement protégés. Les clients de Magic Transit peuvent optimiser encore leur protection en déployant des règles sur Magic Firewall afin d'appliquer un modèle strict regroupant sécurité positive et sécurité négative au niveau de la couche des paquets.

Ces attaques se révèlent sans précédent en termes d'ampleur et de fréquence. Du simple fait de leur taille et de leur débit en termes de bits/paquets par seconde, ces attaques sont capables de mettre hors service les propriétés Internet non protégées, mais aussi les propriétés Internet protégées par des équipements sur site ou par des fournisseurs de cloud qui ne disposent pas d'une capacité réseau ou d'une couverture mondiale suffisantes pour pouvoir traiter ces volumes en parallèle du trafic légitime, sans nuire aux performances.

Cloudflare dispose toutefois de la capacité réseau, de la couverture mondiale et des systèmes intelligents nécessaires pour absorber et atténuer automatiquement ces monstrueuses attaques. 

Dans cet article de blog, nous nous intéresserons plus en détail à la campagne d'attaques et aux raisons pour lesquelles ces dernières revêtent une gravité toute particulière. Nous décrivons l'anatomie d'une attaque DDoS contre les couches 3/4, ses objectifs et la manière dont les attaques sont générées. Nous nous attellerons ensuite aux détails de la manière dont les systèmes Cloudflare ont pu détecter et atténuer ces attaques monstrueuses de manière autonome, sans affecter les performances pour nos clients. Nous décrirons les aspects essentiels de nos défenses, en commençant par la manière dont nos systèmes génèrent des signatures (dynamiques) en temps réel afin de correspondre au trafic hostile jusqu'à la façon dont nous utilisons les fonctionnalités du noyau pour abandonner les paquets à la vitesse du réseau.

D'après nos observations, la campagne s'en est prise à plusieurs clients, notamment dans les secteurs des services financiers, d'Internet et des télécommunications. Cette campagne d'attaques visait la saturation de la bande passante, ainsi que l'épuisement des ressources des applications et des appareils installés en mode « in-line » (interne).

Les attaques se sont principalement appuyées sur le protocole UDP par l'intermédiaire d'un port fixe. Elles provenaient du monde entier, avec une proportion plus importante provenant du Vietnam, de la Russie, du Brésil, de l'Espagne et des États-Unis. 

Les attaques à haut débit de paquets semblent provenir de plusieurs types d'appareils compromis, notamment des appareils MikroTik, des enregistreurs numériques (DVR) et des serveurs web, orchestrés de manière à fonctionner ensemble et à inonder la cible sous des volumes de trafic exceptionnellement élevés. Les attaques à haut débit binaire semblent provenir d'un grand nombre de routeurs domestiques ASUS compromis, probablement exploités à l'aide d'une vulnérabilité CVE 9.8 (critique) récemment identifiée par Censys.

^{Part des paquets observés en fonction de l'emplacement de la source}

Avant de discuter de la manière dont Cloudflare a automatiquement détecté et atténué les attaques DDoS les plus volumineuses jamais observées, il est important de comprendre les principes de base qui sous-tendent ce type d'attaque.

Schéma simplifié d'une attaque DDoS

L'objectif d'une attaque par déni de service distribué (Distributed Denial of Service, DDoS) consiste à empêcher les utilisateurs légitimes d'accéder à un service. L'opération s'effectue généralement par l'épuisement des ressources nécessaires pour fournir le service. Dans le contexte de ces récentes attaques DDoS sur les couches 3 et 4, ces ressources reposaient sur les cycles processeur (CPU) et la bande passante réseau.

Le traitement d'un paquet consomme des cycles CPU. Dans le cas d'un trafic normal (c'est-à-dire sans lien avec une attaque), un paquet légitime reçu par un service entraînera une action de la part de ce dernier. Or, différentes actions nécessitent différentes quantités de traitement par le processeur. Toutefois, avant de transmettre le paquet à un service, il convient d'accomplir certaines tâches en fonction du paquet. Les en-têtes de paquet de couche 3 doivent être analysés et traités afin de transmettre le paquet à la machine et à l'interface correctes. Les en-têtes de paquet de couche 4, quant à eux, doivent être traités et acheminés vers le socket correct (le cas échéant). Plusieurs étapes de traitement supplémentaires peuvent être nécessaires pour l'inspection de chaque paquet. Ainsi, un acteur malveillant qui envoie du trafic à un débit de paquets suffisamment élevé peut potentiellement saturer les ressources CPU disponibles et ainsi refuser le service aux utilisateurs légitimes.

Pour vous défendre contre les attaques à haut débit de paquets, vous devez être en mesure d'inspecter et d'éliminer les mauvais paquets en utilisant aussi peu de cycles CPU que possible, tout en laissant suffisamment de ressources processeur pour traiter les paquets adéquats. Vous pouvez également acquérir davantage de processeurs ou des modèles plus rapides pour effectuer le traitement, mais ce processus peut s'avérer très long et d'un coût particulièrement élevé. 

La bande passante réseau constitue la quantité totale de données qui peuvent être transmises à un serveur. Vous pouvez vous représenter la bande passante comme un tuyau d'acheminement d'eau. La quantité d'eau que nous pouvons aspirer à l'aide d'une paille à cocktail est bien inférieure à celle qui circule dans un tuyau d'arrosage. Si un acteur malveillant parvient à envoyer dans le canal une quantité de données indésirables supérieure à ce que ce dernier ne peut accueillir, les données nuisibles et les données utiles seront toutes deux éliminées en amont, à l'entrée du tuyau. L'attaque DDoS sera donc couronnée de succès.

La défense contre les attaques susceptibles de saturer la bande passante réseau peut se révéler difficile, car les possibilités d'action sont extrêmement limitées si l'on se trouve en aval du canal saturé. Seules quelques options sont réellement disponibles : mettre en place un canal plus grand, trouver un moyen potentiel de déplacer le trafic légitime vers un nouveau canal non saturé ou tenter de demander à l'amont du canal de cesser d'envoyer certaines (ou l'ensemble) des données à travers le pipeline.

Si l'on réfléchit à la manière dont se présente l'opération du point de vue des acteurs malveillants, on se rend compte que ces derniers sont soumis à des contraintes similaires. Tout comme une certaine quantité de cycles CPU est nécessaire pour recevoir un paquet, la création d'un paquet met également en œuvre un certain nombre de cycles CPU. Si les coûts d'envoi et de réception d'un paquet sont égaux, par exemple, l'acteur malveillant a besoin d'autant de puissance de calcul pour générer l'attaque que nécessaire pour se défendre contre elle. Toutefois, dans la plupart des cas, l'équation n'est pas vraie. On constate le plus souvent une asymétrie des coûts, car le pirate peut générer des paquets en utilisant moins de cycles processeur qu'il n'en faut pour recevoir ces paquets. Il est toutefois intéressant de noter que la génération d'attaques n'est pas un processus gratuit et que ce dernier peut nécessiter une grande quantité de puissance CPU.

La saturation de la bande passante réseau peut constituer une tâche encore plus difficile pour un acteur malveillant. Ce dernier doit en effet pouvoir générer davantage de bande passante que ce que le service cible lui a alloué. Pour arriver à ses fins, l'acteur malveillant doit ainsi être en mesure de dépasser la capacité du service de destination. L'opération s'avère tellement difficile que le moyen le plus courant d'attaquer la bande passante du réseau consiste à utiliser une méthode d'attaque par amplification, comme une attaque par amplification DNS, par exemple. Ces attaques permettent à l'acteur malveillant d'envoyer un petit paquet à un service intermédiaire, qui renverra un paquet de plus grande taille à la victime.

Dans les deux cas, le pirate doit acquérir ou avoir accès à de nombreux appareils pour générer l'attaque. Ces appareils peuvent être acquis de diverses manières. Il peut s'agir de serveurs (ou du moins de machines de classe « serveur ») appartenant à des fournisseurs de cloud ou des services d'hébergement, voire d'appareils compromis (comme des DVR, des routeurs et des webcams) infectés par le logiciel malveillant du pirate. Ensemble, ces machines constituent ce qu'on appelle un « botnet ».

Maintenant que nous comprenons les fondamentaux du fonctionnement des attaques DDoS, nous pouvons expliquer comment Cloudflare peut vous défendre contre ces dernières.

Le premier ingrédient pas si secret repose sur le fait que le réseau Cloudflare est bâti sur la technologie Anycast. En bref, cette dernière permet à une adresse IP unique d'être annoncée par plusieurs machines dans le monde. Un paquet envoyé à cette adresse IP sera par conséquent transmis par la machine la plus proche. De fait, lorsqu'un acteur malveillant utilise son botnet distribué pour lancer une attaque, cette dernière sera reçue de manière distribuée sur l'ensemble du réseau Cloudflare. Un DVR infecté à Dallas, au Texas, enverra ainsi ses paquets à un serveur Cloudflare situé à Dallas. Une webcam infectée à Londres adressera les paquets à un serveur Cloudflare implanté à Londres.

Réseaux Anycast et réseaux Unicast

Grâce à son réseau Anycast, Cloudflare peut également allouer des ressources de calcul et de bande passante au plus près des régions qui en ont le plus besoin. Les régions fortement peuplées génèrent des quantités plus importantes de trafic légitime. Pour répondre à ces besoins, les datacenters qui s'y trouvent disposent ainsi de ressources plus élevées en termes de bande passante et de CPU. Les régions peu peuplées, quant à elles, génèrent naturellement moins de trafic légitime. C'est pourquoi les datacenters Cloudflare de ces régions peuvent être dimensionnés de manière appropriée. Comme le trafic hostile provient principalement d'appareils compromis, ces appareils auront tendance à être distribués d'une manière qui corresponde aux flux de trafic normaux, en envoyant proportionnellement le trafic hostile vers les datacenters qui peuvent le traiter. De manière similaire, le trafic est réparti sur plusieurs machines au sein du datacenter.

Le réseau Cloudflare présente également un autre avantage contre les attaques à large bande passante. Une grande partie du trafic circulant sur le réseau Cloudflare ne consomme pas la bande passante de manière symétrique. Une requête HTTP visant à obtenir une page web auprès d'un site protégé par Cloudflare, par exemple, s'appuiera sur un paquet entrant relativement petit, mais générera une plus grande quantité de trafic sortant vers le client. Le réseau Cloudflare a ainsi tendance à renvoyer beaucoup plus de trafic légitime que ce que nous recevons. Toutefois, les liaisons réseau et la bande passante allouée présentent un rapport symétrique (c'est-à-dire qu'une grande quantité de bande passante entrante est disponible pour recevoir le trafic hostile volumétrique).

Lorsque vous joignez un serveur individuel au sein d'un datacenter, la bande passante de l'attaque a été suffisamment distribuée pour qu'aucune des liaisons en amont ne soit saturée. L'opération ne veut toutefois pas dire que l'attaque a été totalement arrêtée, car nous n'avons pas encore éliminé les paquets malveillants. Pour ce faire, nous devons échantillonner le trafic, qualifier l'attaque et créer des règles qui permettront de bloquer ces paquets. 

L'échantillonnage du trafic et l'élimination des paquets nuisibles sont des fonctions assurées par notre composant l4drop, qui s'appuie sur le XDP (eXpress Data Path) et une version étendue du code BPF (Berkeley Packet Filter, filtrage des paquets Berkeley) nommée eBPF (extended BPF). Ce composant nous permet d'exécuter du code personnalisé dans l'espace du noyau et de traiter (abandonner, transmettre ou modifier) chaque paquet directement au niveau de la carte d'interface réseau (Network Interface Card, NIC). Le composant aide ainsi le système à abandonner efficacement les paquets, sans consommer les ressources CPU de la machine. 

Vue d'ensemble du système de protection contre les attaques DDoS de Cloudflare

Nous utilisons le XDP pour échantillonner les paquets à la recherche d'attributs suspects indiquant une attaque. Les échantillons comprennent divers champs, comme l'adresse IP source, le port source, l'adresse IP destination, le port destination, le protocole, les indicateurs TCP, le numéro de séquence, les options, le débit de paquets et bien d'autres. Cette analyse est réalisée par notre daemon de déni de service (denial of service daemon, dosd). C'est au niveau du dosd que réside notre recette secrète. Il comporte en effet de nombreux filtres qui lui indiquent, en fonction de nos instruments heuristiques soigneusement sélectionnés, à quel moment déclencher l'atténuation. Pour nos clients, ces filtres sont logiquement regroupés par vecteurs d'attaque et exposés sous la forme de règles DDoS gérées. Nos clients peuvent personnaliser leur comportement dans une certaine mesure, selon leurs besoins.

Lorsqu'il reçoit des échantillons d'XDP, le dosd génère plusieurs permutations d'empreintes numériques pour les schémas de trafic suspects. Il identifie ensuite les empreintes numériques les plus optimales pour atténuer l'attaque, à l'aide d'un algorithme de diffusion de données. Une fois l'attaque qualifiée, le dosd déploie une règle d'atténuation interne (in-line) sous forme de programme eBPF, afin d'éliminer chirurgicalement le trafic hostile. 

La détection et l'atténuation des attaques par le dosd s'effectuent au niveau du serveur, au niveau du datacenter et au niveau mondial. L'ensemble est défini par logiciel. Ce mode de fonctionnement rend notre réseau extrêmement résilient et conduit à une atténuation presque instantanée. Nous n'utilisons pas de « centres de nettoyage » ou de « dispositifs de nettoyage » hors réseau (out-of-path). À la place, chaque serveur exécute l'ensemble de la suite de produits Cloudflare, notamment le composant de détection et d'atténuation des attaques DDoS. De même, tout s'effectue de manière autonome. Chaque serveur échange (envoie en multidiffusion) également des instructions d'atténuation au sein d'un datacenter entre les serveurs et, dans le monde entier, entre datacenters. Ce processus permet de s'assurer que le dosd dispose déjà de règles d'atténuation installées en interne (in-line) afin d'assurer une atténuation robuste, peu importe que l'attaque soit locale ou distribuée à l'échelle mondiale.

Nos systèmes de détection et d'atténuation des attaques DDoS autonomes et définis par logiciel s'exécutent sur l'ensemble de notre réseau. Dans cet article, nous nous sommes principalement axés sur nos capacités d'analyse dynamique des empreintes numériques, mais notre arsenal de systèmes de défense est beaucoup plus vaste. Les systèmes Advanced TCP Protection et Advanced DNS Protection fonctionnent conjointement avec notre outil de prise d'empreintes numériques dynamique pour identifier les attaques DDoS sophistiquées et hautement randomisées basées sur le TCP. Ils tirent également parti de l'analyse statistique pour déjouer les attaques DDoS complexes basées sur le DNS. Nos défenses intègrent également des informations en temps réel sur les menaces, le profilage du trafic et la classification par apprentissage automatique (Machine Learning) dans le cadre de notre protection adaptative contre les attaques DDoS, afin d'atténuer les anomalies du trafic. 

Tout comme l'ensemble de notre catalogue de produits de sécurité, ces systèmes sont tous bâtis sur le réseau Cloudflare, l'un des plus vastes du marché, afin de nous assurer que nos clients sont protégés contre les attaques les plus volumineuses du monde.