Réduire l’impact des bots sur son site

Il fut un temps où les seuls bots (également appelés crawleurs) qui parcouraient votre site web étaient ceux des moteurs de recherche. Leur objectif était assez évident et leur utilité claire pour les sites web : ils permettaient aux sites de devenir visibles sur le web en étant référencés par les moteurs de recherche. Aujourd’hui, il existe une myriade de bots ayant des objectifs variés, et leur intérêt respectif n’est pas toujours évident.

Le rapport annuel de Thales Imperva sur les mauvais bots estime qu’en 2023, près de la moitié du trafic Internet provenait de bots (processus automatisés), et environ 32 % de ce trafic provenait de mauvais bots, c’est-à-dire des bots ayant des intentions malveillantes (accès illégal, extraction de données, utilisation commerciale de votre contenu protégé, etc.). Ces chiffres augmentent chaque année. La distinction qu’ils établissent entre bons et mauvais bots est floue. Comment peut-on déterminer qu’un bot a des intentions malveillantes lorsque celles-ci sont inconnues ? Ils soulèvent également des préoccupations concernant les “bons” bots, qui peuvent avoir des effets secondaires, comme l’augmentation du nombre de vues publicitaires sans provoquer de ventes.

Si les intentions de la plupart des bots restent floues, leurs comportements ont un impact sur les sites web. Il semble donc de plus en plus important de savoir comment gérer les bots afin que votre site web puisse soit tirer parti de leur présence, soit éviter que leur utilisation ne dégrade ses performances, selon vos besoins. Ensuite, nous vous présenterons quelques outils dont dispose un webmaster pour lutter contre les bots, ainsi que l’impact de l’exploration de votre site web et les moyens de vous protéger contre les comportements indésirables.

Outils de mitigation de l’exploration

Ci-dessous se trouve une boîte à outils indispensables pour se protéger contre les robots d’exploration et l’extraction de données. Il existe deux types d’outils :

  • Les outils externes, qui bloquent l’accès à votre site web, totalement transparents pour l’administrateur et éventuellement laissant des traces dans les journaux.
  • Les ressources informatives, qui déclarent quelles parties d’un site web ne sont pas explorables ou lesquelles doivent l’être (fichiers robots.txt et sitemaps).
  • Et il est toujours possible d’essayer de communiquer avec le propriétaire du robot d’exploration.

Nous présenterons d’abord chaque outil, puis, dans la partie suivante, nous expliquerons dans quelles circonstances ils peuvent être utiles.

Protocole d’Exclusion des Robots

L’outil le plus efficace pour réguler l’exploration de votre site web est le Protocole d’Exclusion des Robots, mis en œuvre par le célèbre fichier robots.txt, proposé pour la première fois en 1994 par Martijn Koster. C’est surtout Google qui a poussé à sa standardisation autour de 2020, et le protocole est devenu une RFC en 2022 (https://datatracker.ietf.org/doc/html/rfc9309). Le fichier robots.txt contient des règles, soit génériques, soit ciblant un user-agent spécifique (c’est à dire l’identifiant auto-déclaré d’un crawleur), qui indiquent quelles pages sont autorisées ou interdites sur un site web. Mais cela est purement informatif, un crawleur n’a pas d’obligation de respecter ce protocole mais il est tout de même risqué de ne pas le faire et de es faire catégoriser comme un bot malveillant. Ce tutoriel de Google est une bonne introduction. Pour un exemple, vous pouvez consulter ce fichier robots.txt de Wikipedia..

Sitemap et news sitemap

Un fichier robots.txt peut spécifier l’adresse d’un ou des fichiers « sitemap » de sont site (Cette directive est non standard dans la RFC et peut donc être ignorée). Le sitemap est essentiellement une liste d’URL d’un site web donné, que ce soit sous la forme d’un fichier texte ou (de préférence) d’un fichier XML. Le sitemap permet d’indiquer quelles sont les parties du site web ou le crawleur doit d’abord se concentrer avant de poursuivre son exploration. Il permet de plus d’indiquer de nouvelles pages pour qu’elle puissent être indexées rapidement. Il permet également d’indiquer la date de dernière modification des pages, permettant de ne pas télécharger du contenu qui n’a pas été modifié depuis la dernière visite du crawleur. Les bots ne tiennent pas forcement compte du fichier sitemap, mais le Google bot le fait et l’utilise comme liste de suggestions. Le fichier news sitemap est un sitemap spécifique dédié aux pages d’actualités. Il est plus proche d’un flux RSS dans sa forme.

Plateformes de sécurité ou outils de sécurité

Vous pouvez protéger votre site web en utilisant différentes plateformes de sécurité, telles que Crowdstrike, Akamai, Cloudflare ou Palo Alto Networks. Ces plateformes proposent généralement des outils anti-malware, des filtres IP, des pare-feu, etc. C’est un moyen simple d’obtenir une bonne protection, moyennant un coût bien entendu. Cependant, elles peuvent également présenter des inconvénients en bloquant tout, y compris ce que vous souhaiteriez laisser passer. En particulier, si vous souhaitez une analyse SEO de votre site, il peut être difficile de laisser accès au crawleur SEO de votre choix.

Contacter les responsables du crawler

Parfois, la solution la plus simple est d’essayer de communiquer avec l’équipe derrière un crawler en utilisant votre moyen de communication préféré. Si vous ne parvenez pas à les contacter directement, il est toujours possible de trouver le fournisseur d’accès Internet lié à l’adresse IP fautive et d’envoyer une demande d’abus qui sera rapidement transférée. Nous ne pouvons parler que de notre cas, mais nous répondons toujours aux requêtes, même si la forme laisse parfois à désirer.

Comportement et stratégies de mitigation

Lorsqu’un site web est exploré, la même adresse IP et/ou le même user-agent sont enregistrés un nombre inhabituel de fois dans les journaux du serveur. Une rafale de visites peut alors être détectée automatiquement par une plateforme de sécurité ou même être directement repérée dans les journaux du serveur pour les sites avec une affluence faible. Il est toutefois moins simple d’interpréter ces signaux. Examinons certains indices, le comportement sous-jacent et leurs stratégies de mitigation (si nécessaire).

DoS, DDoS

Selon Wikipedia, l’inspiration initiale pour le Protocole d’Exclusion des Robots était une attaque par déni de service (DoS) involontaire causée par un crawler bogué. Une attaque par déni de service (Denial of service an anglais ou DoS, ou encore par déni de service distribué (DDoS) si plusieurs IP sont utilisées) est une tentative de perturber le trafic normal d’un serveur, d’un service ou d’un réseau en inondant la cible ou son infrastructure environnante de trafic Internet, c’est-à-dire que si vous envoyez suffisamment de requêtes à un serveur, il ne pourra pas répondre à toutes et ne pourra certainement pas maintenir un comportement normal pour les accès légitimes.

Chaque site est dimensionné en fonction de son trafic habituel (ou simplement d’un budget restreint), mais cette information n’est pas disponible publiquement, et un crawler web considèrera probablement chaque site de la même façon. De nos jours, même les plus petites solutions d’hébergement permettent plusieurs dizaines de requêtes simultanées et peuvent facilement évoluer vers des centaines de connexions simultanées. Un crawler mal configuré ou très naïf peut envoyer trop de requêtes, mais ce n’est pas le cas de la grande majorité des crawlers qui ne risqueront pas d’être bannis définitivement.

Stratégie de mitigation: Pour les sites plus petits, une exploration avec plusieurs requêtes par minute peut apparaître comme une surcharge, mais la plupart du temps cela n’affecte pas les capacités du serveur web. Accéder à un serveur web chaque minute ne devrait pas poser de problème et n’est certainement pas une attaque DoS. Avant tout, vous devez évaluer si l’exploration provoque réellement un déni de service en consultant les statistiques du serveur (charge, trafic) ou les journaux (si le serveur web indique trop de connexions à la fois). S’il y a bien un déni de service, le crawler bogué peut être banni du site en interdisant toutes les ressources dans le fichier robots.txt.

Notez qu’une directive non standard du Protocole d’Exclusion des Robots (Crawl-delay) permet de dire à un crawler quel délai (en secondes) il doit observer entre deux tentatives. Le robot de Google ne la prend pas en compte, mais d’autres crawlers comme BingBot la respectent.

Attaque par force brute

Une attaque par force brute est une attaque très naïve qui consiste à essayer différentes combinaisons pour craquer des mots de passe, accéder à un site ou casser des clés de chiffrement. Évidemment, cela ne peut fonctionner qu’avec des algorithmes de chiffrement très faibles, mais cela peut être utile si les utilisateurs ne sont pas obligés d’utiliser des mots de passe forts et/ou des passaphrases (ce que l’on appelle la vulnérabilité « chaise-clavier »). Une attaque par force brute se détecte par des échecs répétés à accéder à une ressource protégée. Il arrive parfois qu’un crawler ne cherche pas réellement à accéder à une ressource, mais seulement à explorer une URL trouvée publiquement qui nécessite des informations d’identification, mais qui n’a pas été interdite par le fichier robots.txt Ce genre de tentative déclenche alors souvent une alerte.

Stratégie de mitigation: Comme pour les attaques DoS, plusieurs tentatives d’accès à une ressource restreinte ne signifient pas que vous êtes victime d’une attaque par force brute, qui exige des milliers de tentatives pour avoir une chance minime de réussir. La meilleure stratégie de mitigation est de prévenir l’accès aux ressources restreintes en utilisant une directive du fichier robots.txt. Notez que la syntaxe des directives du fichier robots.txt permet de définir des restrictions portant sur un paramètre de la requête, et pas simplement sur un chemin de page.

Action déclenchées par URL

Le web est constitué de pages reliées par des hyperliens, mais les liens sont aussi des sources d’action comme « ajouter au panier » sur un site de commerce électronique, une connexion ou une tentative d’accès à une ressource restreinte. Même si ces URLs se trouvent publiquement, essayer d’y accéder peut déclencher (la encore) des alarmes. Une URL de connexion peut, par exemple, envoyer un email si le compte n’existe pas (cas que nous avons rencontré récemment). Le pire des cas concerne les pages dynamiques où chaque accès crée de nouveaux liens avec en ajoutant des paramètres dans l’URL, le crawler peut alors se retrouver piégé dans une boucle. Cela n’est souhaitable ni pour le site, ni pour le crawler. Le crawler ne peut pas simplement ignorer les paramètres d’URL, car certains sites web sont entièrement dynamiques et l’URL est la même pour toutes les ressources, à l’exception des paramètres de la requête.

Stratégie de mitigation: La plupart des plateformes proposent ou recommandent un fichier robots.txt par défaut conçu pour éviter ces effets secondaires. Regardez les propositions de Magento ou Prestashop pour les plateformes de commerce électronique. WordPress propose un fichier robots.txt pour empêcher l’accès à la console d’administration. Encore une fois, les directives du fichier robots.txt ne se limitent pas à des chemins absolus, et il est possible de filtrer en fonction des paramètres d’URL en utilisant des expressions régulières ou des caractères génériques. Une règle simple : si une ressource ne doit pas être accessible publiquement, alors elle doit être interdite par le fichier robots.txt.

Fausse alarme

Les plugins ou plateformes de sécurité préfèrent souvent signaler les faux positifs plutôt que de manquer de véritables attaques. Il peut ne pas exister de différence réelle entre le comportement d’un crawler web et celui de quelqu’un essayant de scraper un site web, du moins pas de différence détectable de manière programmatique. Par exemple, une plateforme de sécurité bien connue enregistre tous les bots qui ne peuvent pas résoudre leurs captchas ou leurs vérifications comme source d’attaque, mais selon eux, c’est à leurs clients de mettre sur liste blanche ou non l’adresse IP correspondante. Combien de leurs clients prendront le temps de passer en revue toutes les sources d’attaque possibles pour débloquer un crawler inconnu ? Très peu dans le meilleur des cas.

Stratégie de mitigation : Si vous ne pouvez pas faire confiance à tout ce qui émane des plateformes de sécurité, votre meilleure défense est d’acquérir des connaissances à propos des bots les plus communs et de leurs roles respectifs. Le but des crawleurs des moteurs de recherche est clair, pas besoin de revenir dessus. Les crawleurs SEO sont assez courants (et gourmand), mais leurs intérêts resident plutôt dans la connaissance du graphe du web (les liens entre les pages) plutôt que dans le contenu, i.e., ils ne sont pas pas la pour dupliquer votre contenu ou bien l’utiliser à des fins commerciales. Les bots marketing sont la pour mettre à jour leur bases de données et actualiser les informations de votre site, etc. Nous avons déjà vu ci-dessus l’impact qu’un crawleur peut avoir sur un site web et comment le réduire le cas échéant. La deuxième crainte la plus fréquente concerne la propriété intellectuelle et les principaux concernés sont les bots d’IA, qui qui en général utilisés pour créer des ensemble de données d’entrainement. Le risque, c’est que des informations sensibles ou protégées puissent être ressorties par le modèle. Tout les bots d’IA ne sont pas à mettre dans le même panier. Il n’y a malheureusement pas de liste “officielle” des bots de l’Internet. Vous pouvez tout de même trouver des listes telles que la liste des bots identifiés par Cloudflare.