Comment arrêter un bot AWS d’envoyer 2 milliards de requêtes par mois ?

• Sur une infrastructure AWS, un problème inattendu de requêtes web massives est survenu
• Un trafic ayant brutalement augmenté de 200 millions à 2 milliards de requêtes par mois a été signalé
• L’analyse des logs a confirmé des requêtes répétées provenant d’un User-Agent spécifique
• Bien qu’un contact ait été pris avec le support AWS, aucune solution claire n’a été obtenue
• La nécessité d’examiner différentes méthodes de blocage, comme des règles de pare-feu ou le blocage par User-Agent, s’est imposée

---

Présentation du problème

• Un utilisateur AWS a soulevé la question d’un phénomène ayant généré 2B (2 milliards) de requêtes sur un serveur web en un mois
• Ces requêtes provenaient d’un bot utilisant un User-Agent spécifique et constituaient un trafic anormal ne correspondant pas à un schéma d’utilisation légitime
• Cette hausse soudaine du trafic comporte un risque de hausse des coûts et de surcharge du système

Analyse de la cause

• La majorité de ce volume massif de requêtes provenait de plages d’IP AWS suspectes
• L’examen des journaux d’accès a permis d’identifier un bot ou script spécifique comme cause probable
• Le User-Agent présentait un motif commun, rendant un filtrage possible

Réponse apportée jusqu’ici et limites

• Une demande a été adressée au support AWS, mais aucune mesure décisive n’a été proposée
• Un tel volume de requêtes augmente fortement le risque de perturbation du service et de coûts supplémentaires

Pistes de résolution et points à considérer

• Il faut envisager différentes politiques de blocage, comme l’ajout de règles de pare-feu, le blocage du trafic basé sur le User-Agent ou l’application d’une liste noire d’IP
• À plus long terme, la nécessité de renforcer le système de surveillance du trafic et de mettre en place un dispositif de détection et de blocage automatiques des accès anormaux se fait sentir

[GN⁺]

Commentaire Hacker News

• J’ai déjà essayé des redirections 30x, par exemple en renvoyant via une réponse 301 vers de très gros fichiers hébergés par des entreprises que je n’aime pas ; si ça pousse cette instance AWS à télécharger 70 000 ISO Windows en même temps, ils finiront sûrement par s’en rendre compte. Et même si c’est moins simple avec Cloudflare, on peut aussi utiliser une stratégie dite de « tar pit » : après avoir reçu la requête, on envoie la réponse un caractère à la fois, avec 30 secondes de délai entre chaque caractère. Avec 10 KB d’en-têtes/réponse par requête et 700 requêtes par seconde, le serveur aura simplement l’air extrêmement lent.
  • Si vous n’aimez pas viser une entreprise en particulier comme cible de la redirection 301, vous pouvez choisir Amazon par exemple.
  • Le fait de recevoir la requête puis de répondre très lentement, caractère par caractère, est en quelque sorte l’inverse d’une attaque DDoS Slow Loris ; pour une explication de Slow Loris, voir chez Cloudflare. Autrement dit, ce n’est pas l’attaque qui utilise des connexions lentes, c’est la défense qui réplique avec des connexions lentes.
  • Comme autre option, on peut aussi faire une redirection 301 vers le site officiel du gouvernement en .sg pour laisser les forces de l’ordre locales s’en occuper.
  • Il est souligné que le trafic entrant sur AWS est gratuit, donc même si le propriétaire de l’instance reçoit une énorme quantité de données, AWS ne lui facturera pas de frais supplémentaires.
• Une autre méthode consiste à rendre l’exploitation du bot clairement malveillant coûteuse sur le plan opérationnel ; des techniques comme une gzip bomb peuvent être efficaces si le bot y est vulnérable, mais même attendre simplement environ 10 secondes avant d’envoyer la réponse peut suffire à lui faire consommer environ 7 000 ports côté serveur, ce que la plupart des processus Linux ne supporteraient pas avant de tomber. C’est facile à mettre en place avec nginx + mod-http-echo.
  • Des gens ont déjà implémenté ce genre de stratégie en pratique ; on peut le voir dans la liste des user agents du code open source, et l’implémentation elle-même est très simple. Le code concerné est visible ici.
  • Les clients AWS paient le trafic sortant, mais je me demande aussi s’il existe un moyen de pousser un gros volume de trafic vers nous depuis AWS ou Cloudflare au contraire.
  • J’ai vécu une situation similaire : un scraping malveillant répétitif visait les informations de prix de notre site, avec plusieurs millions d’articles au catalogue et un calcul de prix dynamique qui consommait énormément de ressources. Un déluge soudain de requêtes a même failli mettre notre service à terre. Comme stratégie de défense, nous avons essayé de distinguer le trafic spam via des tags pour le mettre en cache sans impact pour les vrais clients, et nous avons aussi discuté de l’ajout d’une erreur aléatoire dans les prix afin de rendre les données elles-mêmes inutilisables. Au final, nous nous sommes stabilisés sur une collaboration avec Cloudflare pour bloquer rapidement les requêtes malveillantes, mais cela a coûté du temps et de l’argent. L’attaquant semblait être un prestataire sous-traité d’un concurrent ; c’était d’autant plus frustrant qu’une API officielle aurait pu être fournie, mais ils n’ont jamais pris la peine de nous contacter. Autrefois, il existait une certaine idée selon laquelle « si un site ne supporte pas le trafic, c’est la faute du site », mais j’ai l’impression que les mentalités ont beaucoup évolué.
  • Je me demande si, avec cette méthode, ce n’est pas aussi mon serveur qui consomme 7 000 ports.
  • Question : avec cette technique, est-ce que mon serveur ne finit pas lui aussi avec le même grand nombre de connexions ?
• Je suis l’auteur principal d’Anubis. J’ai constaté qu’en configurant Cloudflare pour renvoyer une réponse HTTP 200, le bot cesse de marteler dès qu’il reçoit un 200.
  • Au passage, il semble y avoir un souci sur le site principal en ce moment.
  • J’ai aussi essayé de forcer carrément la fermeture de la connexion dès qu’une détection est faite au niveau applicatif ; quand la configuration côté Cloudflare est pénible, ça semble fonctionner contre les bots les plus rudimentaires.
• J’ai vécu quelque chose de similaire sur mon blog personnel il y a 7 ou 8 ans : le trafic a soudainement explosé et j’ai d’abord cru à une viralité, mais le comportement était trop mécanique pour être normal. Après enquête, il s’est avéré qu’un bot/crawler testait mon site en le scrapant. Après plusieurs mois de demandes polies restées sans effet, j’ai fini par rediriger ce bot vers des sites porno aléatoires, et le crawling s’est arrêté.
  • C’est probablement la meilleure méthode en pratique : rediriger vers un endroit que le crawler ne veut pas voir dans ses logs, ou vers lui-même, son fournisseur de service, ou un contenu indésirable.
• Une autre vengeance assez satisfaisante consiste à inclure la chaîne de test EICAR dans le corps d’une réponse 200 afin de polluer ses données ; voir l’explication du fichier de test EICAR.
  • Comme une sorte d’inverse du SSRF, il serait amusant de rediriger le bot vers l’API de métadonnées cloud pour l’amener à appeler un endpoint comme <shutdown>. On pourrait même ajouter la chaîne de test EICAR dans la réponse de redirection pour déclencher aussi les systèmes automatiques de détection de sécurité.
• Si vous n’avez aucune raison de recevoir du trafic légitime depuis AWS Singapore, une autre option consiste à blackholer toute cette plage.
  • On peut utiliser un WAF pour dropper complètement ces paquets ; la fonction « block » du WAF de Cloudflare sert à ce genre d’usage.
  • J’ai déjà fait ça moi aussi : le bot Byte Spider opéré par Byte Dance avait aspiré des millions d’images, et j’avais fini par demander à Cloudinary de bloquer le user agent, tout en bloquant au départ l’ensemble de Singapore. Le caractère franchement malveillant de certains bots d’entreprises de scraping IA m’a vraiment mis en colère. Heureusement, l’usage d’un bon service comme Cloudinary a permis de limiter les coûts, et aujourd’hui je règle ça en bloquant l’ensemble des bots IA via Cloudflare.
  • Pour référence, les plages IP par région AWS sont listées ici.
• En 2018, j’ai vécu quelque chose de similaire à bien plus petite échelle. J’avais créé moi-même un outil qui lisait la liste json officielle des plages IP AWS et bloquait ces plages dans Windows Firewall. On peut consulter le billet de blog correspondant ici et le readme de l’outil ici. Cela a très bien tourné pendant des années dans une tâche planifiée sur le serveur, même si je ne suis plus certain que ça fonctionne encore aujourd’hui. Si cela intéresse quelqu’un, je pourrais publier le code ou le transmettre à quelqu’un d’autre ; de toute façon, ce ne serait pas très difficile à réimplémenter. Bonne chance.
• L’autorité de régulation des télécommunications à Singapour interdit même la simple possession de pornographie ; l’idée proposée est donc de répondre au bot malveillant avec du softcore, tout en signalant le cas par e-mail à l’autorité et à AWS.
  • Lorsqu’une entité cause des dommages répétés sur Internet, utiliser le droit du pays concerné est souvent le moyen le plus efficace de réagir ; des autres organismes, on ne peut généralement rien attendre.
• Si vous signalez à Cloudflare que ce trafic est malveillant, ils peuvent le bloquer en dehors de votre compte, ce qui évite de faire peser la charge sur vos propres métriques de trafic.
• J’ai eu une expérience semblable avec des requêtes massives sur un installateur logiciel de 80 MB ; j’ai redirigé les requêtes fautives vers un fichier nommé please-stop.txt, et dans ce fichier j’expliquais la situation en demandant qu’ils arrêtent. Et ils se sont effectivement arrêtés.