Mi servidor Git se volvió inestable por el crawler de IA de Amazon

 (xeiaso.net)
1 puntos por GN⁺ 2025-01-19 | 1 comentarios | Compartir por WhatsApp
  • El servidor público de Gitea git.xeserv.us se volvió inestable por solicitudes de AmazonBot, por lo que el operador pidió al equipo de AmazonBot que agregara ese dominio a su lista de bloqueo
  • Aunque configuró robots.txt para tratar a todos los bots con Disallow: /, las solicitudes siguieron llegando, al punto de que podría tener que abandonar la operación de un servidor Git público
  • Los crawlers de IA dificultan el bloqueo cambiando el user agent o usando proxies con IP residenciales
  • En nginx ingress bloqueó los user agents Amazon devolviendo 418, pero las solicitudes continuaron desde otras IP y cerca del 10% ni siquiera tenía el user agent amazonbot
  • Finalmente, el servidor Gitea volvió a moverse detrás de una VPN, y se creó Anubis, un proxy inverso que realiza una verificación de prueba de trabajo antes de las solicitudes

Solicitudes de AmazonBot y límites de robots.txt

  • El operador pidió a los responsables de AmazonBot que agregaran git.xeserv.us a la lista de dominios bloqueados
  • También pidió que se pusieran en contacto para poder pagar el costo de actualizar el hardware necesario para soportar el uso excesivo de recursos que implica rastrear el servidor Git
  • Ya había configurado un robots.txt para bloquear a todos los bots, pero no fue suficiente para bloquear las solicitudes reales
User-agent: *
Disallow: /
  • También resumió por qué es difícil bloquear bots crawlers de IA
    • Los bots mienten
    • Cambian el user agent
    • Usan direcciones IP residenciales como proxy
    • También usan otros métodos

Bloqueo en nginx ingress y publicación de Anubis

  • El 2025-01-17 a las 17:50 UTC agregó un bloqueo por user agent mediante la configuración de nginx ingress
nginx.ingress.kubernetes.io/configuration-snippet: |
  if ($http_user_agent ~* "(Amazon)" ){
    return 418;
  }
  • Incluso después de esta configuración, el bot siguió haciendo solicitudes desde IP distintas cada vez, y cerca del 10% de las solicitudes no tenía el user agent amazonbot
  • El 2025-01-18 a las 19:00 UTC movió nuevamente el servidor Gitea detrás de una VPN
  • Luego empezó a crear un proxy inverso que verifica una prueba de trabajo antes de permitir solicitudes al frontend del servidor Gitea
  • El 2025-01-18 a las 23:50 UTC, ese proxy quedó disponible con el nombre Anubis en https://git.xeserv.us/
  • Al 2025-03-26 a las 14:27 UTC, Anubis se convirtió en un proyecto independiente con sitio de documentación

Lecturas relacionadas

1 comentarios

 
GN⁺ 2025-01-19
Opiniones de Hacker News

  • Ya es hora de enviar una carta de abogado. Si se revisan las pautas de acusación de la Computer Fraud and Abuse Act, el Departamento de Justicia de EE. UU. generalmente no considera el acceso a servidores públicos como “acceso no autorizado” si no se trata de un ataque evidente, pero establece que, después de que la parte autorizada envía una solicitud clara por escrito para que se detenga y el acusado la recibe y la entiende, a partir de ese momento sí se considera no autorizado.
    Así que basta con pedirle a un abogado que redacte una carta clara de “cease and desist” y entregársela a Amazon por correo certificado o mediante un notificador judicial, según recomiende el abogado. Probablemente convenga hacer ambas cosas y también enviar un email.
    Después se ve si Amazon se detiene; si no se detiene, se puede presentar una denuncia penal. Entonces Amazon sí empezará a prestar atención.
    https://www.justice.gov/jm/jm-9-48000-computer-fraud

    • Eso de “ver si Amazon se detiene” solo tiene sentido si la solicitud realmente viene de Amazon. Por los detalles del post —user agents rotativos, IP residenciales y un comportamiento que parece no interpretar robots.txt—, eso parece poco probable.
      El bot de Amazon debería venir de rangos de IP conocidos de Amazon y respetar robots.txt. Un ingeniero de Amazon también lo confirmó en otro comentario: https://news.ycombinator.com/item?id=42751729
      Si lo único que coincide con Amazon es la cadena de user agent “AmazonBot”, pero no coinciden los rangos de IP ni el comportamiento, enviarle una carta de abogado a Amazon es casi como quemar dinero.
    • Francamente, con que esto haya llegado a la portada de Hacker News ya debería dar suficiente vergüenza como para que alguien del departamento de sentido común lea y responda el email amable que envié diciendo “por favor no raspen mi servidor git”. Si no hay respuesta para el próximo martes, le pediré a un abogado que redacte una solicitud formal de cese.
    • ¿Será que ya necesitamos una ley que diga que los robots deben respetar robots.txt?
    • Me pregunto qué significa exactamente aquí notificador judicial (process server).

  • Me gusta la solución de este comentario: https://news.ycombinator.com/item?id=42727510
    Consiste en poner en algún lugar del sitio un enlace que ninguna persona visitaría, prohibirlo en robots.txt y, si alguna IP visita ese enlace, bloquearla durante 24 horas. Como dicen que el crawler de OpenAI en particular ignora los comodines, lo colocan debajo de un comodín.

    • He lidiado con actividad de bots que usan rangos amplios de direcciones, y he usado un método parecido: si se confirma que cumple las condiciones para ser bot, bloquear esa IP durante 24 horas.
      Pero había tantas IP relacionadas que casi no tuvo impacto en el tráfico.
      Recomiendo mirar los headers recibidos con mucho detalle. varnishlog es bastante bueno para esto y, si se observa durante mucho tiempo, se pueden encontrar rasgos que comparten todas las solicitudes. Por ejemplo, combinaciones raras entre el idioma reportado y la ubicación geográfica, o la misma versión antigua de navegador.
    • Los crawlers web son realmente insoportables. Hace unos 8 años, en un lugar donde trabajaba, se cayó un servidor de imágenes de vehículos. El crawler problemático accedió a enlaces de imágenes de vehículos que teníamos por la naturaleza del negocio y, con la combinación perfecta de malas condiciones en la que las imágenes no existían realmente, prácticamente hizo un DoS al servidor de imágenes de reportes de estado.
      Peor aún, había un bug en el manejador de errores, así que cuando ocurría esa condición el proceso del servidor se reiniciaba, y en el proceso también invalidaba una implementación de caché que “para estándares de .NET 2.0 estaba bastante decente”.
      Por eso recuerdo que empezamos a agregar una técnica de canarios como salvaguarda. Unos cuantos canarios simples seguían siendo más baratos que agregar otro servidor web. Por supuesto, también arreglamos el problema de caché y agregamos una forma de que el servicio “gritara” si recibía demasiadas solicitudes malas.
    • Cuando hice mi propio crawler para un motor de búsqueda, me di cuenta de que casi no hay bibliotecas de crawlers que funcionen bien para el mundo real. Al final me costó bastante implementar por mi cuenta el respeto de los archivos robots bastante complejos y anidados de Amazon y Google, incluyendo los periodos de enfriamiento solicitados.
      Pero resulta que los crawlers de esas empresas ni siquiera podían parsear los manifiestos que ellas mismas habían creado.

  • Nosotros también estamos viendo el mismo comportamiento en todos los bots de AI y SEO, así que lo recomiendo. Apenas respetan robots.txt y también son difíciles de bloquear. Cuando crawlean, llegan en oleadas como spam, suben mucho la carga y tiran muchos servidores de clientes.
    Si los crawlers de AI quieren acceder, tienen que portarse bien o pagar. De lo contrario, el resultado será un bloqueo casi universal.

    • La solución es un tarpit global. Incluso dejando de lado a los crawlers de AI, tiene sentido. Cuando tuve que implementarlo antes, lo hice de forma semimanual: parseaba los logs de acceso y aplicaba -j TARPIT con iptables a las IP que hacían en promedio más de X solicitudes por segundo a /api.
      No sé bien cómo implementarlo en la nube. Todavía no he tenido que hacerlo ahí.
      https://gist.github.com/flaviovs/103a0dbf62c67ff371ff75fc62f...
    • No sé cómo se supone que se lograría un “bloqueo casi universal”. ¿No es precisamente ese el problema, que es difícil? Si fuera posible, ya lo estaríamos haciendo.
    • Me pregunto qué significa que respeten robots.txt “apenas”. ¿No es algo binario? ¿Quiere decir que respetan algunas directivas e ignoran otras?
    • ¿No habrá alguna forma de que un sitio web les venda esos datos a los bots de AI como un archivo zip grande? Parece mejor que estar bajo DDoS constante.
      O, al menos por cortesía, que raspen de noche o en horarios de baja demanda.
    • ¿De qué sirve bloquearlos? Para entonces probablemente ya habrán raspado todo el contenido.

  • No asumiría que esto sea realmente Amazon. El autor está viendo solicitudes que rotan IP residenciales y también cambian la cadena de user-agent
    Hacerse pasar por el crawler de una gran empresa es una técnica común de gente que no quiere llamar la atención. El hecho de que las solicitudes vengan de IP residenciales es una gran señal de alerta de que está pasando otra cosa

    • Trabajo en Amazon, pero no estoy a cargo directamente del web crawling
      Según la información que pude verificar internamente, es muy poco probable que esto sea realmente Amazon. Amazonbot debería respetar robots.txt y venir siempre desde direcciones IP propiedad de Amazon. El procedimiento de verificación está aquí: https://developer.amazon.com/en/amazonbot
      Lo escalé internamente para comprobar si algún equipo interno extraño que no conozco está haciendo esto, pero al autor le conviene tratar este tráfico como malicioso y como que falsifica el user-agent
    • Esto se ofrece comercialmente como servicio[1]. Por alguna biblioteca incluida en algún lado, cientos de millones de redes se usan como si fueran backdoors y se convierten en crawlers/scrapers; además, con alguna redacción amplia en los términos de servicio, se vuelve plausiblemente legal usar a los usuarios como testaferros para actividades entre lo legal y lo ilegal
      [1] https://brightdata.com/proxy-types/residential-proxies
    • Hoy, si una empresa hace crawling agresivo, es difícil asegurar que no use una red de proxies

  • Hace poco tuve el mismo problema. Mi instancia de Forgejo empezó a usar el 100% del CPU de mi servidor casero, y los amigos de IA de Claude, Meta y Google estaban golpeando a gran velocidad una cantidad prácticamente infinita de enlaces
    Lo reduje en parte con robots.txt y una lista de bloqueo basada en user-agent en Caddy, pero no sé cuánto va a durar eso
    ¿A dónde se fue la cortesía en el scraping?

    • Es por dinero. Las empresas de IA tienen incentivos financieros para tomar la mayor cantidad de datos posible, lo más rápido posible, de donde puedan conseguirlos. Ahora además tienen tanto efectivo para quemar que ni siquiera tienen mucha necesidad de hacerlo de forma eficiente
    • Cuando varias empresas reciben señales de que, al menos por ahora, la ventana de Overton sobre qué puede comer la IA es enormemente amplia, van a intentar llevarse todo lo posible antes de que la regulación empiece a apretar
      El riesgo mayor es que una de estas empresas, incluso una que se autodenomina “Open”, llegue a una escala en la que, desde el punto de vista económico o de seguridad nacional, sea “demasiado grande para dejarla caer”
    • Es lo mismo que pasó con la cortesía en todos los demás contextos. La cortesía solo existía en contextos donde ignorarla no daba dinero. En cuanto desaparece esa premisa, se descarta de inmediato
    • ¿Alguien puede compartir un robots.txt decente o una lista de user-agents para bloquear crawlers de IA?
    • ¿Cuándo se va a dar cuenta la última persona en Hacker News de que Meta, OpenAI y todas las grandes tecnológicas terminarán perjudicándonos a todos por dinero rápido?
      Facebook es famoso por haber facilitado scrapear listas de amigos desde MySpace, y después de crecer prohibió exactamente el mismo comportamiento en su propio sitio
      Por favor, hay que despertar

  • ¿Seguro que esto no es un DDoS haciéndose pasar por Amazon?
    Que las solicitudes vengan de IP residenciales es realmente sospechoso
    La motivación de un DDoS así podría ser tumbar sitios pequeños y hacer que parezca culpa de Amazon, apuntando contra Amazon
    Si fuera realmente Amazon, el punto de partida sería bloquear todos los rangos de IP que publican. Aunque suena como que las solicitudes también vienen de fuera de esos rangos

    • Habría que revisar sitios como grass punto io. No pongo el enlace directo porque no quiero mandarles tráfico
      Estos servicios pagan por el ancho de banda de los usuarios y luego lo revenden a terceros, así que mucho tráfico de bots parece venir de IP residenciales

  • Mi sitio, Pinboard, también está siendo golpeado por lo que parecen crawlers de IA. Este verano empezó con IP de China y Singapur, pero ahora ni siquiera puedo bloquear rangos de IP y tengo que depender de CAPTCHA
    El nivel de tráfico es suficiente para matar el sitio de inmediato, y ni siquiera tengo texto interesante para entrenar, solo enlaces
    Me da curiosidad cómo descubrió el autor original que el crawler de Amazon era la causa. Yo también quiero encontrar a quién echarle la culpa

  • La mejor forma de pelear contra esto quizá no sea bloquear. Bloquear no le causa ningún daño a Amazon ni a ninguna otra empresa
    ¿Y si, en cambio, se pudiera alimentar a los bots con contenido claramente dañino o corruptor?
    Si se hace a mayor escala y Amazon descubre datos envenenados, tendría que gastar dinero para eliminarlos rápido e intentaría evitar que sus bots comieran esos datos
    Claro que el mayor problema es que nadie quiere tener ese tipo de cosas en su propio sitio

    • La idea de alimentar con “contenido dañino” entiende completamente mal el alcance del mal comportamiento de las empresas de IA
      Estos scrapers ya están consumiendo sin reparos CSAM y cosas horribles equivalentes. Algunos subcontratistas de etiquetado de datos de OpenAI en Kenia renunciaron por esto. Es un artículo de Time de 2023
      Ahora las empresas de IA no se preocupan por la calidad de los datos, solo por la cantidad. La única forma de dañarlas es entregarles 0 bytes
      Con solo una décima parte de lo que Sam Altman aprobó, una persona común iría directo a la cárcel
    • He visto que recomiendan este tarpit para ese propósito. Cuando el sitio es rastreado, genera anidamientos infinitos de directorios y contenido basura interminable para que el bot quede atrapado durante horas
      https://zadzmo.org/code/nepenthes/
    • Si por contenido dañino te refieres a contenido incorrecto, en otro comentario de este hilo hay alguien que efectivamente hace eso: https://marcusb.org/hacks/quixotic.html
    • Si las empresas de multimillonarios siguen violando la ley con impunidad, ¿por qué debería responsabilizarme yo de mear contra el viento?

  • Estaría bien que Amazon, como gesto de buena voluntad, diera algunos créditos de AWS para compensar el exceso de tráfico saliente generado por sus bots y otros. Igual, probablemente los ingresos publicitarios de este artículo lo cubran. Si desactivan el bloqueador de anuncios, las cuentas cierran

  • Antes de bloquearlos con Nginx, Bytespider representaba el 59% y Amazonbot el 21%; entre ambos sumaban el 80% de todo el tráfico de nuestro servidor Git.
    ClaudeBot envió a Redmine, en un mes, más tráfico que todo el acumulado en los 5 años anteriores a ClaudeBot.