Limitar la frecuencia de los bots de rastreo de IA con ModSecurity

Limitar la frecuencia de los bots de rastreo de IA con ModSecurity: cómo lo hicimos

Los bots de entrenamiento de IA de OpenAI, Anthropic, Amazon y una docena de empresas más están saturando ahora los servidores web de producción con la misma intensidad que un ataque DDoS, y el archivo robots.txt no los detiene. En esta guía te explicamos cómo el equipo de sistemas de InMotion utiliza ModSecurity para aplicar una limitación de velocidad por bot a nivel de servidor, sin bloquear por completo la indexación de tu sitio web.

El problema: los bots de IA que no respetan las reglas

robots.txt ha sido el acuerdo de facto entre los sitios web y los rastreadores web durante décadas. Una directiva como Crawl-delay: 10 indica a los bots que cumplan las normas que esperen 10 segundos entre cada solicitud. Google te ofrece una forma de configurar la frecuencia de rastreo a través de Google Search Console. Los rastreadores de búsqueda tradicionales llevan tanto tiempo funcionando dentro de estos límites que la mayoría de los administradores de sistemas nunca se han parado a pensar en ellos.

Los rastreadores de entrenamiento de modelos LLM son otra historia.

A partir de 2024, los equipos de administración de sistemas de InMotion empezaron a detectar un patrón de tráfico inusualmente intenso en la infraestructura compartida y dedicada. La causa no era un único bot fuera de control, sino varios bots, cada uno gestionado por una empresa de IA diferente, que rastreaban simultáneamente los mismos servidores sin ningún retraso entre las solicitudes y sin respetar Crawl-delay instrucciones. Ninguna de ellas se coordinaba con las demás. Tampoco era necesario. La carga combinada de GPTBot, ClaudeBot, Amazonbot y sus homólogos, al acceder al mismo servidor al mismo tiempo, provoca un agotamiento de recursos que, en la práctica, resulta idéntico a un ataque distribuido de denegación de servicio no intencionado.

Esto sorprende a muchos propietarios de sitios web, que dan por hecho que el archivo robots.txt es vinculante. Pero no lo es. Se trata de una convención, y estos bots no la respetan.

Dos opciones, una clara disyuntiva

El método más radical es bloquearlo todo mediante un archivo .htaccess. Puedes denegar el acceso por User-Agent y los bots dejarán de acceder a tu servidor por completo. Problema resuelto, o eso parece: tu sitio web también desaparece de los sistemas de descubrimiento basados en IA. Para las empresas que quieren aparecer en las respuestas generadas por IA o en las funciones de búsqueda basadas en modelos de lenguaje grande (LLM), bloquear por completo a los rastreadores de entrenamiento conlleva un coste real a largo plazo.

Limitar la frecuencia es la mejor opción. Haces que los bots reduzcan su velocidad hasta un ritmo que tu servidor pueda soportar. Siguen indexando tu contenido. Sigues manteniendo la visibilidad. Y cuando un bot se niega a respetar el límite de frecuencia que has establecido, bloqueas esa solicitud concreta en lugar de bloquear al bot de forma permanente.

Cómo funciona la limitación de velocidad de ModSecurity

ModSecurity es un cortafuegos de aplicaciones web de código abierto que funciona dentro de Apache o Nginx, inspeccionando el tráfico HTTP en tiempo real. Es la misma herramienta que bloquea los intentos de inyección SQL y los ataques de scripts entre sitios en servidores debidamente protegidos. Lo que lo hace útil en este caso es su capacidad para rastrear la frecuencia de las solicitudes por User-Agent y rechazar aquellas que superen un umbral definido.

El método funciona en dos pasos:

  • Identifica la solicitud entrante mediante User-Agent una cadena e incrementa un contador por host.
  • Si ese contador supera el límite permitido antes de que caduque, rechaza la solicitud con un 429 Too Many Requests respuesta y configura un Retry-After encabezado.

Eso Retry-After El encabezado es importante. Le indica explícitamente al bot cuánto tiempo debe esperar antes de realizar su siguiente solicitud. Un rastreador que se comporte correctamente lo respetará. El que no lo haga, será bloqueado en su siguiente intento.

Las reglas de ModSecurity

A continuación te mostramos las reglas de limitación de velocidad que el equipo de sistemas InMotion Hostingha desarrollado y utiliza actualmente. Cada conjunto de reglas se dirige a un bot específico mediante User-Agent y limita a una solicitud cada 3 segundos por nombre de host.

GPTBot (OpenAI)

# Limit GPTBot hits by user agent to one hit per 3 seconds
SecRule REQUEST_HEADERS:User-Agent "@pm GPTBot" \
    "id:13075,phase:2,nolog,pass,\
    setuid:%{request_headers.host},\
    setvar:user.ratelimit_gptbot=+1,\
    expirevar:user.ratelimit_gptbot=3"

SecRule USER:RATELIMIT_GPTBOT "@gt 1" \
    "chain,id:13076,phase:2,deny,status:429,\
    setenv:RATELIMITED_GPTBOT,\
    log,msg:'RATELIMITED GPTBOT'"
    SecRule REQUEST_HEADERS:User-Agent "@pm GPTBot"

Header always set Retry-After "3" env=RATELIMITED_GPTBOT
ErrorDocument 429 "Too Many Requests"

ClaudeBot (Antrópico)

# Limit ClaudeBot hits by user agent to one hit per 3 seconds
SecRule REQUEST_HEADERS:User-Agent "@pm ClaudeBot" \
    "id:13077,phase:2,nolog,pass,\
    setuid:%{request_headers.host},\
    setvar:user.ratelimit_claudebot=+1,\
    expirevar:user.ratelimit_claudebot=3"

SecRule USER:RATELIMIT_CLAUDEBOT "@gt 1" \
    "chain,id:13078,phase:2,deny,status:429,\
    setenv:RATELIMITED_CLAUDEBOT,\
    log,msg:'RATELIMITED CLAUDEBOT'"
    SecRule REQUEST_HEADERS:User-Agent "@pm ClaudeBot"

Header always set Retry-After "3" env=RATELIMITED_CLAUDEBOT
ErrorDocument 429 "Too Many Requests"

Amazonbot

# Limit Amazonbot hits by user agent to one hit per 3 seconds
SecRule REQUEST_HEADERS:User-Agent "@pm Amazonbot" \
    "id:13079,phase:2,nolog,pass,\
    setuid:%{request_headers.host},\
    setvar:user.ratelimit_amazonbot=+1,\
    expirevar:user.ratelimit_amazonbot=3"

SecRule USER:RATELIMIT_AMAZONBOT "@gt 1" \
    "chain,id:13080,phase:2,deny,status:429,\
    setenv:RATELIMITED_AMAZONBOT,\
    log,msg:'RATELIMITED AMAZONBOT'"
    SecRule REQUEST_HEADERS:User-Agent "@pm Amazonbot"

Header always set Retry-After "3" env=RATELIMITED_AMAZONBOT
ErrorDocument 429 "Too Many Requests"

Adaptar las reglas para otros bots

La estructura es la misma para todos los bots. Para añadir cobertura para un nuevo rastreador, copia cualquier conjunto de reglas y realiza dos cambios:

  • Sustituye el User-Agent cadena (p. ej., GPTBot) con el identificador del nuevo bot.
  • Asigna un nombre único id valores y únicos env nombres de variables para evitar conflictos con reglas ya existentes.

En id El campo debe ser único en toda tu configuración de ModSecurity. Si los añades a un conjunto de reglas ya existente, comprueba qué ID ya están en uso antes de asignar otros nuevos. Las colisiones hacen que las reglas fallen sin avisar.

A modo de referencia, aquí tienes una lista cada vez más amplia de cadenas de User-Agent de rastreadores de IA conocidas: Bytespider, CCBot, Google-Extended, Meta-ExternalAgenty PerplexityBot, entre otros. El Proyecto «Dark Visitors» mantiene un catálogo bastante actualizado de los identificadores conocidos de agentes de IA.

¿Qué pasa después de la implementación?

Una vez que estas reglas estén activas, un bot que realice dos solicitudes al mismo nombre de host en un intervalo de 3 segundos recibirá un 429 en la segunda solicitud. El Retry-After: 3 El encabezado le indica que espere antes de volver a intentarlo.

A partir de ahí, el comportamiento se divide en dos categorías:

Los bots que respetan el encabezado reducen automáticamente su velocidad. Siguen indexando tu contenido a un ritmo que tu servidor puede soportar. Se ahorran recursos y tu sitio sigue siendo accesible para los rastreadores que realmente importan.

Los bots que ignoran el encabezado siguen topándose con la regla de denegación en cada solicitud posterior hasta que se activa su lógica interna de reintentos o pasan a otra cosa. En cualquier caso, consumen una fracción de los recursos que consumirían si no hubiera una limitación de velocidad.

No vas a resolver el problema de fondo de que las empresas de IA utilicen rastreadores agresivos sin consentimiento. Pero sí que dejarás de asumir el coste de sus operaciones de indexación en tu hardware.

Requisitos previos y dónde se aplican estas normas

Estas reglas requieren que ModSecurity esté instalado y activado en tu servidor. En los servidoresInMotion Hosting y los planes VPS InMotion Hosting , ModSecurity está disponible a través de la interfaz WHM cPanel, en «Security Center» > «ModSecurity». Las reglas se pueden añadir como reglas personalizadas a través de WHM o directamente en el directorio de configuración de ModSecurity de tu servidor.

Si tienes un servidor dedicado gestionado, el equipo de asistencia técnica avanzada InMotion Hostingpuede ayudarte a implementar reglas personalizadas de ModSecurity. Los clientes con Premier Care tienen acceso a InMotion Solutions precisamente para este tipo de tareas de configuración personalizada del servidor.

Los entornos de alojamiento compartido no admiten reglas personalizadas de ModSecurity a nivel de cuenta. Si el tráfico agresivo de bots supone un problema en el alojamiento compartido, las opciones se limitan a bloqueos mediante .htaccess o a pasar a un servidor VPS o dedicado, donde tendrás total libertad para configurar el WAF.

Una nota sobre el archivo robots.txt

Nada de esto sustituye a un archivo robots.txt bien estructurado. Sigue mereciendo la pena mantener las directivas de retraso en el rastreo para los bots que cumplen las normas, y enumerar explícitamente los rastreadores de IA a los que quieres restringir el acceso añade una señal documentada de tu intención, aunque algunos bots la ignoren. Las reglas de ModSecurity se encargan de hacer cumplir las normas a aquellos que no se autorregulan.

Un archivo robots.txt para los bots que respetan las normas; y la limitación de tráfico de ModSecurity para los que no lo hacen. Ambas medidas funcionan en conjunto.

Resumen

Los rastreadores de entrenamiento de IA no respetan el archivo robots.txt como lo hacen los bots de búsqueda tradicionales, y la carga combinada de múltiples operaciones de indexación simultáneas puede reducir el rendimiento del servidor para el tráfico legítimo. La limitación de frecuencia basada en el User-Agent de ModSecurity te permite controlar desde el servidor la frecuencia con la que estos bots pueden solicitar recursos, sin que tengas que impedirles por completo que indexen tu sitio.

Las reglas son fáciles de implementar, se pueden aplicar a cualquier bot copiando la plantilla y proporcionan una señalización clara a través de Retry-After encabezados para los rastreadores que sean capaces de respetarlos.

Si observas picos inexplicables en la carga del servidor o en el volumen de solicitudes HTTP que no se corresponden con el tráfico real de usuarios, revisa tus registros de acceso en busca de User-Agents de rastreadores de IA antes de dar por hecho que te enfrentas a algo más complejo.

Comparte este artículo

Deja una respuesta

Tu dirección de correo electrónico no se publicará. Los campos obligatorios están marcados con *.