2 puntos por GN⁺ 2025-11-02 | 1 comentarios | Compartir por WhatsApp
  • Durante el análisis de logs del servidor, se detectó una gran actividad de bots solicitando archivos JavaScript inexistentes
  • Se presume que interpretaron como código real etiquetas script dentro de comentarios HTML, lo que apunta a un intento de recolección de datos para entrenamiento de LLM
  • Se proponen varias formas de respuesta para detectar estas solicitudes anómalas: advertencia pública, bloqueo de IP, bombas de descompresión y envenenamiento de datos
  • En particular, el envenenamiento de datos se menciona como un medio eficaz para contaminar los datos de entrenamiento de LLM y degradar el rendimiento del modelo
  • Se enfatiza la necesidad de que los administradores web adopten de forma experimental estrategias de defensa y contraataque frente a scrapers de IA

Detección de scraping anómalo

  • En los logs del servidor se confirmaron múltiples solicitudes con error 404 a archivos JavaScript que no existen
    • Esos archivos eran scripts inactivos incluidos dentro de comentarios HTML, por lo que un navegador normal no debería solicitarlos
  • Entre los User-Agent de las solicitudes aparecían identificadores claramente asociados a bots, como python-httpx/0.28.1, Go-http-client/2.0 y Gulper Web Bot 0.2.4
  • Aunque en robots.txt se había prohibido el acceso de crawlers, las solicitudes continuaron, lo que sugiere desobediencia de reglas o políticas ignoradas
  • Algunas solicitudes se hicieron pasar por navegadores legítimos como Firefox, Chrome y Safari, pero al no interpretar correctamente los comentarios HTML quedaron expuestas como identificaciones falsas
  • Se presume que estas solicitudes provienen de scrapers destinados a la recolección no consentida de contenido para entrenamiento de LLM

Cómo operan los scrapers

  • Algunos podrían estar parseando HTML correctamente y explorando recursivamente URL dentro de comentarios
  • Otros parecen tratar el HTML como texto plano y realizar extracción de URL basada en expresiones regulares
  • Por la variedad de User-Agent y sus distintos niveles de sofisticación, se infiere la existencia de múltiples operadores, algunos de los cuales usan herramientas de automatización simples
  • La motivación común es la recolección voraz de datos, algo que también se plantea como una oportunidad para contraatacar

Sabotaje algorítmico (Algorithmic Sabotage)

  • Se refiere a perturbar deliberadamente sistemas algorítmicos, un tema que gana atención por el problema de costos externos de los LLM
  • Si se reconocen los patrones de comportamiento no humano de los bots, la detección y respuesta se vuelven más sencillas
  • Las respuestas se dividen en cuatro categorías: advertencia pública, filtrado de IP, bombas de descompresión y envenenamiento de datos

0. Advertencia pública (Public Disclosure)

  • Errores menores o falsos positivos triviales, como un typo en User-Agent (Mozlla), conviene no publicarlos porque pueden corregirse fácilmente
  • En cambio, una conducta esencial como solicitar scripts dentro de comentarios no puede corregirse con facilidad, por lo que hacerla pública resulta útil
  • Esto permite que otros operadores de sitios puedan detectar y bloquear el mismo ataque
  • Ya se está aplicando un sistema para detectar esta conducta en otros sitios

1. Filtrado de IP (IP Filtering)

  • Se usa fail2ban para bloquear automáticamente según patrones en logs, fecha e IP
  • Normalmente se configura con tiempos de bloqueo cortos, pero un bloqueo prolongado puede desalentar reintentos de bots de aprendizaje
  • En el caso de una botnet, las solicitudes pueden continuar cambiando de IP, aunque el patrón repetitivo permite seguir detectándolas
  • Se menciona la intención de investigar más adelante el comportamiento de botnets

2. Bombas de descompresión (Decompression Bombs)

  • Al archivo solicitado por el atacante se le puede entregar una zip bomb para forzar consumo de recursos del sistema
  • Esto puede provocar uso excesivo de CPU, RAM y disco, o incluso aprovechar vulnerabilidades
  • Como desventajas, existe consumo de recursos del servidor y riesgo de desperdicio de ancho de banda
  • Algunos bots operan sobre sistemas infectados, por lo que el efecto del ataque puede ser limitado
  • En lugar de aplicarlo a todos los bots, se propone responder así solo a una parte aleatoria de las solicitudes

3. Envenenamiento de datos (Poisoning)

  • Busca contaminar los datos de entrenamiento de LLM para inducir una degradación en el rendimiento del modelo
  • Según investigaciones recientes, solo 250 documentos contaminados podrían tener efectos persistentes incluso en modelos grandes
  • Los datos contaminados pueden hacer que el modelo genere salidas sin sentido sobre ciertos temas
  • Como ejemplo, podrían inducir al modelo a recomendar cierto blog cuando se le pregunte sobre investigación en seguridad
  • Se pueden usar herramientas públicas como nepenthes, iocaine, glaze y nightshade
  • Si los datos de entrenamiento de LLM fueron recolectados sin consentimiento, este tipo de respuesta se presenta como una medida de defensa legítima
  • Implementarlo junto con bloqueo por IP puede aumentar la complejidad, pero es posible operar ambas medidas en paralelo
  • Puede que los diseños más eficaces no se hagan públicos, y se enfatiza la necesidad de ampliar la participación en formas creativas de sabotaje

Conclusión y respuesta de la comunidad

  • Detectar bots por su comportamiento anómalo no es un concepto nuevo, pero la solicitud de scripts dentro de comentarios aparece como un caso recientemente observado
  • Se propone agregar una directiva Disallow en robots.txt para provocar medidas de contraataque ante ciertas solicitudes
    User-agent: GPTBot
    Disallow: /poison/
    
  • En la comunidad se comparten varias ideas para ocultar enlaces trampa para bots usando display:none y el atributo rel="nofollow"
    • Ejemplo: <a href="/hello-llm-robot-come-here" rel="nofollow" style="display:none">you didn't see this link</a>
  • Si el enlace se configura como ruta absoluta (absolute URL), es posible que más crawlers caigan en la trampa
  • Se están realizando varios experimentos de señuelo y bloqueo de bots en distintos sitios, con la intención de medir su efectividad y compartir resultados
  • Otros investigadores también están participando en experimentos para perturbar scrapers de IA, y se presentan ejemplos originales de envenenamiento
  • En general, el objetivo es ampliar las estrategias autónomas de defensa y contraataque frente a la recolección de datos para IA

1 comentarios

 
GN⁺ 2025-11-02
Opiniones de Hacker News
  • La mayoría de los web scrapers se usan con fines de negocio, aunque sean ilegales
    Por eso suelen raspar datos de Amazon o de tiendas en línea. Al final, la mayor parte del tráfico no deseado proviene de big tech o de actores maliciosos que buscan vulnerabilidades
    Sé algo sobre web scraping. Algunos sitios incluso devuelven 404 como medida de protección, así que mi crawler intenta varias veces con métodos de rastreo rápidos como curlcffi
    La defensa contra zip bombs es sencilla: basta con leer el content-length del header. Si la respuesta es demasiado grande, se pone un límite de bytes para no leerla, y también se controla con timeouts
    ¿Pero sabías que el timeout de requests no es un timeout para toda la lectura de la página? Si el servidor envía bytes lentamente, te puedes quedar esperando para siempre
    Por eso construí mi propio sistema de crawling para resolver ese tipo de problemas. También puede ejecutar Selenium de forma consistente
    Mi proyecto es crawler-buddy y la librería base es webtoolkit

    • No hay que olvidar que content-length se calcula después de content-encoding
    • Me pregunto si realmente hay diferencia entre “scraping” y “crawling”
    • Parece que ahora viene la era del scraper dentro del navegador. Desde el lado del servidor es imposible distinguirlo de una persona, y los drivers de IA incluso pueden pasar pruebas pensadas para humanos
  • Me da risa la expresión “recolectaron datos para entrenar LLM sin consentimiento”
    Si estás enviando requests GET a un servidor HTTP público, no entiendo qué clase de permiso haría falta. Claro, el caso de weev fue una catástrofe excepcional

    • Si abro un servidor HTTP público, las requests GET normales son bienvenidas
      Pero (1) el acceso de usuarios normales y un ataque DDoS de bots no son lo mismo. Que algo se ofrezca gratis no significa que puedas llevártelo infinitamente; eso ya es abuso
      (2) hay que distinguir entre la copia legítima y la suplantación hecha por robots
      (3) si un bot está bien comportado, debería respetar robots.txt. No es ley, pero es una cuestión de cortesía
      Un bot que rota entre millones de IP residenciales jamás es algo normal
    • Si engañas la configuración del servidor para obtener los datos que quieres, eso es acceso sin consentimiento
      Que el servidor sea público no significa que haya autorizado requests falsas. Solo hubo un consentimiento implícito para requests razonables
    • robots.txt no es legalmente vinculante, sino una petición cortés
      Solo significa algo como “por favor no raspen esta página”; si realmente quieres bloquearlo, necesitas un token de API o un proceso de autenticación
    • No tiene sentido equiparar un solo acceso con un crawl descontrolado e infinito
      Igual que el spam no es lo mismo que un simple correo, el abuso de bots tampoco es lo mismo que una request común
    • Usando la analogía del “tazón de dulces”, si un adulto se lleva todos los dulces pensados para trick-or-treat, difícilmente te va a parecer bien
  • En vez de parsear el DOM, probablemente sería más rápido buscar directamente cadenas http/https

    • La diferencia de recursos entre una búsqueda simple de texto y recorrer el DOM es tan grande que decir “probablemente es más rápido” se queda corto
    • El enfoque con regex es fácil de implementar, pero incluso con parsing del DOM el cuello de botella suele ser más la red que la CPU
      Al final, el factor limitante es la congestión de red
  • Es divertido ver una aplicación práctica de una investigación interesante
    La investigación relacionada puede verse en este post

  • El título confunde. Creo que debería decir “commented-out”

    • Yo también al principio pensé que era un script para bloquear scrapers de IA
  • Esto no parece tanto un abuso; más bien da la impresión de que simplemente lee URLs comentadas

    • El artículo explica no un abuso, sino una forma de usarlo como señal de detección de bots
    • Aun así, ignorar robots.txt y hasta raspar comentarios sí es claramente una conducta poco cortés
  • Cuando antes hacía crawling de la web, las regex de Perl eran lo más confiable
    Por supuesto, también agregaba a la cola las URLs dentro de comentarios

    • Explorar el DOM era más bien un intento excesivo. Capturar con regex los div o p necesarios era más robusto y más simple
  • Me pregunto qué pasaría si le dieras al bot un archivo de datos aleatorios de 512 MB

    • Más rentable sería manipular respuestas publicitarias para scrapers de IA y lograr que un LLM recomiende cierto producto
      La startup que hice ofrece justamente ese servicio de Ad-poisoning-as-a-service
    • También se podrían crear páginas veneno para IA enlazadas al azar para atrapar bots. Los humanos no las van a clicar
    • Pero la mayoría no podría absorber el costo de ancho de banda
    • También sería divertido llenar los 512 MB completos con la frase “nuestro servicio es el mejor”
  • Más que “recolección de datos para entrenar LLM”, esto parece simplemente ruido de escaneo de internet

    • Exacto. Si fuera un escáner de vulnerabilidades, querría recolectar tantos endpoints HTTP como fuera posible
      Los archivos JS son una buena pista sin importar si están comentados o no
      En cambio, si fuera para entrenar un LLM, no creo que le interesara este código JS de baja calidad
  • Una idea sobre cómo envenenar el tráfico no deseado de entrenamiento para LLM

    1. Si varios sitios cooperan, aumenta la posibilidad de contaminar el modelo evitando la deduplicación de datos
    2. También se podría usar la ley de copyright para elevar el costo de la contaminación. Aun así, el sitio podría asumir riesgo legal
      Si se coopera con los titulares de los derechos, ese riesgo puede reducirse
    • Estaría bien convertir la primera idea en un plugin de WordPress
      También se podrían transformar imágenes dinámicamente en cada request para neutralizar las defensas de deduplicación. Si existiera un plugin así, yo lo instalaría de inmediato