Limiter le débit des robots d'indexation IA avec ModSecurity

Les bots d'entraînement à l'IA d'OpenAI, d'Anthropic, d'Amazon et d'une douzaine d'autres entreprises s'attaquent désormais aux serveurs web de production avec la même virulence qu'une attaque DDoS, et le fichier robots.txt ne parvient pas à les arrêter. Ce guide explique comment l'équipe système d'InMotion utilise ModSecurity pour appliquer une limitation de débit par bot au niveau du serveur, sans pour autant bloquer complètement l'indexation de ton site.

Table des matières

Le problème : des bots IA qui ne respectent pas les règles

robots.txt c'est l'accord tacite qui existe depuis des décennies entre les sites web et les robots d'indexation. Une directive comme Crawl-delay: 10 demande aux robots conformes d'attendre 10 secondes entre chaque requête. Google te permet de configurer la fréquence d'exploration via Google Search Console. Les robots d'indexation traditionnels fonctionnent depuis si longtemps dans ce cadre que la plupart des administrateurs système n'y ont jamais vraiment prêté attention.

Les robots d'apprentissage du LLM, c'est une autre histoire.

À partir de 2024, les équipes d'administration système d'InMotion ont commencé à constater une tendance à un trafic anormalement intense sur l'infrastructure partagée et dédiée. La source n'était pas un seul bot qui se déchaînait. Il s'agissait de plusieurs bots, chacun géré par une entreprise d'IA différente, qui exploraient simultanément les mêmes serveurs sans aucun délai entre les requêtes et sans tenir compte de Crawl-delay directives. Aucune d'entre elles ne se coordonnait avec les autres. Elles n'en avaient d'ailleurs pas besoin. La charge combinée de GPTBot, ClaudeBot, Amazonbot et de leurs homologues, qui sollicitent simultanément le même serveur, entraîne un épuisement des ressources qui, sur le plan fonctionnel, ressemble à s'y méprendre à une attaque par déni de service distribué involontaire.

Ça en surprend plus d'un parmi les propriétaires de sites web, qui pensent que le fichier robots.txt est contraignant. Ce n'est pas le cas. C'est une convention, et ces robots ne la respectent pas.

Deux options, un compromis évident

La solution radicale consiste à bloquer complètement l'accès via le fichier .htaccess. Tu peux refuser l'accès en fonction de l'User-Agent, et les robots cesseront complètement de solliciter ton serveur. Problème résolu, sauf que ce n'est pas le cas : ton site disparaît également des systèmes de découverte basés sur l'IA. Pour les entreprises qui souhaitent apparaître dans les réponses générées par l'IA ou dans les fonctionnalités de recherche alimentées par des modèles de langage (LLM), bloquer complètement les robots d'indexation a un coût réel à long terme.

La limitation de débit est la meilleure solution. Tu ralentis les robots à un rythme que ton serveur peut supporter. Ils continuent d'indexer ton contenu. Tu conserves ta visibilité. Et lorsqu'un robot refuse de respecter la limite de débit que tu as définie, tu bloques cette requête spécifique plutôt que le robot de manière définitive.

Comment fonctionne la limitation de débit de ModSecurity

ModSecurity est un pare-feu d'applications Web open source qui fonctionne au sein d'Apache ou Nginx et analyse le trafic HTTP en temps réel. C'est ce même outil qui bloque les tentatives d'injection SQL et les attaques de type « cross-site scripting » sur les serveurs correctement sécurisés. Ce qui le rend utile ici, c'est sa capacité à suivre la fréquence des requêtes par User-Agent et à rejeter celles qui dépassent un seuil défini.

Cette méthode se déroule en deux étapes :

Identifie la requête entrante en User-Agent chaîne de caractères et incrémenter un compteur par hôte.
Si ce compteur dépasse la limite autorisée avant son expiration, refuse la requête avec un 429 Too Many Requests répondre et définir un Retry-After en-tête.

Ça Retry-After L'en-tête est important. Il indique clairement au robot combien de temps il doit attendre avant d'envoyer sa prochaine requête. Un robot bien élevé respectera cette consigne. Celui qui ne le fait pas sera bloqué lors de sa prochaine tentative.

Les règles ModSecurity

Voici les règles de limitation de débit que l'équipe technique InMotion Hostinga mises au point et utilise actuellement. Chaque ensemble de règles cible un bot spécifique en User-Agent et limite le nombre de requêtes à une par 3 secondes par nom d'hôte.

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"

# 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 (Anthropique)

# 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"

# 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"

# 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"

Adapter les règles pour d'autres bots

La structure est la même pour tous les bots. Pour ajouter la couverture d'un nouveau robot d'indexation, copie n'importe quel ensemble de règles et apporte deux modifications :

Remplace le User-Agent chaîne (par exemple, GPTBot) avec l'identifiant du nouveau bot.
Attribuer un identifiant unique id des valeurs et une personnalité unique env des noms de variables pour éviter les conflits avec les règles existantes.

Le id Ce champ doit être unique dans toute ta configuration ModSecurity. Si tu les ajoutes à un ensemble de règles existant, vérifie quels identifiants sont déjà utilisés avant d'en attribuer de nouveaux. Les conflits entraînent l'échec silencieux des règles.

À titre indicatif, voici une liste de plus en plus longue de chaînes User-Agent connues utilisées par les robots d'indexation basés sur l'IA : Bytespider, CCBot, Google-Extended, Meta-ExternalAgentet PerplexityBot, entre autres. Le Le projet Dark Visitors tient à jour un catalogue assez récent des identifiants d'agents IA connus.

Que se passe-t-il après le déploiement ?

Une fois ces règles activées, un bot qui envoie deux requêtes au même nom d'hôte en l'espace de 3 secondes reçoit un 429 à la deuxième demande. Le Retry-After: 3 L'en-tête lui indique d'attendre avant de réessayer.

À partir de là, les comportements se divisent en deux catégories :

Les robots qui respectent l'en-tête ralentissent automatiquement. Ils continuent d'indexer ton contenu à un rythme que ton serveur peut supporter. Les ressources sont préservées, et ton site reste accessible aux robots d'indexation qui comptent vraiment.

Les bots qui ignorent l'en-tête continuent de se heurter à la règle de refus à chaque requête suivante, jusqu'à ce que leur logique interne de réessai se déclenche ou qu'ils passent à autre chose. Dans tous les cas, ils consomment une fraction des ressources qu'ils auraient utilisées sans limitation de débit.

Tu ne résoudras pas le problème de fond posé par les entreprises d'IA qui déploient des robots d'indexation agressifs sans autorisation. Mais tu ne supportes plus le coût de leurs opérations d'indexation sur ton matériel.

Conditions préalables et champ d'application de ces règles

Ces règles nécessitent que ModSecurity soit installé et activé sur ton serveur. Sur les serveursInMotion Hosting et les offres VPS InMotion Hosting , ModSecurity est accessible via l'interface WHM cPanel, dans la section « Security Center » > « ModSecurity ». Les règles peuvent être ajoutées en tant que règles personnalisées via WHM ou directement dans le répertoire de configuration ModSecurity de ton serveur.

Si tu utilises un serveur dédié géré, l'équipe d'assistance produit avancée InMotion Hostingpeut t'aider à déployer des règles ModSecurity personnalisées. Les clients bénéficiant du forfait Premier Care ont accès à InMotion Solutions, spécialement conçu pour ce type de configuration personnalisée des serveurs.

Les environnements d'hébergement mutualisé ne prennent pas en charge les règles ModSecurity personnalisées au niveau du compte. Si le trafic intense généré par les bots pose problème sur un hébergement mutualisé, les options se limitent à des blocages via .htaccess ou à la migration vers un serveur VPS ou dédié, où tu bénéficieras d'une configurabilité totale du WAF.

Une note sur le fichier robots.txt

Tout cela ne remplace en rien un fichier robots.txt bien structuré. Il reste utile de maintenir les directives de délai d'exploration pour les robots conformes, et le fait de répertorier explicitement les robots d'exploration basés sur l'IA que tu souhaites restreindre apporte une indication claire de ton intention, même si certains robots l'ignorent. Les règles ModSecurity se chargent de faire respecter ces restrictions pour ceux qui ne s'autorégulent pas.

Un fichier robots.txt pour les robots qui respectent les conventions ; une limitation de débit via ModSecurity pour ceux qui ne les respectent pas. Ces deux niveaux fonctionnent de concert.

Résumé

Les robots d'entraînement à l'IA ne respectent pas le fichier robots.txt comme le font les robots de recherche traditionnels, et la charge combinée de plusieurs opérations d'indexation simultanées peut nuire aux performances du serveur pour le trafic légitime. La limitation de débit basée sur l'User-Agent de ModSecurity te permet de contrôler côté serveur la fréquence à laquelle ces robots peuvent demander des ressources, sans que tu aies à les empêcher complètement d'indexer ton site.

Ces règles sont faciles à mettre en place, s'appliquent à n'importe quel bot en copiant le modèle et fournissent une signalisation claire via Retry-After des en-têtes pour les robots d'indexation capables de les prendre en compte.

Si tu constates des pics inexpliqués de charge du serveur ou de volume de requêtes HTTP qui ne correspondent pas au trafic réel des utilisateurs, vérifie dans tes journaux d'accès si des agents utilisateur de robots d'indexation IA y figurent avant de conclure qu'il s'agit d'un problème plus complexe.

Partager cet article