Mon serveur Git déstabilisé par le crawler IA d’Amazon

 (xeiaso.net)
1 points par GN⁺ 2025-01-19 | 1 commentaires | Partager sur WhatsApp
  • Le serveur Gitea public git.xeserv.us est devenu instable à cause des requêtes d’AmazonBot, et l’administrateur a demandé à l’équipe AmazonBot d’ajouter ce domaine à sa liste de blocage
  • Bien que tous les bots aient été interdits via robots.txt avec Disallow: /, les requêtes ont continué, au point que l’exploitation d’un serveur Git public pourrait devoir être abandonnée
  • Les crawlers IA rendent le blocage difficile en changeant d’user-agent ou en utilisant des proxies sur IP résidentielles
  • Un blocage a été mis en place dans nginx ingress pour renvoyer 418 aux user-agents contenant Amazon, mais les requêtes ont continué depuis d’autres IP, et environ 10 % n’avaient même pas l’user-agent amazonbot
  • Finalement, le serveur Gitea a été replacé derrière un VPN, et un reverse proxy nommé Anubis, qui effectue une vérification de preuve de travail avant les requêtes, a été créé

Requêtes AmazonBot et limites de robots.txt

  • L’administrateur a demandé à l’opérateur d’AmazonBot d’ajouter git.xeserv.us à la liste des domaines bloqués
  • Il a aussi demandé à être contacté afin que soit pris en charge le coût d’une mise à niveau matérielle nécessaire pour supporter le crawl du serveur Git
  • Un robots.txt bloquant déjà tous les bots était en place, mais cela n’a pas suffi à empêcher les requêtes en pratique
User-agent: *
Disallow: /
  • Il a également résumé pourquoi il est difficile de bloquer les bots de crawl IA
    • les bots mentent
    • ils changent d’user-agent
    • ils utilisent des adresses IP résidentielles comme proxy
    • ils emploient aussi d’autres méthodes

Blocage dans nginx ingress et publication d’Anubis

  • Le 2025-01-17 à 17:50 UTC, un blocage par user-agent a été ajouté dans la configuration nginx ingress
nginx.ingress.kubernetes.io/configuration-snippet: |
  if ($http_user_agent ~* "(Amazon)" ){
    return 418;
  }
  • Même après ce réglage, le bot a continué à envoyer des requêtes à chaque fois depuis des IP différentes, et environ 10 % des requêtes n’avaient pas l’user-agent amazonbot
  • Le 2025-01-18 à 19:00 UTC, le serveur Gitea a de nouveau été déplacé derrière un VPN
  • Ensuite, le développement d’un reverse proxy a commencé devant le serveur Gitea afin de vérifier une preuve de travail avant d’autoriser les requêtes
  • Le 2025-01-18 à 23:50 UTC, ce proxy était accessible sous le nom Anubis à l’adresse https://git.xeserv.us/
  • Au 2025-03-26 à 14:27 UTC, Anubis était devenu un projet indépendant avec son propre site de documentation

À lire aussi

1 commentaires

 
GN⁺ 2025-01-19
Avis sur Hacker News

  • Il est temps d’envoyer une lettre d’avocat. Si l’on regarde les lignes directrices en matière de poursuites au titre du Computer Fraud and Abuse Act, le ministère américain de la Justice ne considère généralement pas l’accès à un serveur public comme un « accès non autorisé » lorsqu’il ne s’agit pas d’une attaque manifeste, mais il indique qu’à partir du moment où le titulaire des droits envoie ensuite une demande écrite claire de cessation, et que le défendeur la reçoit et la comprend, l’accès est alors considéré comme non autorisé
    Il suffit donc de demander à un avocat de rédiger une lettre de « cease and desist » claire, puis de la faire remettre à Amazon par courrier recommandé ou par huissier/agent de signification, selon ce que recommande l’avocat. Il faudra probablement faire les deux, et envoyer aussi un e-mail
    Ensuite, il faut voir si Amazon s’arrête ; si ce n’est pas le cas, il est possible de déposer une plainte pénale. Là, Amazon commencera à s’en soucier
    https://www.justice.gov/jm/jm-9-48000-computer-fraud

    • « Voir si Amazon s’arrête » n’a de sens que si ces requêtes viennent réellement d’Amazon. Vu les détails de l’article — user agents tournants, IP résidentielles, comportement qui semble ne pas interpréter robots.txt — cela paraît peu probable
      Le bot d’Amazon devrait venir de plages d’IP connues d’Amazon et respecter robots.txt. Un ingénieur d’Amazon l’a aussi confirmé dans un autre commentaire : https://news.ycombinator.com/item?id=42751729
      Si la seule chose qui correspond à Amazon est la chaîne de user agent « AmazonBot », alors que les plages d’IP et le comportement ne correspondent pas, envoyer une lettre d’avocat à Amazon revient à peu près à brûler de l’argent
    • Honnêtement, le simple fait que ce soit arrivé en une de Hacker News devrait être suffisamment embarrassant pour que quelqu’un au service du bon sens lise et réponde à mon e-mail poli demandant de « ne pas scraper mon serveur git ». Si je n’ai pas de réponse d’ici mardi prochain, je demanderai à un avocat de rédiger une demande formelle de cessation
    • Est-ce qu’on en est au point où il faut une loi disant que les robots doivent respecter robots.txt ?
    • Je me demande ce que signifie exactement ici process server

  • J’aime bien la solution proposée dans ce commentaire : https://news.ycombinator.com/item?id=42727510
    L’idée est de placer quelque part sur le site un lien qu’aucun humain ne devrait visiter, de l’interdire dans robots.txt, puis de bloquer pendant 24 heures toute IP qui visite ce lien. Comme il paraît que le crawler d’OpenAI ignore notamment les wildcards, on le place sous une wildcard

    • J’ai déjà eu affaire à des activités de bots utilisant de larges plages d’adresses, et j’ai employé une méthode similaire : lorsqu’une IP était confirmée comme bot selon les critères, elle était bloquée pendant 24 heures
      Mais il y avait tellement d’IP concernées que cela n’avait presque aucun effet sur le trafic
      Je recommande d’examiner les en-têtes reçus très en détail. varnishlog est assez bon pour ça, et à force de regarder longtemps, on finit par trouver des caractéristiques communes à toutes les requêtes. Par exemple une combinaison inhabituelle entre langue déclarée et localisation géographique, ou la même vieille version de navigateur
    • Les crawlers web, c’est vraiment une plaie. Il y a environ 8 ans, dans une entreprise où je travaillais, un serveur d’images de véhicules était tombé. Le crawler en question avait accédé à des liens vers des images de véhicules que nous avions par nature dans notre activité, et une combinaison parfaite de mauvaises conditions — les images n’existaient pas réellement — a pratiquement DoS le serveur d’images des rapports d’état
      Pire encore, il y avait un bug dans le gestionnaire d’erreurs : quand cette condition se produisait, le processus serveur redémarrait, ce qui invalidait au passage une implémentation de cache qui était « plutôt correcte pour du .NET 2.0 »
      Je me souviens donc avoir commencé à ajouter une technique de canari comme garde-fou. Quelques canaris simples coûtaient encore moins cher que l’ajout d’un autre serveur web. Bien sûr, nous avons aussi corrigé le problème de cache et ajouté un mécanisme qui « hurlait » quand ce service recevait trop de mauvaises requêtes
    • Quand j’ai construit le crawler de mon moteur de recherche, je me suis rendu compte qu’il existait très peu de bibliothèques de crawling réellement adaptées au monde réel. J’ai fini par devoir fournir pas mal d’efforts pour implémenter moi-même le respect des fichiers robots assez complexes et imbriqués d’Amazon et de Google, ainsi que des délais de refroidissement demandés
      Et pourtant, les crawlers de ces entreprises n’arrivaient pas à parser les manifestes qu’elles avaient elles-mêmes créés

  • Nous observons le même comportement de la part de tous les bots IA et SEO, donc je recommande aussi cette approche. Ils respectent robots.txt à peine, et ils sont difficiles à bloquer. Quand ils crawlent, ils arrivent comme du spam, augmentent fortement la charge et font tomber beaucoup de serveurs de clients
    Si les crawlers IA veulent accéder aux sites, ils doivent se comporter correctement ou payer. Sinon, le résultat sera un blocage quasi généralisé

    • La solution, c’est un tarpit global. Même sans parler des crawlers IA, ça se tient. À l’époque où j’ai dû en implémenter un, je parsais semi-manuellement les logs d’accès et j’appliquais avec iptables un -j TARPIT aux IP qui faisaient en moyenne plus de X requêtes par seconde sur /api
      Je ne sais pas trop comment l’implémenter dans le cloud. Je n’en ai pas encore eu besoin là-bas
      https://gist.github.com/flaviovs/103a0dbf62c67ff371ff75fc62f...
    • Je ne vois pas comment on ferait un « blocage quasi généralisé ». Le problème, justement, n’est-il pas que c’est difficile ? Si c’était possible, on l’aurait déjà fait
    • Je me demande ce que signifie respecter robots.txt « à peine ». Ce n’est pas binaire ? Est-ce que cela veut dire qu’ils respectent certaines directives et en ignorent d’autres ?
    • Il n’y aurait pas un moyen pour les sites de vendre ces données aux bots IA sous forme de gros fichier zip ? Ça me semblerait mieux que de se faire DDoS en continu
      Ou alors, au minimum, qu’ils aient la politesse de scraper la nuit ou en dehors des heures de pointe
    • À quoi bon bloquer ? À ce stade, ils auront déjà aspiré tout le contenu

  • Je ne supposerais pas que ce soit réellement Amazon. L’auteur voit des requêtes qui font tourner des IP résidentielles et changent aussi de chaîne User-Agent
    Se faire passer pour le crawler d’une grande entreprise est une technique courante chez ceux qui veulent passer inaperçus. Le fait que les requêtes viennent d’IP résidentielles est un gros signal d’alerte indiquant qu’il se passe autre chose

    • Je travaille chez Amazon, mais je ne m’occupe pas directement du crawling web
      D’après les informations que j’ai pu vérifier en interne, il est très peu probable que ce soit réellement Amazon. Amazonbot est censé respecter robots.txt et doit toujours provenir d’adresses IP appartenant à Amazon. La procédure de vérification est ici : https://developer.amazon.com/en/amazonbot
      J’ai tout de même fait remonter en interne pour vérifier si une équipe interne bizarre dont je n’aurais pas connaissance fait ce genre de choses, mais l’auteur ferait mieux de traiter ce trafic comme malveillant et comme usurpant son User-Agent
    • Ce genre de chose est commercialisé sous forme de service[1]. À cause d’une bibliothèque incluse quelque part, des centaines de millions de réseaux sont utilisés comme des backdoors et deviennent des crawlers/scrapers, tandis qu’une formulation très large enfouie quelque part dans les conditions d’utilisation rend plausible la légalisation du fait d’utiliser les utilisateurs comme hommes de main pour des activités à la limite du légal et de l’illégal
      [1] https://brightdata.com/proxy-types/residential-proxies
    • Aujourd’hui, difficile de garantir qu’une entreprise qui crawle agressivement n’utilise pas de réseau de proxies

  • J’ai eu le même problème récemment. Mon instance Forgejo s’est mise à utiliser 100 % du CPU de mon serveur domestique, parce que Claude et les amis IA de Meta et Google martelaient à grande vitesse un nombre pratiquement infini de liens
    J’ai réduit un peu le problème avec robots.txt et une liste de blocage par User-Agent dans Caddy, mais je ne sais pas combien de temps ça tiendra
    Où est passée la politesse du scraping ?

    • C’est une question d’argent. Les entreprises d’IA ont une incitation financière à récupérer le plus de données possible, le plus vite possible, partout où elles peuvent en obtenir. Elles ont aussi tellement de cash à brûler en ce moment qu’elles n’ont même pas vraiment besoin d’être efficaces
    • Quand plusieurs entreprises reçoivent le signal que, au moins pour un temps, la fenêtre d’Overton sur ce que l’IA peut ingérer est extrêmement large, elles vont essayer d’en prendre un maximum avant que la régulation ne se resserre
      Le plus grand risque, c’est que l’une de ces entreprises, même une qui se prétend « Open », atteigne une taille telle qu’elle devienne « trop grosse pour faire faillite » du point de vue économique ou de la sécurité nationale
    • C’est la même chose que pour la politesse dans tous les autres contextes. La politesse n’existait que dans les contextes où l’ignorer ne rapportait pas d’argent. Dès que cette prémisse disparaît, elle est immédiatement abandonnée
    • Quelqu’un peut-il partager un robots.txt correct, ou une liste de User-Agents, pour bloquer les crawlers d’IA ?
    • Quand la dernière personne sur Hacker News se rendra-t-elle compte que Meta, OpenAI et toutes les Big Tech finiront par nous nuire à tous pour de l’argent facile ?
      Facebook est connu pour avoir facilité le scraping des listes d’amis depuis MySpace, puis pour avoir interdit exactement le même comportement sur son propre site une fois devenu gros
      Il faut vraiment se réveiller

  • Es-tu sûr que ce n’est pas un DDoS déguisé en Amazon ?
    Le fait que les requêtes viennent d’IP résidentielles est vraiment louche
    La motivation de ce genre de DDoS pourrait être de faire tomber de petits sites et de faire croire qu’Amazon est responsable, afin de viser Amazon
    Si c’était réellement Amazon, le point de départ serait de bloquer toutes les plages d’IP qu’ils publient. Cela dit, on dirait que des requêtes arrivent aussi depuis l’extérieur de ces plages

    • Il faut regarder des sites comme grass point io. Je ne mets pas de lien direct parce que je ne veux pas leur envoyer de trafic
      Ces services paient les utilisateurs pour leur bande passante, puis la revendent à des tiers, ce qui fait que beaucoup de trafic de bots semble provenir d’IP résidentielles

  • Mon site Pinboard se fait aussi matraquer par ce qui semble être des crawlers d’IA. Cet été, ça a commencé avec des IP chinoises et singapouriennes, mais maintenant je ne peux même plus bloquer par plages d’IP et je dois compter sur des CAPTCHA
    Le niveau de trafic suffit à tuer le site instantanément, alors que je n’ai même pas de texte intéressant à entraîner, seulement des liens
    Je me demande comment l’auteur du billet original a déterminé que le crawler d’Amazon était en cause. Moi aussi, j’aimerais trouver à qui attribuer la responsabilité

  • La meilleure façon de lutter contre ce genre de choses n’est peut-être pas le blocage. Bloquer ne fait aucun mal à Amazon ni aux autres entreprises
    Et si, à la place, on pouvait faire ingérer au bot du contenu manifestement nuisible ou corrupteur ?
    Si cela se faisait à plus grande échelle et qu’Amazon découvrait des données empoisonnées, ils devraient dépenser de l’argent pour les retirer rapidement et essaieraient d’empêcher leurs bots d’en ingérer
    Bien sûr, le principal problème est que personne n’a envie d’héberger ce genre de choses sur son propre site

    • L’idée de leur faire ingérer du « contenu nuisible » repose sur une incompréhension totale de l’étendue des mauvais comportements des entreprises d’IA
      Ces scrapers ingèrent déjà sans scrupule du CSAM et des choses horribles du même ordre. Une partie des sous-traitants kényans d’OpenAI chargés du tagging de données ont démissionné à cause de cela. C’était dans un article de Time en 2023
      Les entreprises d’IA, aujourd’hui, ne s’intéressent pas à la qualité des données, seulement à la quantité. La seule façon de leur nuire est de leur envoyer 0 octet
      Pour un dixième seulement de ce que Sam Altman a approuvé, une personne ordinaire irait directement en prison
    • J’ai déjà vu recommander ce tarpit pour cet usage. Quand le site est crawlé, il génère une imbrication infinie de répertoires et une quantité infinie de contenu poubelle pour piéger les bots pendant des heures
      https://zadzmo.org/code/nepenthes/
    • Si par contenu nuisible tu veux dire contenu inexact, il y a justement quelqu’un dans un autre commentaire de ce fil qui fait ça : https://marcusb.org/hacks/quixotic.html
    • Des entreprises de milliardaires continuent d’enfreindre la loi en toute impunité ; pourquoi est-ce à moi de prendre la responsabilité de pisser contre le vent ?

  • Ce serait bien qu’Amazon nous donne quelques crédits AWS en signe de bonne volonté pour compenser l’excédent de trafic sortant généré par Amazon et les autres bots. Cela dit, les revenus publicitaires de cet article devraient probablement couvrir ça. En désactivant le bloqueur de pub, l’équilibre est atteint

  • Avant le blocage via Nginx, Bytespider représentait 59 % et Amazonbot 21 % ; à eux deux, ils comptaient donc pour 80 % de tout le trafic de notre serveur Git
    En un mois, ClaudeBot a envoyé vers Redmine plus de trafic que sur les cinq années précédant ClaudeBot cumulées