Usando una colección de pequeñas herramientas para bloquear bots

• El rastreo y scraping indiscriminado por parte de grandes empresas de IA/búsqueda ha afectado gravemente a servidores y servicios personales, provocando de forma constante consumo de recursos e inestabilidad del servicio
• Tras detectar tráfico anómalo con monitoreo basado en Zabbix y Loki, se usaron herramientas de análisis de logs (lnav, goaccess) y consultas basadas en SQL para identificar en detalle patrones de atacantes, IP y User Agent
• Se construyó una defensa por capas con configuración de Nginx, como bloqueos 403 basados en User Agent, rate limit e integración con Fail2Ban, logrando bloquear cientos de IP maliciosas y estabilizar el servidor
• El principal problema eran bots que intentaban descargar masivamente todo el repositorio de Gitea como tarball, y aumentó con fuerza el tráfico con fines de recolección de datos para IA/entrenamiento de modelos, no de simples consumidores de contenido
• A largo plazo, se está considerando una estrategia de excepciones para servicios legítimos (como archive.org) y de mantener la visibilidad en buscadores, pero resistiendo la enshitificación de la IA

---

Introducción: tráfico de bots desbordado en mi pequeño servidor

• Recientemente aumentó de forma abrupta una gran cantidad de tráfico de origen desconocido hacia el blog lambdacreate y varios otros servicios operados personalmente
• Servicios legítimos como Archive.org son bienvenidos, pero el rastreo indiscriminado de datos por parte de grandes empresas como Amazon, Facebook y OpenAI daña el sitio
• A medida que aumenta la demanda de recolección de datos para entrenamiento de modelos de IA, este fenómeno se vuelve aún más grave
• En esta situación, en vez de lectores reales (personas), lo que predomina es el asedio de grandes volúmenes de tráfico automatizado

Confirmación del problema: diagnóstico del pico de tráfico con herramientas de monitoreo

• Se analizaron las condiciones de consumo de recursos del servidor usando herramientas de monitoreo como Zabbix y Loki
• La instancia de Gitea mostró un aumento de 20~30 GB de datos por día, además de varias alertas de CPU y memoria
• El análisis del tráfico de nginx mostró un salto del promedio mensual de 8 req/s a picos de más de 20 req/s
• Aunque el volumen no era masivo en términos absolutos, era casi 10 veces superior a lo habitual y provocaba agotamiento de recursos

Análisis de la causa del ataque: revisión profunda de archivos de log

• Se analizaron con SQL los logs de acceso de nginx usando lnav y goaccess
  • Se identificaron patrones como IP de visitantes, UserAgent y Referrer
• Como resultado, no se trataba de tráfico proveniente de un servicio o comunidad específicos, sino de rastreo masivo desde ciertos rangos de IP
• Se encontraron muchos valores explícitos o falsificados en el UserAgent, como Amazonbot, OpenAI, Applebot y Facebook
• Como esto afectó el uso real del servicio, surgió la necesidad de aplicar una política de bloqueo más fuerte

Solución: aplicación combinada de varias capas de defensa con Nginx, Fail2Ban y más

• Usando Nginx map, se devolvía 403 de inmediato a User Agent maliciosos y se introdujo rate limit (limitación de velocidad de acceso)
• Incluso para bots nuevos o no detectados, se redujo la frecuencia de solicitudes web para minimizar la carga del servidor
• Con base en los logs de respuestas 403, se detectaron nuevas IP y UserAgent maliciosos con goaccess y lnav
• Mediante la herramienta de seguridad automatizada Fail2Ban, se bloquearon automáticamente por 24 horas las IP que generaban demasiadas respuestas 403
  • Más de 735 bloqueos automáticos registrados
• El uso real de recursos volvió en gran medida a la normalidad
• En adelante, se planea aplicar reglas de excepción para servicios legítimos como archive.org, permitir la indexación en buscadores, pero seguir bloqueando el rastreo indiscriminado para entrenamiento de IA

Conclusión: la fuerza de combinar herramientas y la necesidad de seguridad en servicios personales

• Al aplicar esta serie de medidas de defensa multicapa, se recuperó una operación fluida del blog personal y la accesibilidad del servicio
• Se confirmó que el uso de múltiples pequeñas herramientas de administración y automatización es eficaz para la seguridad de servidores personales
• En un entorno donde el creciente apetito por el entrenamiento de IA lleva a rastrear indiscriminadamente incluso servidores personales, bloquear activamente y automatizar la gestión se vuelve indispensable

[GN⁺]

Opinión de Hacker News

• A menudo veo que muchos rastreadores poco éticos solo fingen ser grandes motores de búsqueda; hay quienes dicen que no hay que dejarse engañar por la información del user agent, pero mi método favorito es poner información sospechosa en robots.txt (por ejemplo, una gzip bomb) y configurar que cualquier crawler que la detecte quede bloqueado a partir de la siguiente solicitud. Se puede implementar fácilmente con Caddy, y así normalmente se atrapa a los infractores más graves. No pretendo justificar el comportamiento de los bots, pero si unos cuantos bots de estos pueden tumbar tu sitio, eso demuestra que tu sitio es realmente vulnerable a un atacante malicioso.

  • Siento que el último comentario dio exactamente en el clavo. Tal vez soy de otra generación, pero no entiendo por qué quienes escriben hoy están tan obsesionados con usar tan pocos recursos. Es como cuando los abuelos hacen escándalo por apagar focos LED o manejan 24 km para ahorrarse 5 centavos de combustible. 20 solicitudes por segundo no son absolutamente nada; incluso si el contenido se genera dinámicamente (¿para qué hacerlo? con ese tiempo sale mucho más a cuenta configurar caché), esta ola de artículos estilo "fuck the bots" está de moda, pero no es un tema nuevo. Hay muchas maneras más productivas de manejarlo sin perder tiempo.

  • Me gustaría escuchar más detalles sobre cómo hacer lo de la gzip bomb en robots.txt. Según entiendo, la mayoría de las IA ignoran robots.txt, así que me pregunto si al final eso solo atrapa a algunos crawlers ingenuos. No lo digo por contradecir a nadie, solo quiero saber más sobre cómo implementarlo sin afectar a los que sí actúan de buena fe.

  • Administro una de las wikis más grandes de mi área, y convencer al resto del equipo de desarrollo para usar una gzip bomb es casi imposible. Insisten en que este método tiene demasiado riesgo (con la mentalidad de que podría meternos en problemas por regulaciones de la UE) y que no vale la pena impulsarlo. Me pregunto si alguien realmente usa esto en sitios públicos.

• Últimamente me enfurece que los bots ya no respeten para nada el archivo robots.txt; me parece que la gente que creó esto es realmente egoísta. Si hicieron ese tipo de bots, pues que se las arreglen solos.

  • Si pones trampas (honeypots) en el archivo robots, aunque no atrapes a los que lo ignoran por completo, sí ayuda a filtrar bots que vienen a causar problemas a propósito.

  • También podrías decir algo parecido de la gente que usa chatbots, motores de búsqueda o comparadores de precios. En realidad, esos usuarios son quienes económicamente incentivan a los scrapers.

• Entiendo que el autor diga que “ya no le importa”, pero vi que entre las IP prohibidas estaban Google, ripe.net y semrush. De otras empresas no sé, pero yo de verdad no bloquearía a Google. Si quieres dar a conocer tu sitio, tampoco creo que haya necesidad de bloquear a Semrush o ripe.net. Aunque mi contenido termine siendo scrapeado por IA o por cualquier raro, si el sitio es público desde el inicio, creo que uno debe asumir que se va a usar hasta cierto punto; sería como invitar clientes a un motel con el letrero apagado.

  • Semrush lleva mucho tiempo siendo una molestia realmente grave en varios niveles, tanto que durante los últimos 8 años hasta dejé mensajes poco comunes en robots.txt. Al final tuve que involucrar incluso al equipo legal para que por fin se calmaran. Desde mi punto de vista, no tiene valor permitir que una empresa de “SEO” raspe agresivamente el sitio mientras desplaza a visitantes reales. Los competidores de Semrush también eran igual de problemáticos. Los scrapers de IA actuales también son de un nivel bajísimo; alguna vez incluso tuve que enviar repetidamente quejas formales a grandes inversionistas y departamentos de PR. Tanto técnica como legalmente, apenas así logré volver las cosas a la normalidad.

  • El problema real es que los bots consumen tráfico a gran escala (ancho de banda, memoria, CPU, recursos de disco). En la introducción también se menciona como una falta de modales difícil de justificar. Siento que no hay por qué regalarle ese tráfico a los scrapers. Google también opera scrapers de IA, así que supongo que tal vez por eso terminó en la lista de bloqueados.

  • También existen bots realmente maliciosos que se hacen pasar por Google. Antes Google scrapeaba de una manera relativamente educada, pero si el autor ya está obteniendo el tráfico que necesita, lo bloquee o no, entonces no tendría por qué importarle.

  • Me pregunto si en estos últimos 10 años la gente todavía no se había dado cuenta de que no debería usar Google, especialmente ahora que está apareciendo esta situación donde Google censura sitios independientes con IA; hasta enlazo directamente un comentario relacionado. A estas alturas, Google me parece más un riesgo que un activo.

• Los bots han hecho que los archivos de log del servidor crezcan demasiado, al grado de que mis servidores terminaron con el logging desactivado por completo. Los bots raspan obstinadamente APIs, formularios e incluso partes del sitio a las que solo se puede entrar haciendo clic en la web. Anthropic, openAI, Facebook y otros siguen scrapeando mi sitio.

  • Si se trata de APIs a las que solo se puede acceder haciendo clic, me pregunto cómo logran entrar los bots.

  • Me gustaría saber más sobre esas APIs, para aclarar si te refieres a algo que es parte de la UI o que solo un humano debería usar, o si de verdad no existe ninguna otra ruta de acceso. Últimamente los agentes de IA imitan patrones de comportamiento de usuarios reales, así que ya estamos en una época donde distinguir entre humanos y bots es casi imposible.

• Pensé que era bueno que los bots crawler de IA llenaran honestamente el header User-Agent, pero me sorprendió un poco que eso fuera la causa de tanto tráfico. La mayoría de los sitios web no necesitan datos con tanta frecuencia, y aun así el tráfico es excesivo. Si es un blog de desarrollador, menos todavía lo entiendo.

  • La mayoría de los crawlers de IA sí cumplen robots.txt, pero cuando los bloquean o los frenan, hay casos en los que enseguida cambian a un user agent de navegador y vuelven a intentar el crawling desde IP residenciales. Aun así, como hay tantísimos que falsifican ser OpenAI/Amazon/Facebook, hay que tener mucho cuidado al distinguir los casos reales.

• Soy el creador de tirreno. Nuestra plataforma está optimizada para usuarios conectados en vivo, pero también sirve de forma efectiva para detectar y bloquear bots. Usamos un método de anonimización de IP que reemplaza el último octeto con un asterisco (*) para agrupar la misma subred como una sola cuenta. Se pueden generar listas negras automáticas para anomalías de tráfico (errores 500/404, intentos de login por fuerza bruta, IPs de centros de datos, etc.). Con la API de blacklist de tirreno se puede redirigir tráfico no deseado a una página de error. También ofrece un panel de monitoreo que ayuda a evitar falsos positivos y facilita la gestión.
  tirreno Github, demo de administrador

  • Últimamente muchos ISP están pasando a estructuras CGNAT, así que me pregunto cómo manejan el problema de que una sola IP pueda representar a cientos de usuarios reales.

  • También estoy desarrollando bloqueo de bots basado en rangos de IP públicos. Si tienen ideas para mejorarlo, siempre son bienvenidas.

  • Con ese sistema de reemplazar el último octeto de la IP, terminas agrupándome como un solo usuario junto con vecinos de direcciones que no tienen absolutamente nada que ver conmigo. Tampoco se pueden ignorar los falsos positivos por IPs de centros. En la práctica, si algo no está bloqueado, tengo que pasar apenas por poco después de hacer clic en 87 semáforos. Al final, parece más una excusa para decir que no recopilan mis datos personales sin consentimiento incluso durante la fase para evitar falsos positivos. Ojalá incluyan una estructura de retroalimentación que haga evidente de inmediato al cliente que en realidad está perdiendo usuarios que pagan.

• Hay algo que me he preguntado desde hace tiempo: si no sería posible una estructura de “page knocking”, es decir, abrir páginas en un orden específico para obtener permiso de entrada. Por ejemplo, que primero haya que acceder a cierta URL privada designada para que el resto de las páginas se abran normalmente en vez de devolver 404.

  • Esa arquitectura no encaja con los casos donde los usuarios comunes deben poder encontrar el proyecto desde un motor de búsqueda y empezar a usarlo de inmediato, sin crear cuenta ni pasar por autenticación adicional.

  • En términos de usabilidad, por bien que se diseñe, inevitablemente va a causar molestias. Si usas marcadores o le envías un link a un amigo, es de esperarse que solo vean 404 todo el tiempo.

• Mi pequeño servidor ha estado funcionando bien, así que últimamente no había revisado el estado de fail2ban.
  Comparación del resultado del comando:

  sshd-ddos:      0
  postfix:       583
  dovecot:     9690
  postfix-sasl: 4227
  nginx-botsearch: 1421
  nginx-http-auth: 0
  postfix-botnet:  5425
  sshd:         202157
  

Me impactó un poco descubrir que había más de 220,000 IP bloqueadas.

• Un bot que rastreamos, llamado 'DotBot/1.2', dejó más de 220 mil solicitudes en las últimas dos semanas. Su patrón consiste en pedir aleatoriamente nombres de archivos y carpetas del servidor web. Por curiosidad, lo estoy observando sin bloquearlo para ver hasta dónde llega.

• Me pregunto si la estructura centralizada de indexación para IA o motores de búsqueda ya no debería cambiar a un modelo de push o envío, donde yo solo comparta directamente cuando quiera; creo que eso reduciría mucho el problema del scraping.

• Cuando yo era niño en los 90, una vez mi ISP me llamó para avisarme que mi computadora estaba metida en una botnet y que me cortarían el acceso a internet. Me pregunto si no deberíamos volver a una época así y simplemente bloquear el ASN completo de los ISP que permiten ese comportamiento para terminar también con este problema.

  • Los proxies residenciales no los ofrece directamente el ISP; surgen porque usuarios de todo el mundo instalan malware de forma intencional o sin darse cuenta y terminan prestando sus computadoras como proxy. Hace poco salió en HN un buen artículo sobre esto.

  • En mi red configuré una regla de firewall para mostrar una alerta cada vez que un dispositivo intenta hacer una conexión saliente a un puerto asociado con malware. La lista de puertos necesita actualizarse periódicamente porque los objetivos del malware van cambiando; es un método pequeño, pero también es otra capa de defensa.