Comment le mode Anti-DDoS de DataDome a protégé un site web d’actualités leader aux États-Unis

Dans cet article, nous entrons dans le détail d’une attaque DDoS massive de couche 7 qui ciblait un site web d’actualités leader aux États-Unis. En raison du volume de requêtes de bots — atteignant plus de 2,459 millions de requêtes par seconde au pic le plus fort — le mécanisme anti-DDoS de DataDome a été déclenché. Ce mécanisme nous permet de protéger efficacement les sites web, les applications mobiles et les API contre les pics de trafic soudains.

Ainsi, dans cet article, certains des graphiques sont liés au mode de détection standard des bots de DataDome, tandis que d’autres sont liés aux requêtes gérées par le mode anti-DDoS.

Indicateurs clés

De 21h54 UTC à 22h21 UTC le 27 février 2024, l’API de connexion du site d’actualités a été ciblée, ce qui indiquerait habituellement une tentative de credential stuffing ou d’account takeover. Cependant, le volume et la vitesse des requêtes indiquent que l’attaquant tentait plutôt de rendre le site indisponible par le biais d’une attaque DDoS.

Aperçu de l’attaque DDoS

Le graphique ci-dessous (Figure 1) représente le trafic de bots détecté au fil du temps par notre moteur de détection. Comme mentionné précédemment, il ne prend pas en compte les requêtes gérées par notre mécanisme anti-DDoS.

Figure 1 : Nombre de requêtes de bots gérées par le moteur de détection de bots de DataDome au fil du temps pendant l’attaque.

En effet, alors que le volume de trafic entrant atteignait des pics de 2,459M de requêtes/seconde (Figure 2), notre moteur de détection activait ses mécanismes anti-DDoS.

Figure 2 : Série temporelle représentant le volume de requêtes provenant de l’attaquant pendant la partie la plus intense de l’attaque. Au pic, les clients ont reçu plus de 2,459M de requêtes/seconde.

Le graphique ci-dessous (Figure 3) représente le volume de requêtes gérées par le mécanisme anti-DDoS de DataDome. Nous avons observé que ce mécanisme agissait rapidement quelques secondes après le début de l’attaque. C’est le composant qui a géré la majorité des requêtes DDoS (>505M de requêtes).

Figure 3 : Série temporelle représentant le volume de requêtes gérées par notre mécanisme anti-DDoS pendant l’attaque.

Distribution de l’attaque

L’attaque a été distribuée à travers 43 740 adresses IP. Le graphique ci-dessous (Figure 4) représente le nombre distinct d’adresses IP de bots pendant l’attaque.

Figure 4 : Nombre d’adresses IP de bots distinctes utilisées au fil du temps. Lorsque l’attaque a commencé, nous avons observé des pics de 12K d’adresses IP distinctes utilisées par minute.

Si nous examinons de plus près les adresses IP utilisées lors de l’attaque, nous observons que l’attaque provenait de plusieurs systèmes autonomes (Figure 5), incluant des FAI américains bien connus tels que Comcast, AT&T et Verizon (UUNET).

Figure 5 : Volume de requêtes par système autonome (AS) principal impliqué dans l’attaque.

Indicateurs de compromission (IoCs) de l’attaque

L’attaquant a utilisé différents user-agents, tous relativement à jour :

• Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36
• Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/97.0.4692.99 Safari/537.36 Edg/97.0.1072.91
• Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:121.0) Gecko/20100101 Firefox/121.0
• Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36 OPR/106.0.0.0
• Mozilla/5.0 (X11; CrOS x86_64 14989.11.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/105.0.0.0 Safari/537.36

Certains user-agents—comme Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/86.0.4240.198 Safari/537.36—étaient malformés (ici la citation était contenue dans le user-agent). Cela est survenu soit parce que l’attaquant utilisait une base de données d’user-agents contenant des valeurs erronées, soit parce qu’il n’échappait pas correctement les chaînes dans son code.

L’attaquant a utilisé différentes combinaisons de langues acceptées, mais la majorité d’entre elles incluaient la langue anglaise américaine puisque c’est la langue du site web.

L’attaquant a utilisé différentes empreintes TLS ; cependant, l’empreinte JA3 la plus commune était 0cce74b0d9b7f8528fb2181588d23793. Si nous analysons le trafic avec cette empreinte JA3 sur notre base de clients, nous observons qu’elle est également liée aux user-agents suivants :

• node-fetch/1.0 (+https://github.com/bitinn/node-fetch)
• axios/0.17.1

Ainsi, nous pouvons conclure que l’attaquant a utilisé un client HTTP(s) basé sur NodeJS pour mener l’attaque. De ce fait, l’attaquant n’a exécuté aucun payload JS.

Comment l’attaque a-t-elle été bloquée ?

Grâce à notre approche multicouche, l’attaque a été bloquée en utilisant différentes catégories indépendantes de signaux. Ainsi, si l’attaquant avait modifié une partie d’un bot—comme l’empreinte, le comportement, etc.—il aurait probablement été attrapé en utilisant d’autres signaux et approches.

Les principaux signaux et approches de détection utilisés ici étaient les suivants :

• Incohérences d’empreintes : Les requêtes présentaient différentes incohérences dans leurs empreintes, à la fois au niveau HTTP et au niveau TLS. Par exemple, certaines des requêtes avec des user-agents obsolètes—comme Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; en) Opera 8.54—envoyaient des en-têtes HTTP récents de client-hints. Les différentes empreintes TLS utilisées par l’attaquant étaient également liées à des clients HTTP connus.
• Détection comportementale : Notre moteur comportemental a remarqué un changement dans la distribution du trafic, en particulier une augmentation anormale du trafic sans exécution de JS sur les API de connexion. Chaque adresse IP avait également une distribution anormale d’user-agents, et elles ont toutes commencé à utiliser trop d’empreintes distinctes par rapport à ce que nous observons habituellement sur ce site web.
• Signaux contextuels et de réputation : Nos modèles ML ont également pu tirer parti du fait que la plupart des requêtes de l’attaquant provenaient d’adresses IP signalées comme proxies, utilisant des user-agents obsolètes/non standard, provenant de sessions qui étaient toutes nouvelles.

Conclusion

Les attaques DDoS sont le fléau de la plupart des entreprises opérant en ligne ; elles sont généralement très médiatisées et ont des impacts négatifs immédiats sur les revenus, la réputation de la marque et l’expérience client. Le puissant moteur de détection ML de DataDome utilise plusieurs couches de protection, examinant une variété de signaux allant des empreintes aux comportements en passant par la réputation. Cette approche nous aide à détecter les bots les plus sophistiqués—une approche renforcée par notre défi invisible de vérification de dispositif et CAPTCHA intégré.

Lorsque notre système détecte une attaque DDoS en cours, nos mécanismes anti-DDoS permettent une protection qui s’adapte parfaitement, peu importe le nombre de requêtes envoyées par l’attaquant. Pour mieux comprendre comment DataDome arrête les attaques DDoS de couche 7, planifiez une démo dès aujourd’hui.