Mobiliser tout un arsenal de petits outils pour bloquer les bots

• Le crawling et le scraping indiscriminés des grandes entreprises de l’IA et de la recherche affectent gravement les serveurs et services personnels, provoquant en continu une consommation de ressources et une instabilité du service
• Après avoir détecté un trafic anormal avec une supervision basée sur Zabbix et Loki, l’auteur a utilisé des outils d’analyse de logs (lnav, goaccess) et des requêtes SQL pour identifier en détail les schémas d’attaque, les IP et les User-Agent
• En mettant en place une défense par étapes dans la configuration Nginx — blocage 403 selon le User-Agent, rate limiting, intégration avec Fail2Ban — il a pu bloquer des centaines d’IP malveillantes et rétablir la stabilité du serveur
• Le problème principal venait de bots tentant de télécharger massivement l’intégralité des dépôts Gitea sous forme de tarballs, avec une forte hausse d’un trafic visant non pas la simple consultation de contenu, mais la collecte de données pour l’IA / l’entraînement de modèles
• À long terme, il réfléchit à une stratégie permettant d’accorder des exceptions à des services légitimes (comme archive.org), tout en maintenant la visibilité dans les moteurs de recherche mais en résistant à l’« enshittification » liée à l’IA

---

Introduction : un déluge de trafic de bots sur mon petit serveur

• Ces derniers temps, un volume massif et inexpliqué de trafic a fortement augmenté sur le blog lambdacreate qu’il exploite personnellement ainsi que sur plusieurs autres services
• Les services légitimes comme Archive.org sont les bienvenus, mais le crawling de données sans discernement par de grands groupes comme Amazon, Facebook, OpenAI nuit au site
• Avec la hausse de la demande de collecte de données pour l’entraînement de modèles d’IA, ce phénomène s’aggrave encore
• Dans ce contexte, au lieu de vrais lecteurs humains, c’est surtout un trafic massif de bots qu’il doit subir

Vérification du problème : diagnostiquer l’explosion du trafic avec des outils de supervision

• Des outils de supervision comme Zabbix et Loki ont été utilisés pour analyser la consommation de ressources du serveur
• Sur l’instance Gitea, le volume de données augmentait de 20 à 30 Go par jour, avec diverses alertes CPU/mémoire
• L’analyse du trafic nginx a montré une moyenne mensuelle de 8 req/s, avec des pics dépassant ponctuellement 20 req/s
• Le trafic n’était pas massif à grande échelle, mais il avait augmenté de près de 10 fois par rapport à l’habitude, jusqu’à épuiser les ressources

Analyse de la cause : examen approfondi des fichiers de logs

• Les logs d’accès nginx ont été analysés en SQL à l’aide de lnav et goaccess
  • Identification de schémas liés aux IP visiteuses, User-Agent, referrers, etc.
• Il s’est avéré qu’il ne s’agissait pas d’un afflux venant d’un service ou d’une communauté particulière, mais d’un crawling massif depuis certaines plages d’IP
• De nombreuses valeurs explicites ou usurpées ont été trouvées dans les User-Agent, dont Amazonbot, OpenAI, Applebot, Facebook
• Comme cela nuisait à l’utilisation réelle du service, la nécessité d’une politique de blocage plus ferme s’est imposée

Solution : combiner plusieurs couches de défense avec Nginx, Fail2Ban, etc.

• Utilisation de Nginx map pour renvoyer immédiatement une 403 aux User-Agent malveillants, avec ajout d’un rate limiting (limitation de la fréquence des visites)
• Même les bots nouveaux ou non encore détectés voient leur fréquence de requêtes web réduite, ce qui minimise la charge sur le serveur
• Détection de nouvelles IP et de nouveaux User-Agent malveillants à partir des logs de 403 avec goaccess et lnav
• Grâce à l’outil de sécurité automatisé Fail2Ban, les IP générant trop de réponses 403 sont automatiquement bloquées pendant 24 heures
  • Plus de 735 bannissements automatiques enregistrés
• L’utilisation réelle des ressources est revenue à un niveau largement normalisé
• À l’avenir, le plan est d’appliquer des règles d’exception pour les services légitimes comme archive.org, d’autoriser l’indexation par les moteurs de recherche, tout en continuant de bloquer le crawling indiscriminé destiné à l’entraînement de l’IA

Conclusion : la force de la combinaison d’outils et la nécessité de sécuriser les services personnels

• L’application de cette série de mesures de défense multicouches a permis de rétablir une exploitation fluide du blog personnel et l’accessibilité des services
• Cela confirme que l’usage de nombreux petits outils d’administration système et d’automatisation est efficace pour la sécurité d’un serveur personnel
• Dans un environnement où même les serveurs personnels sont crawlés sans discernement à cause de la croissance de la demande liée à l’entraînement de l’IA, un blocage proactif et l’automatisation de la gestion deviennent indispensables

[GN⁺]

Avis Hacker News

• Je constate souvent que beaucoup de crawlers peu scrupuleux se contentent d’imiter les grands moteurs de recherche. Certains disent qu’il ne faut pas se laisser tromper par le User-Agent, mais ma méthode préférée consiste à placer des informations piégées dans le robots.txt (par exemple une gzip bomb) et à configurer le blocage du crawler dès la requête suivante s’il les détecte. C’est simple à mettre en place avec Caddy, et cela permet surtout d’attraper les contrevenants les plus flagrants. Je ne cherche pas à excuser le comportement de ces bots, mais si quelques-uns suffisent à faire tomber un site, cela prouve aussi qu’il est vraiment vulnérable face à un attaquant malveillant.

  • J’ai trouvé que le dernier commentaire mettait vraiment le doigt sur l’essentiel. C’est peut-être générationnel, mais je ne comprends pas pourquoi autant d’auteurs aujourd’hui sont obsédés par l’idée de consommer le moins de ressources possible. Ça me rappelle les grands-parents qui s’affolent pour une ampoule LED laissée allumée, ou ceux qui font 24 km pour économiser 5 centimes de carburant. 20 requêtes par seconde, ce n’est vraiment rien, même si les pages sont générées dynamiquement — et dans ce cas, pourquoi faire, alors que configurer un cache serait bien plus rentable en temps. Les articles du style "fuck the bots" sont peut-être à la mode en ce moment, mais le sujet n’a rien de nouveau. Il existe bien des façons plus productives de le gérer sans y perdre son temps.

  • J’aimerais bien en savoir plus sur la façon d’utiliser une gzip bomb via robots.txt. À ma connaissance, la plupart des IA ignorent robots.txt, donc je me demande si, au final, cela ne piège que quelques crawlers naïfs. Je ne suis pas contre par principe, j’aimerais simplement mieux comprendre comment le mettre en place sans nuire aux acteurs de bonne foi.

  • Je gère l’un des plus grands wikis de mon domaine, et convaincre les autres membres de l’équipe de développement d’utiliser une gzip bomb est quasiment impossible. Ils insistent sur le fait que cette méthode comporte trop de risques — avec en toile de fond les réglementations de l’UE — et qu’elle ne vaut pas la peine d’être déployée. Je me demande si quelqu’un utilise vraiment ce genre de technique sur un site public.

• En ce moment, les bots ne respectent plus du tout les fichiers robots.txt, et ça m’agace vraiment. Je trouve que les gens qui les conçoivent sont profondément égoïstes. Si quelqu’un fabrique ce type de bot, qu’il se débrouille.

  • Si on place des pièges (honeypots) dans le fichier robots, cela peut aider à filtrer les bots qui viennent délibérément semer le trouble, même si cela n’attrape pas ceux qui l’ignorent complètement.

  • On pourrait dire à peu près la même chose des utilisateurs de chatbots, de moteurs de recherche ou d’outils de comparaison de prix. Au fond, ce sont eux qui créent l’incitation économique principale derrière ces scrapers.

• Je comprends que l’auteur dise qu’il « n’en a plus rien à faire », mais j’ai vu Google, ripe.net et Semrush dans la liste des IP interdites. Pour d’autres entreprises, passe encore, mais je ne bloquerais vraiment pas Google. Si on veut faire connaître son site, je ne vois pas non plus l’intérêt de bloquer Semrush ou ripe.net. Même si mon contenu est aspiré par des IA ou d’autres énergumènes, à partir du moment où mon site est public, je considère qu’il faut s’attendre à un certain niveau de réutilisation. C’est un peu comme inviter des clients tout en éteignant l’enseigne lumineuse du motel.

  • Semrush a été une nuisance particulièrement grave à plusieurs niveaux pendant longtemps, au point que j’ai laissé un message inhabituel dans mon robots.txt pendant huit ans. Au final, j’ai même dû faire intervenir l’équipe juridique pour les calmer. De mon point de vue, laisser une société de « SEO » labourer brutalement un site tout en évincant les vrais visiteurs n’a aucune valeur. Les concurrents de Semrush étaient tout aussi pénibles. Les scrapers IA actuels sont eux aussi tellement mauvais que j’ai parfois dû envoyer à répétition des lettres de plainte officielles à de grands investisseurs et à des services de relations publiques. J’ai fini par revenir à une situation normale, à grand-peine, à la fois par des moyens techniques et juridiques.

  • Le vrai problème, c’est que les bots consomment en masse du trafic et des ressources réelles — bande passante, mémoire, CPU, disque. L’article mentionne aussi que leur comportement est difficilement défendable sur le plan des bonnes manières. Je ne vois pas pourquoi il faudrait offrir ce trafic à des scrapers. Google exploite aussi des scrapers IA, donc c’est peut-être pour cela qu’il s’est retrouvé sur la liste de blocage.

  • Il existe aussi de vrais bots malveillants qui se font passer pour Google. Autrefois, Google avait une manière de scraper relativement plus polie, mais si l’auteur obtient déjà le trafic dont il a besoin, qu’il les bloque ou non n’a probablement plus beaucoup d’importance.

  • Je me demande si, après toutes ces années, les gens ne se sont toujours pas rendu compte qu’il ne faut pas utiliser Google, surtout maintenant qu’on voit apparaître des cas où Google censure des sites indépendants avec l’IA. Je mets aussi directement le lien vers le commentaire concerné. À ce stade, Google ressemble davantage à un risque qu’à un atout.

• À cause des bots, les fichiers de logs de mes serveurs sont devenus tellement énormes que j’en suis arrivé à désactiver complètement la journalisation. Les bots aspirent obstinément les API, les formulaires, et même des zones du site accessibles uniquement par clic. Anthropic, OpenAI, Facebook et d’autres continuent encore à scraper mon site.

  • S’il s’agit d’API accessibles uniquement par clic, je me demande comment les bots y accèdent.

  • J’aimerais bien avoir plus de détails sur ces API, pour savoir s’il s’agit d’éléments de l’interface ou de parties réellement réservées à des humains, ou s’il n’existe tout simplement aucun autre chemin d’accès. Aujourd’hui, les agents IA imitent de plus en plus les comportements réels des utilisateurs, au point qu’il devient presque impossible de distinguer un humain d’un bot.

• Je trouvais plutôt bien que les bots crawlers d’IA remplissent honnêtement l’en-tête User-Agent, mais j’ai été un peu surpris d’apprendre que cela pouvait représenter une telle part du trafic. La plupart des sites web n’ont pas besoin que leurs données soient récupérées aussi souvent, et pourtant le volume est énorme. Pour un blog de développeur, c’est encore plus difficile à comprendre.

  • La plupart des crawlers IA respectent robots.txt, mais lorsqu’ils sont bloqués, certains passent immédiatement à un User-Agent de navigateur et réessaient depuis des IP résidentielles. Cela dit, comme il existe énormément de faux bots se faisant passer pour OpenAI/Amazon/Facebook, il faut rester prudent avant d’identifier un cas avec certitude.

• Je suis le créateur de tirreno. Notre plateforme est optimisée pour les utilisateurs connectés en direct, mais elle est aussi efficace pour la détection et le blocage des bots. Elle anonymise les IP en remplaçant le dernier octet par un astérisque (*), afin de regrouper un même sous-réseau sous un seul compte. On peut lui faire générer automatiquement des listes noires à partir d’anomalies de trafic (erreurs 500/404, tentatives de connexion en force brute, IP de datacenter, etc.). L’API de liste noire de tirreno permet de rediriger le trafic indésirable vers une page d’erreur. Un tableau de bord de supervision est aussi fourni pour aider à éviter les faux positifs et à gérer l’ensemble.
  tirreno Github, démo administrateur

  • Aujourd’hui, de nombreux FAI sont passés à des architectures CGNAT, ce qui signifie qu’une seule IP peut représenter des centaines d’utilisateurs réels. Je me demande comment vous gérez ce problème.

  • Je travaille aussi sur un système de blocage des bots basé sur des plages d’IP publiques. Toute idée d’amélioration est la bienvenue.

  • Avec ce remplacement du dernier octet de l’IP, je me retrouve regroupé comme un seul utilisateur avec des voisins d’adresses qui n’ont pourtant aucun lien avec moi. Il ne faut pas non plus minimiser les faux positifs dus aux IP de datacenter. En pratique, s’il n’y a pas de blocage explicite, je dois quand même cliquer sur 87 feux de circulation pour réussir à passer. Au final, on a surtout l’impression que cela sert à prétendre qu’aucune donnée personnelle n’est collectée sans consentement, même à l’étape où l’on évite les faux positifs. J’espère vraiment que vous avez prévu un mécanisme de retour qui permette aux clients de comprendre immédiatement qu’ils sont en train de perdre de vrais utilisateurs payants.

• Je me pose cette question depuis longtemps : est-ce qu’une structure de type « page knocking » serait possible, c’est-à-dire ouvrir certaines pages dans un ordre précis pour obtenir un droit d’accès ? Par exemple, obliger à visiter d’abord une URL privée définie pour que le reste des pages s’affiche normalement au lieu de renvoyer une 404.

  • Ce type d’architecture ne convient pas aux cas où il faut permettre à des utilisateurs ordinaires d’arriver directement sur le projet depuis un moteur de recherche, sans création de compte ni authentification préalable.

  • En matière d’ergonomie, même très bien conçu, cela créera forcément des frictions. On peut facilement imaginer des 404 à répétition dès qu’on utilise un favori ou qu’on envoie un lien à un ami.

• Mon petit serveur tourne bien, donc je n’avais pas regardé l’état de fail2ban récemment.
  Comparaison des résultats de commande :

  sshd-ddos:      0
  postfix:       583
  dovecot:     9690
  postfix-sasl: 4227
  nginx-botsearch: 1421
  nginx-http-auth: 0
  postfix-botnet:  5425
  sshd:         202157
  

J’ai été un peu choqué de découvrir que plus de 220 000 IP étaient bloquées.

• Un bot que nous suivons, « DotBot/1.2 », a généré plus de 220 000 requêtes au cours des deux dernières semaines. Son comportement consiste à demander au hasard des noms de fichiers et de dossiers du serveur web. Par curiosité, je ne l’ai pas bloqué, juste pour voir jusqu’où il allait creuser.

• Je me demande s’il ne faudrait pas désormais faire évoluer la structure d’indexation centralisée pour l’IA ou les moteurs de recherche vers un modèle de push ou de soumission. Si je ne partage directement que lorsque je le souhaite, cela réduirait sans doute fortement les problèmes de scraping.

• Quand j’étais enfant dans les années 90, mon FAI avait appelé pour me prévenir que mon ordinateur faisait partie d’un botnet et qu’il allait couper ma connexion Internet. Je me demande si on ne devrait pas revenir à ce genre d’époque et bloquer carrément l’ensemble de l’ASN des FAI qui laissent faire ce type d’activité.

  • Les proxys résidentiels ne sont pas fournis directement par les FAI : ils apparaissent parce que des utilisateurs, partout dans le monde, installent volontairement ou non des malwares qui transforment leur ordinateur en proxy. Un bon article à ce sujet était passé sur HN il n’y a pas longtemps.

  • J’ai configuré une règle de pare-feu qui affiche une alerte chaque fois qu’un appareil de mon réseau tente une connexion sortante vers un port associé à des malwares. La liste des ports doit être mise à jour régulièrement, car les cibles des malwares changent sans cesse. C’est une petite mesure, mais cela ajoute malgré tout une couche de défense supplémentaire.