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

par

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, 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 <code>include botcheck/botcheck.conf;</code> 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 🙂

Ah, et si voulez voir ce que ça donne, vous pouvez aller voir sur https://slides.fiat-tux.fr, par exemple.

5 réflexions au sujet de “Bloquer les bots avec Nginx de façon simple avec Nginx botcheck”

  1. Bonjour, Luc.

    Sincérement, l’idée est intéressante…
    mais en tant qu’humain, devoir cliquer sur le bouton [ Yes, I’m a real person. ] pour pouvoir accéder à ton contenu… hum, perso, ça craint !

    Ensuite, juste un détail : j’utilise Debian Sid, en tant que OS quotidien.
    Dessus, j’ai Firefox ESR (actuellement v140.14.0) : impossible de me connecter !
    L’appui sur le bouton idoine, sus-mentionné, ne valide strictement rien.
    OK, bascule sur Chrome, et là, c’est fonctionnel. J’ai pu te lire 😉
    Aucune idée de la raison.

    Cdlt.

    Répondre

  2. Devoir cliquer, j’ai envie de dire que c’est pas un bien grand effort, surtout quand tu vois les captcha de Google avec des images toutes petites et floues. Et ça te fout la paix pendant un mois après ça 🙂

    Ensuite, pour le pb de clic qui fonctionne pas… j’avoue, je sais pas. J’ai eu le pb qq fois (il m’a suffit de rafraîchir la page pour que ça passe), mais pas toujours, et c’est pas reproductible à loisir. Mais bon, c’est un truc qui date d’il y a ± une semaine, donc avoir des bugs, c’est pas le truc le plus étonnant du monde.

    Répondre

  3. @luc
    Implémenté sur certains de mes sites, merci!
    en passant, j'ai rajouté une règle pour qu'il évite de bloquer les requêtes opensearch (quand on a un searx auto-hébergé ou autre, qu'on veut pouvoir ajouter comme moteur de recherche dans le browser).

    Je ne sais pas si c'est qqch qu'il est judicieux de rajouter dans les common exclusions?
    (si tu penses que oui, je te ferai une PR)

  4. Ping @maxlath

  5. @luc également implémenté sur certains de mes sites merci!

    Pour celleux qui comme moi avaient une conf nginx un peu pauvre en paramètres par défaut:

    1. il faut inclure le module lua dans la conf nginx (souvent config par défaut include module-enabled;)
    2. il faut inclure les confs dans le dossier conf.d (souvent config par défaut)

    J'ai traduit/personnalisé le message en anglais directement dans le fichiers 402.html.

    pourquoi autoriser les @IP de chatgpt?

Laisser un commentaire