Jugar con los bots scraper

• Se aborda el problema de los bots scraper que saturan sitios web públicos con demasiadas solicitudes, actuando como un DDoS, y se presenta un enfoque experimental para aprovechar eso y hacerles perder el tiempo
• Se creó un generador de texto basado en cadenas de Markov para producir datos falsos que parecen archivos .php, induciendo a los bots maliciosos a descargarlos
• Después se construyó un servidor de contenido estático que entrega párrafos aleatorios de la novela Frankenstein, diseñado para que los crawlers se propaguen de forma explosiva mediante su estructura de enlaces
• A todas las páginas se les añadieron los atributos noindex, nofollow y un contador de solicitudes, para excluir a los motores de búsqueda legítimos y detectar solo a los bots que ignoran las reglas
• Los resultados del experimento fueron interesantes, pero por el riesgo de falsos positivos con Googlebot, no se aplicó al servicio real y se mantuvo como un proyecto de aprendizaje y experimentación

---

El problema de los bots scraper y una idea para responder

• Los scrapers provocan sin querer una carga a nivel de DDoS en sitios web pequeños
• Algunos operadores preguntaron cómo protegerse, pero este texto se enfoca en el “contraataque en lugar de la defensa”
• Tras ver el caso de otro desarrollador que engañaba bots generando datos falsos infinitos con cadenas de Markov, comenzó el experimento propio

Generador falso de PHP basado en cadenas de Markov

• Se implementó en Rust un entrenador de cadenas de Markov para generar contenido con apariencia realista a partir de datos de texto arbitrarios
• Apuntado a bots maliciosos que buscan rutas vulnerables como .env, .aws y .php, se les entrega código PHP falso que parece real pero no significa nada
• El tamaño de los archivos se amplió de 2 KB a 10 MB para forzar el desperdicio de recursos del bot
• La salida de ejemplo toma la forma de código PHP falso pero convincente, mezclando nombres de funciones de WordPress y comentarios
• El objetivo es hacer que el bot desperdicie tiempo y recursos, y que el atacante pierda tiempo intentando encontrar vulnerabilidades reales

Eficiencia y experimento con contenido estático

• Al servir archivos de más de 1 MB desde un VPS, aparecieron demoras en la respuesta y mayor carga del servidor
• Para resolverlo, se construyó un “garbage server” con forma de sitio estático
  • Se carga en memoria la novela completa Frankenstein y en cada solicitud se devuelven 4 párrafos aleatorios
  • Al final de cada página se agregan 5 enlaces para provocar una expansión explosiva del rastreo (crecimiento por 5)
• El resultado puede verse en https://herm.app/babbler/

Detalles del diseño y forma de operación

• La novela elegida es de dominio público, y se usó por haber trabajado en esto en temporada de Halloween y por la similitud entre la IA y Frankenstein
• A todas las páginas se les asignó noindex,nofollow para capturar solo a los bots que ignoran las reglas
• Al final de cada página se muestra un contador de número de solicitudes, que se reinicia al desplegarse por estar basado en memoria
• También se configuró un servidor separado para solicitudes .php, que entrega archivos PHP reales aleatorios desde memoria
• El proyecto se resume con la frase “Garbage for the garbage king!”

Riesgos y limitaciones

• Este sistema implica un riesgo de falsos positivos con motores de búsqueda si se aplica a un servicio real
  • Si Googlebot rastrea endpoints equivocados, podría clasificar el sitio como spam
  • Eso podría llevar a menor visibilidad en búsquedas o a que Chrome muestre advertencias
• Por eso, no se recomienda para sitios que dependen del tráfico de búsqueda y se opera solo como proyecto experimental
• El babbler para .php no es HTML, así que no afecta a Googlebot y apunta solo a bots maliciosos

Cierre y conclusión personal

• Se agregaron al blog enlaces ocultos (rel="nofollow") para atraer scrapers maliciosos
• Si se supera el límite de tráfico del VPS, se considera usar la caché de Cloudflare
• A través del proyecto, se aprendió sobre las cadenas de Markov y cómo funcionan los bots, en un experimento mezclado con diversión y frustración
• En conclusión, no todo intento tiene que ser práctico; a veces, hacerlo solo por diversión es suficiente

[GN⁺]

Opinión de Hacker News

• Aunque el mundo cambie, al final uno termina enfrentándose a problemas parecidos
  Hace 10~15 años yo estaba peleando con servicios de monitoreo de redes sociales. Grandes marcas les pagaban para monitorear el sentimiento en foros, y raspaban sin permiso la comunidad gratuita que yo administraba, causando carga en el servidor.
  Aunque bloqueaba sus bots, volvían cambiando la IP y el UA, así que hice un filtro que insertaba nombres de marcas al azar en las publicaciones para arruinar la calidad de sus datos. Después de activar esa medida, el scraping se detuvo por completo en solo dos días.

  • Yo tuve una experiencia parecida. Había bots que usaban el formulario de donaciones de mi sitio para probar tarjetas de crédito, e intentaban una y otra vez cambiando de IP. Así que, en vez de bloquearlos, empecé a devolver mensajes aleatorios de éxito o fallo; sus datos se contaminaron y se rindieron en pocos días.
  • La parte sobre analizar encabezados fue realmente útil. En mi servidor del Fediverse también detecté bots que usaban un UA de Chrome viejo y no enviaban ningún encabezado Accept-Language. Lo configuré en nginx para devolver 403 y el tráfico empezó a bajar.
  • Como en la película The Imitation Game, si respondes de inmediato a todas las solicitudes, el otro lado se da cuenta. Si solo procesas algunas o devuelves códigos de error aleatorios, se vuelve más difícil de detectar y también mucho más difícil para ellos depurar.
  • La mayoría de los bots todavía no logra imitar bien un conjunto de encabezados HTTP. Incluso en 2025 terminé filtrando de la misma manera, y los bots siguen evolucionando con los mismos patrones.
  • Me da curiosidad por qué al insertar nombres de empresas los bots desaparecieron. Quisiera preguntar si fue porque se contaminó la señal de los datos durante su proceso de búsqueda de menciones de marca.

• Estos bots no están analizando realmente archivos PHP, sino creando una huella digital para detectar vulnerabilidades (fingerprinting) según si existen o no. Solo miran el código de respuesta y los descartan de inmediato.

  • Exacto, en casos así herramientas como fail2ban o crowdsec son más efectivas. Cuando probé crowdsec me di cuenta de que incluso en servidores con poco tráfico hay una cantidad enorme de intentos de exploración de vulnerabilidades.
  • Entonces también podría servir una estrategia de exponer vulnerabilidades falsas a propósito para atraer a los bots. Por ejemplo, llevar bots automatizados a un honeypot (honeybot) para observar su comportamiento interno. Referencia: The Cuckoo’s Egg
  • Si los scrapers de LLM usan estas respuestas como datos de entrenamiento, el riesgo de envenenamiento de datos (poisoning) podría crecer mucho. Incluso artículos recientes dicen que se puede arruinar un modelo con solo unos pocos puntos de datos.

• Hace poco escuché hablar de tarpits para IA y scrapers. La idea es no cortar la conexión y en cambio enviar datos infinitos muy lentamente. Me pareció interesante una herramienta llamada Nepenthes y quiero experimentar con ella.

• Antes, en HN, si bloqueabas scrapers te criticaban. La lógica era: “no importa cómo acceda yo”.

  • Pero ahora es distinto. Una persona accediendo por su cuenta y una empresa de IA enviando solicitudes masivas a nivel de DDoS son cosas completamente diferentes. Lo segundo claramente consiste en pasarle el costo a otro.
  • Yo también creo que el scraping legítimo está bien. Basta con identificar el UA y respetar robots.txt. Pero enviar decenas de solicitudes por segundo mientras se hacen pasar por una versión vieja de Chrome es inaceptable.
  • Yo raspo sitios de empleo una vez al día para un proyecto académico. Eso es un uso razonable. En cambio, llevarse contenido cada pocos minutos o buscar vulnerabilidades es un problema totalmente distinto.
  • Lo más deprimente es que la llegada de la IA está debilitando la conciencia ética en sí misma. Personas que antes valoraban la libertad ahora piden reforzar el copyright o eliminar el anonimato. La tecnología está volviendo peor a la gente.

• Si administras directamente un servidor Apache, puedes bloquear de inmediato las solicitudes PHP con RewriteEngine

  RewriteEngine On
  RewriteCond %{REQUEST_URI} (\.php|%2ephp|%2e%70%68%70) [NC,OR]
  RewriteCond %{QUERY_STRING} \.php [NC,OR]
  RewriteCond %{THE_REQUEST} \.php [NC]
  RewriteRule .* - [F,L]
  

  En mi servidor no hay PHP, así que todas esas solicitudes son maliciosas.

  • En nginx hago algo parecido. A las solicitudes de PHP o ASPX les devuelvo el código HTTP 418 “I’m a teapot”

    location ~* \.(?:php|aspx?|jsp|dll|sql|bak)$ { return 418; }
    error_page 418 /418.html;
    

    Así es más fácil filtrar los logs. Ejemplo: FreeSolitaire.win/wp-login.php

• La mayoría de los scrapers agresivos apunta a vulnerabilidades de WordPress. Más que el archivo PHP en sí, quieren su resultado de salida. Este tipo de configuración se parece más a un honeypot, pero si el bot no ve lo que espera según su script, simplemente se va.

  • Probablemente buscan en la salida, con expresiones regulares, patrones de login de administrador. Si no los encuentran, saltan al siguiente objetivo. O sea, una sola línea de regex es mucho más eficiente que generar un PHP falso de 4 KB.

• Una vez publiqué en HN una estrategia de zipbomb y el tráfico explotó hasta 100 mil visitas en un día. Un VPS de $6 no podía aguantar eso. Ahora solo respondo con zipbomb a los bots más agresivos y al resto les doy 403. La nueva estrategia funciona bien, pero todavía dudo si volver a hacerla pública. Referencia: publicación anterior

• Antes solo usaba fail2ban, pero quería crear una defensa un poco más entretenida
  En .htaccess, redirijo rutas sospechosas (/.git, /wp-login) a decoy.php y fuerzo la descarga de un decoy.zip de 10 GB.
  decoy.php aparenta ser el archivo sensible solicitado, pero en realidad hace streaming infinito de logs falsos y datos SQL falsos para mantener ocupado al bot.

• Estos bots no están raspando archivos PHP, sino buscando vulnerabilidades de frameworks. Si les das una respuesta inesperada, abandonan de inmediato y pasan a otro objetivo.

• A veces pienso esto: ¿no sería posible hacer que con los recursos que desperdician los bots se mine criptomoneda?

  • Para intentarlo habría que inducir la ejecución de JavaScript, pero la mayoría de los bots probablemente ya tenga contramedidas para bloquear ese tipo de intentos.