Les attaques de scrapers IA rendent le Web ouvert de plus en plus difficile à maintenir

• Les attaques de web scraping visant à collecter des données d’entraînement pour les grands modèles de langage et autres systèmes augmentent depuis plus d’un an, au point d’alourdir le trafic au point de rendre difficile le maintien de l’ouverture des sites web indépendants
• Les attaquants utilisent des proxies résidentiels composés de millions d’appareils ordinaires et mobiles, en n’envoyant que quelques requêtes par IP et en usurpant le user-agent, ce qui neutralise les blocages IP classiques
• Des malwares, des appareils de streaming multimédia vulnérables, des VPN gratuits et des SDK d’applications servent à constituer ces réseaux de proxies; après le démantèlement d’IPIDEA et de NetNut par Google, le volume des attaques a brièvement baissé avant de repartir à la hausse
• Les sites répliquent avec la preuve de travail d’Anubis, des CAPTCHA, des barrières de connexion ou payantes, et des outils d’empoisonnement des données, mais LWN se concentre surtout sur l’optimisation du site et la réduction des coûts en période d’attaque afin de ne pas gêner les vrais lecteurs, les moteurs de recherche et l’Internet Archive
• Alors que le coût des défenses contre les scrapers et de la vérification des utilisateurs est reporté sur l’ensemble du Web, l’absence de solution durable pourrait pousser les sites indépendants derrière des murs d’accès et endommager l’Internet ouvert

---

Des attaques de scrapers toujours plus importantes

• Le problème de la collecte de données d’entraînement pour les grands modèles de langage et projets associés, déjà traité au début de 2025, continue de s’aggraver plus d’un an plus tard
• Les requêtes envoyées vers les sites web par des acteurs non identifiés ont atteint un niveau sans précédent, et la surcharge de trafic rend le maintien du Web ouvert de plus en plus difficile

Des proxies résidentiels mobilisant des millions d’IP

• Les attaques consistent à envoyer, pendant plusieurs heures, des requêtes coordonnées depuis des millions d’adresses IP uniques, chaque adresse n’accédant au site que deux ou trois fois au maximum
• Les informations contrôlées par les attaquants, comme le user-agent, sont fictives et font passer chaque requête pour l’accès d’une personne ordinaire utilisant un navigateur web
• Les bots ne récupèrent généralement ni les images ni les CSS, ce qui permet de les distinguer des humains, mais au moment où l’identification est faite, l’adresse n’est déjà plus réutilisée, ce qui rend le blocage IP a posteriori inefficace
• Le trafic provient principalement de réseaux domestiques et mobiles pilotés par un nœud central de commande et de contrôle
  • Un logiciel installé sur des appareils ordinaires reçoit les ordres du nœud de contrôle, récupère les pages web puis retransmet les données
  • Une part importante fonctionne sans que le propriétaire de l’appareil en soit conscient ou y ait consenti; les systèmes ainsi exploités sont appelés proxies résidentiels

Réseaux de proxies criminels et appareils infectés

• Un premier type d’opérateurs est constitué de groupes criminels qui exécutent des scrapers sur des systèmes compromis par des malwares
• Google a entrepris en début d’année le démantèlement du botnet IPIDEA et a publié des informations sur son mode de fonctionnement
  • Le moment de l’interruption d’IPIDEA coïncide avec une forte baisse du trafic de scrapers observée par LWN
  • Quelques mois de relatif répit ont suivi, avant une nouvelle hausse des attaques
• Plus récemment, des appareils de streaming multimédia ont été identifiés comme vecteurs majeurs de logiciels de scraping malveillants
  • Certains appareils sont infectés dès la chaîne d’approvisionnement
  • D’autres sont vendus avec une sécurité trop faible et se compromettent facilement ensuite

Réseaux commerciaux de proxies via VPN gratuits et SDK d’apps

• Un autre type d’acteurs se comporte comme des entreprises partiellement légitimes et vend des adresses IP “obtenues de manière éthique”
• Bright Data est un exemple représentatif d’entreprise qui met en avant sa capacité à contourner les contrôles d’accès et les limitations de trafic des sites web
  • Les utilisateurs de VPN “gratuits” doivent autoriser Bright Data à faire transiter du trafic via leur appareil
  • Les téléphones et autres appareils utilisant ce VPN deviennent des points de terminaison du réseau de proxies résidentiels de Bright Data et peuvent être mobilisés pour attaquer des sites web
• Des entreprises similaires fournissent des bibliothèques que les développeurs peuvent intégrer à leurs produits, et rémunèrent parfois ces développeurs en échange de l’accès à la connexion réseau des utilisateurs
  • L’une d’elles a demandé à LWN s’il était possible d’y publier une publicité pour son SDK, mais la conversation a vite pris fin
  • Ces opérateurs vont de sociétés cherchant à se donner une apparence légale en mettant en avant la “conformité au RGPD” à d’autres qui affichent un comportement ouvertement non éthique
• Comme ces opérateurs de proxies peuvent exécuter du code ayant accès aux ressources de réseaux connectant des millions d’appareils, on ne peut pas supposer que cette capacité soit utilisée uniquement pour le web scraping

Entreprises de modèles et utilisateurs de réseaux de proxies

• Des entreprises bien connues dont le cœur d’activité est le développement de modèles pratiquent aussi elles-mêmes le scraping du Web
  • Le trafic qui leur est facilement attribuable s’identifie clairement via le user-agent
  • Elles respectent généralement des mécanismes de contrôle comme robots.txt
  • Elles recollectent à répétition l’ensemble du site, comme pour vérifier si des articles remontant à 2003 ont récemment changé
  • Toutefois, elles n’envoient pas un volume de trafic ingérable à l’échelle de millions de systèmes et ne constituent donc pas le principal problème
• On ne sait pas clairement qui paie pour lancer des attaques via proxies résidentiels
  • Aucune preuve ne confirme que les entreprises à la pointe des modèles utilisent ces réseaux
  • Ces entreprises ne divulguent ni la manière dont elles alimentent leurs modèles en données ni l’origine de leurs données d’entraînement, et elles n’ont pas montré de grand respect pour les créateurs de contenu ni pour ceux qui s’inquiètent des problèmes opérationnels
• Derrière chaque modèle public, il peut exister de nombreux modèles qui ne sont pas exposés publiquement
  • Beaucoup d’entreprises peuvent développer leurs propres modèles dans l’espoir qu’une avance dans la course à l’IA leur apporte une valorisation énorme
  • Des agences gouvernementales non publiques de plusieurs pays peuvent également chercher à obtenir leurs propres modèles et données d’entraînement
  • De grandes organisations criminelles pourraient elles aussi vouloir leurs propres modèles
• Les outils d’IA étant désormais perçus comme des armes, une course aux armements est en cours, et l’Internet tout entier s’y retrouve entraîné

Des défenses pour préserver l’Internet ouvert

• Les opérateurs de sites web mettent en place divers dispositifs de défense pour bloquer les attaques tout en limitant autant que possible l’impact sur les vrais utilisateurs
• Anubis est largement utilisé pour bloquer les scrapers en imposant une preuve de travail (proof of work) aux visiteurs
• Des services commerciaux affichent un bouton demandant de “prouver que vous êtes humain”, tandis que d’autres sites imposent des CAPTCHA consistant à choisir des cases avec des feux tricolores ou à assembler des pièces de puzzle
• Certains sites ont déplacé leurs fonctions principales derrière une connexion ou un paywall, et empoisonnent activement les données reçues par les scrapers avec des outils comme iocaine
• Le coût de construction et de maintenance de ces défenses, ainsi que la gêne subie par les utilisateurs qui doivent les franchir, constituent une lourde charge imposée au monde entier par les scrapers et ceux qui les financent

La défense de LWN et ses contraintes

• LWN a récemment subi l’attaque de scrapers la plus puissante à ce jour, mais grâce aux défenses mises en place, le site a absorbé le trafic au point que la plupart des lecteurs réels ne s’en sont pas aperçus
• Les moyens de défense précis ne sont pas rendus publics, car les divulguer donnerait aux attaquants des informations pour s’adapter; la défense aussi est engagée dans une course aux armements
• La priorité est de réduire autant que possible l’impact sur les vrais lecteurs
  • LWN n’utilise pas Anubis, car cela retarde l’accès au site et gêne les lecteurs
  • Il semble probable que les scrapers finiront par contourner Anubis, et certains signes laissent penser que c’est déjà le cas
  • Si l’on peut mobiliser les appareils de millions de tiers, une preuve de travail ne constitue pas un obstacle majeur
• LWN ne veut pas non plus bloquer l’accès des moteurs de recherche légitimes ni d’organisations comme Internet Archive
  • Une liste blanche explicite n’autorisant que les moteurs dominants renforcerait encore la position de monopoles dont la qualité de service pose déjà problème
  • Jusqu’à présent, LWN a réussi à maintenir un accès normal sans liste blanche dédiée à un moteur de recherche particulier
• Le site optimise agressivement certaines parties, et minimise pendant les attaques les opérations les plus coûteuses
  • Les lecteurs anonymes peuvent parfois en ressentir les effets, mais les utilisateurs connectés ne sont pas touchés
  • Il arrive même que le temps de réponse soit plus rapide qu’en temps normal lorsque les mesures de défense sont actives pendant une attaque
• Ces mesures ne sont pas considérées comme une solution permanente, et il faut déjà réfléchir à la prochaine réponse lorsque leur efficacité disparaîtra

Démantèlement de NetNut et calme temporaire

• Google a annoncé le 2 juillet, en coopération avec le FBI et d’autres partenaires, avoir démantelé le réseau de proxies résidentiels NetNut
• Après cette action, le niveau des attaques de scrapers semble avoir quelque peu baissé, mais l’expérience passée suggère que ce calme ne durera probablement pas
• Le Google Play Store prévoit d’examiner les applications infectées par NetNut
• Les principaux opérateurs d’app stores n’expliquent toujours pas pourquoi il est si facile d’y publier des applications disposant de fonctions de proxy résidentiel

Un Internet repoussé derrière des murs

• Il faut une solution plus durable avant que l’ensemble d’Internet ne se replie derrière des murs d’accès et que le réseau ouvert qui favorisait la créativité ne disparaisse
• L’industrie qui alimente ces attaques se moque de savoir si elle récupère le contenu de sites web indépendants au prix de leur destruction, et cette même indifférence s’étend aussi à la planète et à l’économie
• Tant qu’un minimum de normes éthiques ne sera pas appliqué aux entreprises exploitant les grands modèles de langage et les technologies associées, ce comportement continuera, et les opérateurs de sites web n’auront d’autre choix que de se défendre eux-mêmes

[GN⁺]

Avis sur Lobste.rs

• Parmi toutes les activités ouvertement louches dont j’ai entendu parler récemment, les proxys résidentiels sont de loin ce qui m’a le plus choqué
  J’ai lu plus en détail sur https://spur.us/blog/smart-tv-apps-residential-proxy-sdks, et j’ai du mal à croire que ce soit légal. Il faut classer ça dans la même catégorie qu’un botnet et appeler cela un botnet légalisé

  • C’est vraiment une activité qui mérite d’être dénoncée. Ils disent n’utiliser que des partenaires vérifiés et approuvés, mais je n’arrive pas à imaginer un seul usage légitime des proxys résidentiels. Est-ce qu’il en existe réellement ?
  • Il faut faire attention à la régulation des proxys résidentiels. Si on crée une réglementation qui les cible, cela affectera bien plus de choses que les seuls botnets de proxys résidentiels

• Une autre victime, ce sont les vérificateurs de liens. Il devient assez difficile de vérifier si un site contient des liens morts
  Si j’avais le temps, j’essaierais probablement d’utiliser le projet Common Crawl pour vérifier si le contenu est toujours accessible

  • Les aperçus de liens générés côté expéditeur dans les applications de chat en souffrent aussi. J’étais content d’avoir contribué cette fonctionnalité à gajim, un client XMPP, mais en pratique c’est déprimant de voir les requêtes de prévisualisation de liens se faire si souvent bloquer par des écrans de type « vérification que vous êtes humain »

• Au final, toutes les opérations coûteuses comme l’affichage de l’historique d’un dépôt GitHub finiront derrière une barrière d’authentification, et le reste sera généré de façon statique puis servi via un CDN

  • Comme la centralisation et la surveillance étatique posent problème, les CDN devraient être un dernier recours, et il vaudrait mieux d’abord tirer davantage de performances du serveur lui-même
    Au niveau applicatif, générer davantage de contenu statique, réduire les requêtes vers la base de données et utiliser le cache aide clairement. Pendant longtemps, on a eu le luxe de ne pas trop se soucier des performances, mais désormais même les petits sites doivent y faire plus attention, et c’est toujours préférable à voir le « vérification du navigateur » de Cloudflare partout
    J’ai déjà eu des problèmes sur un petit VPS à cause de l’approche traditionnelle d’Apache, qui fork un processus distinct à chaque requête. Ayant grandi en bricolant des serveurs LAMP, Apache m’est familier et confortable, mais ce n’est pas la manière la plus efficace d’utiliser la machine, et au final c’est ça qui compte le plus. Je n’ai pas de données empiriques, mais j’ai l’impression qu’un serveur comme Caddy tiendrait mieux la charge, donc je pense migrer lors de la prochaine mise à niveau du serveur
  • Mon serveur Forgejo était dans la même situation. J’ai essayé de gérer le trafic malveillant continu avec Anubis, mais je n’ai jamais vraiment compris comment ajuster la configuration à ce trafic précis, et je n’aimais pas non plus être moi-même confronté à des défis d’authentification lents
    J’ai aussi essayé fail2ban, mais à plus grande échelle cela ne répondait pas correctement. J’ai fini par laisser Cloudflare s’en charger avec les règles de sécurité résumées dans ce billet de blog. J’étais réticent à dépendre de Cloudflare sur le long terme, mais j’ai changé d’avis après avoir vu le graphique d’utilisation CPU en bas de l’article
  • En revanche, les dépôts Git et les crawlers font extrêmement mauvais ménage. Les liens générés dynamiquement provoquent une explosion combinatoire et créent des pièges à crawler improvisés, si bien que tout crawler un peu correct évite activement les URL contenant de longues chaînes hexadécimales dans le chemin
    Cela engendre des coûts énormes pour les hébergeurs Git, et pourtant, étonnamment, beaucoup d’entre eux ne configurent pas robots.txt pour empêcher l’exploration en profondeur à l’intérieur des dépôts

• Le passage disant : « on m’a demandé d’expliquer les mesures prises pour défendre le site, mais pour des raisons évidentes je préfère ne pas en discuter en détail. À ce niveau aussi, une course aux armements est en cours » m’a fait mal au cœur
  J’ai moi aussi eu pas mal de succès dans cette lutte, mais à cause de la tragédie des communs, si je rends publiques les mesures très simples que j’ai utilisées, elles perdront de leur efficacité. C’est un sujet vraiment fascinant et j’ai même des idées originales, donc j’aimerais en faire un billet de blog, mais je ne peux pas, et c’est bien dommage