S’amuser avec les bots de scraping

• Aborde le problème des bots de scraping qui sursollicitent des sites web publics au point de se comporter comme un DDoS, et propose une approche expérimentale consistant à retourner la situation pour leur faire perdre du temps
• Création d’un générateur de texte basé sur des chaînes de Markov pour produire de fausses données ressemblant à des fichiers .php, afin d’inciter les bots malveillants à les télécharger
• Mise en place ensuite d’un serveur de contenu statique fournissant aléatoirement des paragraphes du roman Frankenstein, avec une structure de liens conçue pour provoquer une propagation explosive du crawler
• Ajout sur toutes les pages des attributs noindex, nofollow et d’un compteur de requêtes pour exclure les moteurs de recherche légitimes et ne capter que les bots qui enfreignent les règles
• Les résultats de l’expérience étaient intéressants, mais le risque de faux positifs avec Googlebot a conduit à ne pas l’appliquer à un service réel et à conserver le projet pour l’apprentissage et l’expérimentation

---

Le problème des bots de scraping et une idée de riposte

• Les scrapers provoquent parfois involontairement une charge de niveau DDoS sur de petits sites web
• Certains administrateurs ont demandé des moyens de protection, mais cet article se concentre sur « non pas la défense, mais la contre-attaque »
• Après avoir vu un autre développeur tromper des bots avec des données factices infinies générées par chaînes de Markov, l’auteur a lancé sa propre expérimentation

Générateur de faux PHP basé sur des chaînes de Markov

• Implémentation en Rust d’un apprenant par chaînes de Markov pour générer un contenu réaliste à partir de données textuelles arbitraires
• Cible les bots malveillants qui visent des chemins sensibles comme .env, .aws ou .php, en leur servant du code PHP qui semble réel mais ne signifie rien
• Augmentation de la taille des fichiers de 2 KB à 10 MB pour pousser les bots à gaspiller leurs ressources
• Les exemples de sortie prennent la forme d’un faux code PHP crédible, mêlant noms de fonctions WordPress et commentaires
• L’objectif est de faire perdre du temps et des ressources aux bots, tout en poussant l’attaquant à gaspiller du temps à chercher de vraies vulnérabilités

Efficacité et expérimentation autour d’un contenu statique

• Sur un VPS, servir des fichiers de plus de 1 MB a entraîné une hausse de la latence et de la charge serveur
• Pour résoudre ce problème, création d’un « garbage server » sous forme de site statique
  • Le roman Frankenstein entier est chargé en mémoire, puis 4 paragraphes aléatoires sont renvoyés à chaque requête
  • 5 liens sont ajoutés en bas de chaque page pour déclencher une expansion explosive du crawling (croissance par 5)
• Le résultat est visible sur https://herm.app/babbler/

Détails de conception et mode d’exploitation

• Le roman choisi est dans le domaine public ; il a été retenu en raison de la période d’Halloween et du parallèle entre l’IA et Frankenstein
• Toutes les pages reçoivent les attributs noindex,nofollow pour ne capter que les bots qui enfreignent les règles
• Un compteur du nombre de requêtes est affiché en bas de chaque page ; comme il est basé sur la mémoire, il se réinitialise au redéploiement
• Un serveur distinct pour les requêtes .php a aussi été configuré afin de fournir aléatoirement de vrais fichiers PHP depuis la mémoire
• Le projet est résumé par la formule : « Garbage for the garbage king! »

Risques et limites

• Ce système présente, s’il est appliqué à un vrai service, un risque de faux positifs avec les moteurs de recherche
  • Si Googlebot explore un mauvais endpoint, le site pourrait être classé comme spam
  • Cela peut entraîner une baisse de visibilité dans les résultats de recherche ou l’affichage d’avertissements dans Chrome
• En conséquence, la méthode est déconseillée pour les sites dépendants du référencement et n’est maintenue que comme projet expérimental
• Le babbler pour .php n’étant pas du HTML, il n’a aucun impact sur Googlebot et ne vise que les bots malveillants

Conclusion et avis personnel

• Ajout sur le blog de liens cachés (rel="nofollow") pour attirer les scrapers malveillants
• En cas de dépassement du quota de trafic du VPS, l’usage du cache Cloudflare est envisagé
• Le projet a servi à apprendre le fonctionnement des chaînes de Markov et des bots, dans une expérimentation mêlant amusement et agacement
• En conclusion, tout n’a pas besoin d’être pratique, et parfois le simple plaisir suffit

[GN⁺]

Avis Hacker News

• Le monde change, mais on finit toujours par rencontrer les mêmes problèmes
  Il y a 10 à 15 ans, je me battais déjà contre des services de veille des réseaux sociaux. De grandes marques les payaient pour surveiller le sentiment sur les forums, et ils pillaient sans autorisation la communauté gratuite que j’administrais, en surchargeant le serveur
  Même en bloquant leurs bots, ils revenaient en changeant d’IP et d’UA, donc j’ai créé un filtre qui insérait aléatoirement des noms de marques dans les messages afin de ruiner la qualité de leurs données. Deux jours après l’activation de cette mesure, le scraping s’était complètement arrêté

  • J’ai vécu quelque chose de similaire. Un bot utilisait le formulaire de don de mon site pour tester des cartes bancaires, en réessayant sans cesse avec des IP différentes. Au lieu de le bloquer, j’ai commencé à renvoyer aléatoirement des messages de succès ou d’échec, ce qui a pollué leurs données et ils ont abandonné au bout de quelques jours
  • L’analyse des en-têtes était vraiment utile. Sur mon serveur Fediverse aussi, j’ai remarqué que des bots se faisant passer pour de vieux Chrome n’envoyaient jamais l’en-tête Accept-Language. En configurant nginx pour renvoyer 403, le trafic a commencé à baisser
  • Comme dans le film The Imitation Game, si on réagit immédiatement à chaque requête, l’adversaire s’en aperçoit. Si on ne traite qu’une partie des requêtes ou qu’on renvoie des codes d’erreur aléatoires, cela devient plus difficile à détecter et rend leur débogage bien plus compliqué
  • La plupart des bots n’arrivent toujours pas à imiter correctement un jeu d’en-têtes HTTP. En 2025, on en est encore à filtrer de la même façon, et les bots continuent d’évoluer selon les mêmes schémas
  • Je me demande pourquoi l’insertion de noms d’entreprise a fait disparaître les bots. J’aimerais savoir si c’est parce que le signal des données a été contaminé pendant qu’ils cherchaient des mentions de marques

• Ces bots ne parsèment pas réellement les fichiers PHP ; ils s’en servent pour faire du fingerprinting de détection de vulnérabilités. Ils regardent simplement le code de réponse avant de passer à autre chose

  • Exactement, dans ce genre de cas, des outils comme fail2ban ou crowdsec sont plus efficaces. Depuis que j’utilise crowdsec, je me suis rendu compte que même les serveurs avec peu de trafic subissent énormément de tentatives d’exploration de vulnérabilités
  • Dans ce cas, on pourrait aussi envisager une stratégie consistant à exposer volontairement de fausses vulnérabilités pour attirer les bots. Par exemple, faire tomber des bots automatisés dans un honeypot afin d’observer leur fonctionnement interne. Référence : The Cuckoo’s Egg
  • Si des scrapeurs LLM utilisent ce type de réponse comme données d’entraînement, le risque de poisoning de données pourrait devenir important. Des articles récents disent aussi qu’un modèle peut être saboté avec seulement quelques points de données

• J’ai récemment entendu parler des tarpits pour l’IA et les scrapeurs. Le principe consiste à ne jamais couper la connexion et à faire couler des données infinies très lentement. L’outil Nepenthes m’intrigue et j’aimerais bien l’essayer

• Autrefois, sur HN, on se faisait critiquer si on bloquait les scrapeurs. La logique était : « peu importe la manière dont j’accède au site »

  • Mais aujourd’hui, c’est différent. L’accès ponctuel d’un humain n’a rien à voir avec une entreprise d’IA qui envoie massivement des requêtes au niveau d’un DDoS. Dans le second cas, on reporte clairement ses coûts sur les autres
  • Pour ma part, je trouve qu’un scraping normal est acceptable. Il suffit d’indiquer son UA et de respecter robots.txt. Mais envoyer des dizaines de requêtes par seconde en se faisant passer pour une vieille version de Chrome, comme aujourd’hui, c’est inacceptable
  • Moi, je scrape des sites d’emploi une fois par jour pour un projet universitaire. Ça, c’est un usage raisonnable. En revanche, aspirer du contenu à la minute ou chercher des vulnérabilités, c’est un tout autre problème
  • Ce qui me déprime le plus, c’est que l’arrivée de l’IA affaiblit le sens même de l’éthique. Des gens qui valorisaient autrefois la liberté demandent maintenant un renforcement du copyright ou la suppression de l’anonymat. La technologie rend les gens pires

• Si vous administrez directement un serveur Apache, vous pouvez bloquer immédiatement les requêtes PHP avec RewriteEngine

  RewriteEngine On
  RewriteCond %{REQUEST_URI} (\.php|%2ephp|%2e%70%68%70) [NC,OR]
  RewriteCond %{QUERY_STRING} \.php [NC,OR]
  RewriteCond %{THE_REQUEST} \.php [NC]
  RewriteRule .* - [F,L]
  

  Mon serveur n’a pas de PHP, donc toutes ces requêtes sont malveillantes

  • Sur nginx, je fais quelque chose de similaire. Pour les requêtes PHP ou ASPX, je renvoie le code HTTP 418 “I’m a teapot”

    location ~* \.(?:php|aspx?|jsp|dll|sql|bak)$ { return 418; }
    error_page 418 /418.html;
    

    Ça facilite le filtrage des logs. Exemple : FreeSolitaire.win/wp-login.php

• La plupart des scrapeurs agressifs visent surtout les vulnérabilités WordPress. Ils ne cherchent pas tant le fichier PHP lui-même que sa sortie. Ce genre de configuration ressemble davantage à un honeypot, mais si le bot ne suit pas le script prévu, il s’en va simplement

  • Ils vont probablement chercher dans la sortie, via expression régulière, un motif de connexion administrateur. S’ils ne trouvent rien, ils passent immédiatement à autre chose. Autrement dit, une simple ligne de regex est bien plus efficace que de générer un faux PHP de 4 Ko

• J’avais déjà posté sur HN une stratégie de zipbomb, et le trafic avait explosé jusqu’à 100 000 requêtes en une journée. Impossible à encaisser sur un VPS à 6 $. Aujourd’hui, je ne réponds par zipbomb qu’aux bots les plus agressifs, et je renvoie 403 aux autres. La nouvelle stratégie fonctionne bien, mais j’hésite à la rendre publique à nouveau. Référence : billet précédent

• Avant, je n’utilisais que fail2ban, mais je voulais mettre au point une défense un peu plus amusante
  Dans .htaccess, je redirige les chemins suspects (/.git, /wp-login) vers decoy.php, et je force ensuite le téléchargement d’un decoy.zip de 10 Go.
  decoy.php ressemble au fichier sensible demandé, mais en réalité il diffuse à l’infini de faux logs et de fausses données SQL pour garder le bot occupé

• Ces bots ne récupèrent pas des fichiers PHP ; ils cherchent des vulnérabilités de framework. Si on leur donne une réponse inattendue, ils abandonnent immédiatement et passent à une autre cible

• Parfois je me dis : ne pourrait-on pas utiliser les ressources qu’ils gaspillent pour miner de la cryptomonnaie ?

  • Pour essayer, il faudrait les amener à exécuter du JavaScript, mais la plupart des bots ont probablement déjà des contre-mesures contre ce genre de tentative