- L’auteur exploite Spigot, un générateur factice de hiérarchies de pages web, qui expose des pages générées aléatoirement face aux web crawlers agressifs
- Il a récemment constaté que des image crawlers exploraient intensivement le site à la recherche d’images jpg
- Pour générer des images en temps réel avec un minimum de ressources CPU, il propose d’utiliser comme modèle uniquement les parties structurées de vrais fichiers JPEG, puis d’insérer des données aléatoires dans la partie compressée
- Les essais montrent que les JPEG créés de cette manière, malgré des erreurs, peuvent tout de même être affichés par la plupart des visionneuses d’images et paraissent suffisamment plausibles pour les crawlers
- Cette méthode consomme peu de ressources serveur, tout en imposant une charge aux crawlers, et elle est appliquée à environ 60 % des pages de Spigot
Contexte de Spigot et de la falsification JPEG
- Spigot génère en temps réel une fausse hiérarchie de pages web basée sur une chaîne de Markov, afin de fournir des données dénuées de sens aux web crawlers agressifs
- Certains crawlers utilisent des signatures de navigateur aléatoires et des IP variées pour masquer leur identité, ce qui laisse entrevoir un possible usage abusif d’appareils compromis via un botnet
- L’analyse du trafic a confirmé qu’un nouveau crawler, "ImageSiftBot", sollicitait massivement les pages de Spigot pour collecter des images
- L’objectif principal de Spigot est de minimiser l’utilisation CPU du serveur tout en conservant un fonctionnement efficace
Réflexion autour d’une génération d’images à bas coût
- Générer des images dynamiquement entraîne une forte consommation CPU à cause de la compression, d’où le besoin d’une méthode plus efficace
- L’idée part du fait qu’un fichier JPEG se compose d’une structure de fichier (taille, couleur, etc.) et d’une zone de données de pixels compressées
- Après avoir extrait uniquement les informations d’en-tête structurées de plusieurs JPEG, la zone des données de pixels est remplie avec des données aléatoires
- Cela permet de générer des images à la volée sans avoir à les compresser à chaque fois, réduisant au minimum la charge côté serveur
Structure des fichiers JPEG et implémentation réelle
- Un fichier JPEG est constitué de plusieurs chunks (avec marqueurs et longueurs)
- On conserve l’en-tête et les métadonnées, on enregistre seulement la longueur des données de pixels compressées, puis on injecte des données aléatoires uniquement dans cette zone
- Avec 514 échantillons JPEG, l’ensemble des en-têtes et des données structurées nécessaires n’occupe qu’environ 500 KB, ce qui représente une charge mémoire négligeable
- Exemple de code : génération d’images en remplissant de nombres aléatoires le chunk de données de pixels de chaque modèle
Résultats en production et publication en open source
- En pratique, les visionneuses d’images peuvent afficher une image dans une certaine mesure même si la zone de pixels est entièrement aléatoire
- Les web crawlers ont du mal à identifier l’erreur, ce qui augmente leur coût de collecte
- Sur la base de JPEG 1280x960 de 200 à 300 KB, environ 900 images par seconde peuvent être générées, ce qui reste parfaitement compatible avec un traitement en temps réel
- La méthode est appliquée à 60 % de l’ensemble des pages de Spigot, avec une graine aléatoire basée sur l’URL pour renvoyer la même image en cas de nouvelle requête
- Un volume élevé de requêtes a été observé de la part de ImageSiftBot, Meta, AmazonBot, GPTBot, etc.
- Le but central est d’imposer une charge aux crawlers avec très peu de ressources serveur
Codes Huffman et optimisations supplémentaires
- Les données de pixels des JPEG utilisent un codage Huffman, si bien qu’une insertion totalement aléatoire peut provoquer des erreurs dans certaines visionneuses
- L’ajout d’une simple technique de masquage de bits (
0x6D) empêche l’apparition de plus de trois 1 consécutifs, ce qui réduit la probabilité de produire un code Huffman invalide de 90 % à moins de 4 %
- Il serait possible de produire un flux Huffman entièrement valide, mais le gain serait minime au regard des ressources serveur et du temps de développement nécessaires
Conclusion
- La méthode de génération de faux JPEG de Spigot permet, avec une efficacité remarquable, d’économiser les ressources serveur tout en semant la confusion chez les crawlers et en leur faisant gaspiller des ressources
- Le code associé tient en moins de 100 lignes et a été publié sur GitHub
- C’est une technique de défense et de dispersion du trafic web à la fois simple et créative
1 commentaires
Avis sur Hacker News
Le fait que le fichier robots.txt bloque l’accès des robots à l’arborescence /spigot/ était attendu, mais il a été constaté qu’en retirant simplement /spigot/ de l’URL, on pouvait toujours accéder à Spigot ; comme l’espace de noms /~auj n’est pas bloqué par robots.txt, même un crawler de bonne foi peut tomber par hasard sur ce chemin et se retrouver piégé dans une boucle infinie de pages, ce qui n’est pas très réjouissant lien vers robots.txt
Il y avait auparavant un commentaire de l’auteur indiquant qu’il n’avait pas configuré robots.txt séparément ; il explique que, dans ce choix assez extrême, il n’aime pas l’idée que les administrateurs de sites web doivent délibérément mettre en place des protections pour éviter un DOS causé par les crawlers. Selon lui, un crawler légitime ne devrait pas marteler un site à plus de 15 requêtes par seconde de manière continue
Même sur le fait que des crawlers de bonne foi puissent se retrouver dans une boucle infinie de pages, il reste sceptique quant à l’obligation qu’aurait un administrateur de site d’être « aimable » envers ceux qui scrapent son site ; il n’est pas certain que ce soit nécessaire
Si un crawler ignore robots.txt et qu’on parvient à l’identifier, il semble plus efficace de monopoliser sa connexion réseau et de la laisser pendante plutôt que de lui servir des informations « poubelles » ; il n’est pas évident de voir pourquoi il faudrait fournir indéfiniment des déchets à un endpoint
Une idée pour perturber les scrapers destinés à alimenter l’IA serait d’ajouter une fausse légende à chaque image : par exemple, mettre « un chat joue avec une boule d’herbe à chat » sur une image d’un amas vert, et « un rouge-gorge fait son nid » sur une image bleue
Le cas le plus extrême est le bot facebookexternalhit exploité par Meta (Facebook) ; il est même officiellement documenté que ce bot ignore robots.txt. Facebook le justifie par la détection de liens malveillants, mais en pratique, si un utilisateur malveillant soumet en boucle à Facebook des URL vers des endpoints coûteux, cela revient à faire lancer par Facebook lui-même une bombe de trafic ; ainsi, plusieurs jours par mois, le site reçoit plus de 10 r/s pendant une journée entière
En lisant cet article sur Spigot, cela a rappelé Project Honeypot ; il y a 20 ans, c’était très enthousiasmant de recevoir des e-mails expliquant que les scripts du projet et les enregistrements MX donnés avaient aidé à attraper des collecteurs d’adresses e-mail sur son site, par exemple en signalant qu’un expéditeur de spam non confirmé (IP : 172.180.164.102) avait été repéré grâce à son MX
Fabriquer un faux JPEG demande bien moins de CPU que d’en produire un vrai ; en outre, cela peut aussi faire office de fuzzing en provoquant éventuellement des crashs si le décodage JPEG côté malware adverse est défaillant
Le fait que le trafic récent provienne de milliers d’IP résidentielles n’implique pas forcément un botnet classique ; il peut plutôt s’agir d’une structure de « proxyware », où de nombreuses personnes s’inscrivent à un « VPN gratuit » ou à un outil de « revenu passif », et leur appareil devient alors un nœud de sortie pour le trafic d’autres utilisateurs. Dans ce cas, elles peuvent servir à leur insu de relais au trafic de crawlers IA référence connexe
Au fond, ce type de proxyware est aussi une variante de botnet à laquelle les utilisateurs ont adhéré volontairement ; comme il est peu probable que ces gens découvrent sur HN ou ailleurs que leur IP pose problème, l’idée d’afficher, pour certaines IP, une page d’avertissement du type « vous faites partie d’un botnet » semble acceptable. En pratique, le plus simple reste de tout bloquer sans distinction
Avis selon lequel ce genre de structure entre tout à fait dans la catégorie des botnets
La manière de parler de comment satisfaire les bots est marquante ; c’était un article amusant et le projet est intéressant
L’attitude consistant à dire « j’ai eu pitié du bot qui peinait à accomplir sa mission, alors j’ai réfléchi à une façon de le divertir » paraît vraiment originale et amusante ; cela tranche nettement avec les fils habituellement pleins de colère et de plaintes
J’aime bien le résultat (l’image) de ce lien voir l’image, on dirait une sorte de pièce artistique porteuse d’un message
Pour vivre la véritable expérience Spigot, dans Firefox on peut faire F12 > Network > remplacer No Throttling par GPRS, et dans Chromium faire F12 > Network > créer un Custom profile à 20kbps pour limiter le débit de façon réaliste
Je me demande s’il y a aussi ici du contenu lié à Shakespeare