Journal Bloquer les bots avec Nginx de façon simple avec Nginx botcheck

Posté par  (site web personnel) . Licence CC By‑SA.
Étiquettes :
36
2
sept.
2026

Disclaimer : ce journal est une republication de l’article de présentation de Nginx botcheck sur mon blog.

Avec l’explosion de l’IA, on a de plus en plus de bots qui viennent sur nos sites pour, grosso modo, tout pomper pour entraîner des modèles IA (souvent en tapant comme des connards sur toutes les pages qu’ils peuvent sans réfléchir à une manière plus propre de faire) ou pour essayer de trouver des vulnérabilités avec des agents IA.

Et ça peut mettre nos sites en péril. Chez Framasoft, par exemple, Framagit est régulièrement ralenti, voir inutilisable à cause d’un trafic de bots complètement dingue. Ça peut toucher n’importe qui, vraiment.

Et malheureusement, des outils comme Fail2ban et reaction sont impuissants contre un tel fléau : les bots utilisent une adresse IP pour quelques requêtes et passent à une autre IP.

On peut bloquer des AS, pour par exemple bloquer du trafic venant d’hébergeurs, mais pour un site fédéré (comme mon blog, mon nextcloud, un serveur Mastodon ou PeerTube), avec un flux RSS (c’est très le bien, les flux RSS, utilisez-les !) ou une forge logicielle comme Framagit sur laquelle on vient cloner un dépôt git pour installer un truc sur son serveur, c’est inenvisageable.

Il y a aussi le blocage par pays, mais on ne sait jamais d’où peuvent venir les usages légitimes. Chez Framasoft, j’ai déjà banni des pays de certains services pour cause de vagues de spam, en nous disant que c’était pas trop grave parce que le pays n’était pas francophone, mais il peut toujours y avoir un·e utilisateur·ice en voyage, ou expatrié·e qui a besoin d’accéder au service. Donc bof. En tout dernier recours.

Bref.

Alors oui, bien sûr, y a Anubis, Iocaine et consorts. Mais ça demande un service supplémentaire sur sa machine, et de les configurer finement, ce qui n’est pas forcément une mince affaire (croyez-moi : j’ai mis Anubis sur Framagit, ça demande une connaissance très fine des routes de Gitlab et de bien comprendre les possibilités des expressions de configuration d’Anubis).

Par contre, le créateur de DokuWiki, @splitbrain@fedi.splitbrain.org, a créé un système de blocage tout simple à base de redirection Apache et un tout petit programme en Go, appelé par Apache (donc ce n’est pas un service qui tourne à côté) : botcheck. Côté client·e, c’est un simple bouton à cliquer pour accéder à la page désirée, et vous êtes tranquille pendant un temps.

Sebsauvage a aussi développé un système un peu similaire.

J’ai été séduit par la simplicité de ces solutions, mais insatisfait car je suis plus du côté Nginx de la force. Qu’à cela ne tienne, je me suis retroussé les manches et j’ai développé ma solution : Nginx botcheck.

Point de service externe, j’utilise le module Lua de Nginx pour tout mettre dans la configuration Nginx. Une fois installé sur le serveur selon les instructions données, la protection d’un virtualhost est aussi simple que l’ajout de include botcheck/botcheck.conf; dans sa configuration.

Le code de Nginx botcheck est très simple à lire et à adapter (au contraire des règles de réécritures du botcheck Apache 😅). On peut ainsi ajouter autant de conditions pour forcer ou contourner la page anti-bot que l’on souhaite, en ajoutant une map Nginx pour définir une variable et un bout de code aussi simple que celui-ci :

--  No botcheck for custom map
if ngx.var.my_var == "yes" then
    return "yes"
end

Je trouve que Nginx botcheck constitue une solution simple et élégante aux problèmes de bots, et je vous encourage fortement à le tester en cas de besoin !

Notez bien qu’il ne s’agit que d’une première ligne de défense, mais en attendant, je regarde mes logs, et je me dis que c’est déjà pas si mal 🙂

  • # Et si voulez voir ce que ça donne

    Posté par  (site web personnel) . Évalué à 4 (+2/-0).

    Vous pouvez aller voir sur https://slides.fiat-tux.fr, par exemple.

    Being a sysadmin is easy. As easy as riding a bicycle. Except the bicycle is on fire, you’re on fire and you’re in Hell.

  • # Faut voir

    Posté par  . Évalué à 5 (+3/-0).

    Discerner le bon bot du mauvais bot, je sais que c'est un problème insoluble.

    Avec cette solution :

    1/ un utilisateur humain doit avoir JS activé (même si ça parle de fonctionner avec un referer, je suis pas sûr comment)
    2/ un bot légitime et ne gérant pas JS ne passera pas
    3/ combien de temps avant que des bots illégitimes ajoute un header `cookie: botckeck=1' ?
    4/ un bot qui tente avec différents user agents (Firefox, Curl) passe

    Ça fait toujours un outil en plus dans la boite à outils du sysadmin, merci pour le portage en Nginx/Lua (trop peu utilisé à mon gout) et le partage.

    • [^] # Re: Faut voir

      Posté par  (site web personnel) . Évalué à 8 (+6/-0).

      un utilisateur humain doit avoir JS activé

      Non. Tu peux essayer en désactivant le JavaScript, ça fonctionne très bien sans 🙂

      un bot légitime et ne gérant pas JS ne passera pas

      Le botcheck de splitbrain se base sur les listes d'adresses IP des bots d'indexation légitimes connus, j'ai repris la liste. Je compte faire une map alliant User-Agent et adresses IP des bots légitimes pour verrouiller un peu mieux ça. NB : mon projet date de la semaine dernière, la peinture est encore fraîche 😉

      combien de temps avant que des bots illégitimes ajoute un header `cookie: botckeck=1' ?

      Idem, peinture fraîche : je compte demander/permettre à l'utilisateur·ice de botcheck de mettre en place une variable pour le contenu du cookie, ce qui fera que chaque installation de botcheck aura un cookie différent.

      un bot qui tente avec différents user agents (Firefox, Curl) passe

      Libre à l'utilisateur·ice de botcheck de changer la liste des User-Agents autorisés, hein, rien n'est gravé dans le marbre 🙂

      Being a sysadmin is easy. As easy as riding a bicycle. Except the bicycle is on fire, you’re on fire and you’re in Hell.

  • # réseaux de bot d'indexation

    Posté par  (site web personnel) . Évalué à 5 (+4/-0).

    Le blocage des réseaux de bot d'indexation est vraiment une aventure. Pour moi elle a commencé avec une indexation massive de tous les commits et les diffs de mon cgit.

    J'ai d'abord pensé que fail2ban ferait l'affaire, avec des règles sur les vieux navigateurs (partant d'un postulat que les vrais gens ont des navigateurs qui se mettent à jour tout seul). J'ai même trouvé sur github une liste de faux navigateur qui semblait être la source utilisée (ou un dérivé) pour faire tourner le User-Agent de ces requêtes.

    La liste des IPs bannies a vite atteint plus de 200k, et les mises à jour de cette liste ont vite consommé beaucoup trop de CPU (nft add, nft remove). J'ai donc écrit fail2ban-subnet pour tenter d'identifier des sous-réseaux hostiles mais ça n'a pas aidé : j'ai compris que c'était trop distribué et que c'est des appareils compromis ou avec des fonctions cachées au fond des conditions générales qui étaient utilisées et que finalement c'était chez les vrais gens.

    N'ayant pas trouvé le temps de mettre en place des solutions plus complexes, j'ai déployé une modification de botcheck sur apache2 et ça fait très bien le boulot, de manière simple : les requêtes ne sont pas servies et l'utilisation CPU et bande passante est minime. Pour encore optimiser, j'ai remarqué que le Referer utilisé par ces requêtes était toujours la racine du site, du coup j'ai mis une règle pour renvoyer une 403 dans ce cas vu que la racine du site n'a pas de lien vers mon cgit.

    • [^] # Re: réseaux de bot d'indexation

      Posté par  . Évalué à 3 (+2/-0).

      j'ai remarqué que le Referer utilisé par ces requêtes était toujours la racine du site, du coup j'ai mis une règle pour renvoyer une 403 dans ce cas vu que la racine du site n'a pas de lien vers mon cgit.

      Attention, ça peut être le comportement de navigateurs Web "normaux" configurés pour masquer le vrai referer pour des raisons de protection de vie privée. Il me semble que par le passé il y avait même une option explicite pour ça dans les préférences de Firefox, mais je ne la vois plus. Mais ça peut toujours s'éditer manuellement dans about:config (paramètres "network.http.referer.defaultPolicy.*") ou avec une extension comme Smart Referer.

      Donc attention au sur-blocage d'utilisateurs légitimes qui arriveraient depuis un lien posté sur linuxfr ou un lien dans des résultats d'un moteur de recherche par exemple.

  • # combien de bots ?

    Posté par  . Évalué à 5 (+3/-0).

    Il y a tant de IA que ça sur le marché pour que leurs bots chargent à ce point les sites ? A moins qu'elles ne reviennent pomper les données toutes les minutes, j'ai du mal à comprendre.

    • [^] # Re: combien de bots ?

      Posté par  (site web personnel) . Évalué à 8 (+5/-0).

      Il n'y a pas que l'entraînement, il y a aussi le RAG qui permet d'agir sur des sites réels, les agents, etc. Donc ça peut être à chaque demande d'un utilisateur d'IA (et "chaque demande" peut engendrer énormément de hits par ailleurs, si c'est « trouve une faille sur ce site » ou « cherche le meilleur voyage Haïti - Novossibirsk »).

      • [^] # Re: combien de bots ?

        Posté par  (site web personnel, Mastodon) . Évalué à 2 (+0/-0).

        C'est ce qui explique le nombre d'IP utilisées ?

        • [^] # Re: combien de bots ?

          Posté par  (site web personnel) . Évalué à 9 (+7/-0).

          Ce qui explique le nombre d'IP, c'est le fait que les bots se comportent comme des malpropres, qu'à cause de cela, les admins les traquent à coup de reaction et fail2ban, mais pour que reaction et fail2ban soient efficaces, il faut que l'adresse IP détectée soit toujours la même.
          Pour contourner les blocages d'IP de reaction et fail2ban, il utilisent des proxys résidentiels pour pouvoir utiliser un pool d'IP gigantesque et ne faire que quelques requêtes avec chaque IP.

          Being a sysadmin is easy. As easy as riding a bicycle. Except the bicycle is on fire, you’re on fire and you’re in Hell.

          • [^] # Re: combien de bots ?

            Posté par  . Évalué à 7 (+5/-0).

            les bots se comportent comme des malpropres … il utilisent des proxys résidentiels

            On n'avait pas des lois in France ou aux US qui interdisaient ce genre de truc ? Personne ne veut tenter une plainte ?

      • [^] # Re: combien de bots ?

        Posté par  . Évalué à 2 (+0/-0).

        Il n'y a pas que l'entraînement, il y a aussi le RAG qui permet d'agir sur des sites réels, […]

        Non le RAG c'est de l'indexation. Il s'agit d'enregistrer des données dans des vector stores pour ensuite enrichir le contexte d'un prompt. Mais ça ne fonctionne pas de tenter de faire des indexations à chaque requête. Ce qui permet à un modèle de faire des actions sur d'autres site c'est le function call.

        Le client envoie un prompt au LLM en indiquant une liste de fonctions qu'il sait faire. Le LLM réponds en demandant au client d'appeler l'une des fonctions qui peut être lancer telle recherche sur un moteur de recherche, suivre un lien, lancer telle commande,… Et de lui envoyer le résultat. MCP est le standard pour créer un outil qui est réutilisable entre différents clients. Tu as des MCP qui sont fait pour "tooliser" in site (on peut imaginer avoir un ensemble qui permet de rechercher et poster sur linuxfr).

        Ça explique la multitude d'IP et ce que ça signifie de les bloquer.

        https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

        • [^] # Re: combien de bots ?

          Posté par  . Évalué à 4 (+1/-0).

          C'est un détail d'implémentation ça, le RAG c'est d'aller chercher des infos ailleurs et de les rajouter au contexte pour générer la réponse. Il peut y avoir une phase de recherche par mot clé et tir en temps réels des résultats par un classement pour rejeter les docs non pertinents. Mais le doc peut être du récupéré par un moteur "classique" question index et un agent qui vient récupérer le doc complet.

          • [^] # Re: combien de bots ?

            Posté par  . Évalué à 2 (+0/-0).

            Si c'est par mot clef ce n'est pas du RAG, le RAG nécessite par définition une recherche sémantique via des embeddings.

            Mais le doc peut être du récupéré par un moteur "classique" question index et un agent qui vient récupérer le doc complet.

            Tu veut dire ne stocker que des couples embeddings/url ? Ça me paraît bien con. Tu paie le coût réseau, ça induit toute une classe de problème si l'URL n'est plus valide ou si elle t'injecte maintenant un payload au mieux non pertinent au pire hostile. Au moment où tu te rend compte du problème, tu dois refaire une recherche dans ton vector store pour aller chercher les résultats suivants et tu va vouloir invalider globalement ces entrées. Les index n'aiment pas particulièrement les update random…

            Ça voudrait dire que tu as peu d'IP a bloquer pour supprimer le trafic, là où ce qu'on voit c'est bien plus d'IP ce qui me paraît plus aller vers des requêtes faites par les utilisateurs.

            https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

            • [^] # Re: combien de bots ?

              Posté par  . Évalué à 4 (+1/-0).

              Non RAG à la base ça implique juste un enrichissement du contexte avec des données trouvées ailleurs : Génération à enrichissement contextuel. Ça peut être n'importe quoi à partir de là, genre générer une requête dans une base de données et lire les résultats avant de répondre.

              • [^] # Re: combien de bots ?

                Posté par  . Évalué à 1 (+0/-1). Dernière modification le 09 septembre 2026 à 20:20.

                Allez j’admets j’ai était légèrement trop assertif dans ma première phrase. Il a pu exister des RAG sans embeddings (et j’imagine que de la même manière que certains utilisent toujours svn, tu va trouver des gens qui le font encore). Ça ne change pas grand chose au fait d’avoir un fetch non fiable semble une très mauvaise idée à tout point de vu.

                https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

                • [^] # Re: combien de bots ?

                  Posté par  . Évalué à 5 (+2/-0). Dernière modification le 09 septembre 2026 à 20:25.

                  Sur des sources qui bougent tout le temps dont tu connais un peu le contenu, c'est pas une bonne pratique non plus de scanner en permanence pour rebuilder l'index (cf. le lien Good enough is not good enough.

                  Si il y a peu de requêtes, j'imagine que ça doit pouvoir dans les cas extrême coûter plus cher de réindexer que d'aller chercher au besoin les pages à jour en temps réel …

                  • [^] # Re: combien de bots ?

                    Posté par  . Évalué à 2 (+0/-0).

                    Je vois pas bien le cas d'usage. Je comprends pas pourquoi tu cherche à ne pas le faire par MCP ? Parce que c'est mon point initiale : ce qui génère le plus massivement des requêtes c'est MCP (donc le client qui fait des requêtes) plutôt que RAG (qui le serveur récupère à intervalle régulier les données pour rebuild l'index). MCP produit : aucune forme de cache/memoisation et un nombre largement plus important d'IPs sources.

                    Ca me parait intéressant de comprendre ça pour s'en prémunir plus que de savoir s'il a existé des RAG mal foutu.

                    https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

    • [^] # Re: combien de bots ?

      Posté par  . Évalué à 4 (+2/-0).

      combien ?

      36'000, selon cette source.

  • # Dans le kernel aussi

    Posté par  . Évalué à 5 (+5/-0). Dernière modification le 03 septembre 2026 à 11:44.

    Un post que j'ai trouvé intéressant et qui traite du même sujet chez kernel.org :
    creepy-crawlies

    • [^] # Re: Dans le kernel aussi

      Posté par  (site web personnel) . Évalué à 6 (+4/-0).

      Lien déjà contenu dans le journal 😅

      (derrière le texte souvent en tapant comme des connards sur toutes les pages qu’ils peuvent sans réfléchir à une manière plus propre de faire)

      Being a sysadmin is easy. As easy as riding a bicycle. Except the bicycle is on fire, you’re on fire and you’re in Hell.

  • # Quelques news

    Posté par  (site web personnel) . Évalué à 10 (+9/-0).

    J’ai bossé sur botcheck ce matin, voici ce qui en ressort :
    - un thème sombre automatique (parce que je bosse en thème sombre) 😎
    - des noms et des valeurs de cookies customisables !
    - un honeypot avec la méthode de celui d’Anubis et qui renvoie vers un Iocaine 😁
    - curl et wget ne sont plus autorisés avec la configuration par défaut

    Et je me suis mis un ticket pour faire des maps spécifiques aux crawlers connus via leur User-Agent et leurs IP connues.

    Being a sysadmin is easy. As easy as riding a bicycle. Except the bicycle is on fire, you’re on fire and you’re in Hell.

Envoyer un commentaire

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.