Comment protéger vos serveurs et lutter efficacement contre les crawlers d’IA

L’émergence des LLM n’a pas juste apporté l’IA Slops et les dissertations trop verbeuses, elle s’accompagne aussi de la multiplication des robots d’indexation qui viennent analyser les contenus de vos applications web.

Il peut arriver que les ressources des serveurs saturent car les robots se montrent très insistants en parcourant l’arborescence de votre site. Les robots d’analyse (crawler) fonctionnent sur la base de grosses infrastructures, ils arrivent en masse sur votre application et cela peut provoquer un DoS du serveur du fait du volume de trafic généré.

Dans cet article nous vous proposons un tour d’horizon des différents moyens de protections, de leurs avantages et inconvénients.

Interdiction totale ou partielle

• Robots.txt : La mise en place d’un fichier “robots.txt” à la racine de votre site web est la solution la plus simple. Des directives ont été ajoutées aux spécifications pour contrôler l’accès aux robots d’entraînement de modèles de langage, mais c’est selon la volonté des robots qui peuvent passer outre.
• Filtrage des agents / IP : Il est possible de renforcer ces règles en interdisant tout bonnement l’accès à tout ou partie de votre application en configurant le serveur directement avec des règles de filtrage des User-Agents et/ou de la plage d’adresses IP utilisés par les robots. Il existe des bases de données (par exemple, celle de agents collectée par Badbot, ou les IPs de Uptimerobot).
• Il faut maintenir ces listes à jour en permanence, et surtout, ces solutions sont restrictives, et peuvent causer des trous dans votre référencement (SEO). L’outil Darkvisitor fournit une API et un module Wordpress pour générer un fichier robots.txt actualisé en continu, ainsi que des logs sur l’activité des robots sur votre serveur.
• À noter, Cloudflare maintient une liste de bots “officiels” et catégorisés. Ce qui peut être utile pour faire du whitelisting (autoriser le bot de Google par exemple, ou Qualys) et du blacklisting (refuser les LLM “officiels”).

Autoriser un peu, en limitant

Les robots utilisent de grosses infrastructures et il est compliqué de faire le filtrage vous même, car les plages d’adresse IP sont vastes, et changent continuellement.

• Mitigation locale : rate-limiting :
  Il est possible de tenter d’effectuer vous même une mitigation en vous basant sur les adresses IP utilisées par les robots. HAProxy permet de fixer une limite de requêtes sur une période pour une IP ou plage d’IP donnée. Il vous faudra maintenir cette liste de manière assidue, et surtout bien déterminer le taux à configurer pour ne pas risquer trop de faux positifs.

Du fait de la multiplication des robots et de leurs IPs, des solutions existent qui s’occupent de mettre à jour ces informations. Ces solutions sont généralement payantes :

• Ajouter une porte d’entrée à votre site (test de Turing inversé)
  Vous pouvez conditionner l’entrée des visiteurs à la réalisation d’un test qui prouvera qu’il est bien légitime.
  • L’outil Anubis de TecharoHQ peut être installé sur votre serveur et fonctionner comme un proxy qui s’occupera de filtrer l’accès à votre application. Il existe une solution gratuite et payante (sans pub).
  • Cloudflare propose l’API Turnstile qui ajoutera un test à l’entrée de votre site (il est nécessaire de créer un compte)

Pour les sites de contenu ces solutions ne sont pas trop gênantes, mais cela devient plus dérangeant pour les sites de vente en ligne si le test à réaliser est trop intrusif ou restrictif (du type Captcha).

• Déléguer la mitigation :
  Les CDN grand public comme Cloudflare (US) ou Bunny (Européen) proposent des services de mitigation basés sur leur propre heuristique et couplés à une limitation de trafic (service WAF, “Web Application Firewall”), ces outils peuvent se révéler très efficaces, à des prix abordables. L’inconvénient est que, pour les activer, il est nécessaire de déléguer votre zone DNS chez eux.

Dormir la fenêtre ouverte

L’optimisation de votre application pour supporter les effets DdoS de l’activité des robots est une solution gratifiante de tout point de vue. Elle vous permet d’identifier les goulets d’étranglement, revoir l’architecture des services, et rendre l’accès à votre application plus confortable pour vos utilisateurs. Cela nécessite du travail en amont et qui se révélera payant pour le cycle de vie de vos développements.

• Importance du cache : l’ajout d’un cache pour les éléments statiques de votre application peut grandement faciliter les choses. Cela peut se faire via un cache applicatif (Drupal en possède un performant), ou un cache serveur type Varnish, couplé à Redis pour les sessions. Pour une application de gestion de contenus, ces solutions sont très efficaces, mais dans le cadre d’une boutique en ligne, des adaptations dans le développement de l’application seront nécessaires pour dissocier les éléments dynamiques du contenu statique (comportement du panier, gestionnaire de déclinaisons …).
• Si l’application supporte bien la mise en cache, la réalisation d’un test de charge pourra être intéressant pour identifier ce qui va provoquer la saturation, et généralement une analyse de votre base de données sera un élément déterminant pour limiter la saturation trop rapide de la mémoire ou du CPU.
• Du fait de sa longue expertise sur les outils comme Varnish, Redis ou encore le tunning de base de données, Bearstech peut vous accompagner à chaque étape de votre besoin d’optimisation.

En conclusion, il n’y a pas de solution “clé en main”: que ce soit par l’analyse du trafic pour séparer celui qui est légitime ou nécessaire à votre référencement, ou par l’ajout de solutions de contrôle du trafic entrant, ou la mise en cache du site, chacune nécessitera un effort d’analyse et d’optimisation, mais ce travail sera le gage d’une vie meilleure pour vos serveurs, vos utilisateurs et vos développeurs.