
Automatisez le blocage des mauvais bots qui accèdent à votre serveur
Une TUI, une console web et une CLI qui vous aident à configurer votre serveur pour arrêter les mauvais bots sans vous cacher derrière un CDN.
Il fonctionne aux côtés de NGINX et de votre pare-feu existant (nftables ou iptables) :

L'application fait de son mieux pour ne pas vous verrouiller hors du serveur, mais vous l'utilisez à vos propres risques. Et notez qu'elle est sous licence AGPL, donc si vous l'utilisez à des fins commerciales, assurez-vous de respecter la licence.
Sur Debian ou Ubuntu, depuis le dépôt APT :
curl -fsSL https://ivankovic.github.io/stop-bots/key.gpg \
| sudo tee /usr/share/keyrings/stop-bots.gpg > /dev/null
echo "deb [signed-by=/usr/share/keyrings/stop-bots.gpg] \
https://ivankovic.github.io/stop-bots stable main" \
| sudo tee /etc/apt/sources.list.d/stop-bots.list
sudo apt update && sudo apt install stop-bots
Le paquet fournit man stop-bots (et une page par verbe, telle que man stop-bots-batch) ainsi que
les complétions bash, zsh et fish. Il n'installe aucun service et ne démarre rien.
Ou depuis crates.io, avec Rust 1.88 ou plus récent :
cargo install stop-bots
Ou téléchargez un binaire statique pour x86_64 ou aarch64 Linux depuis les GitHub
releases.
install refuse un
hôte qui n'est pas Debian ou un dérivé.nft, ou iptables-restore et ip6tables-restore, pour le
pare-feu ; nginx pour le reste. NGINX dans un conteneur fonctionne aussi — voir
Exécuter NGINX dans un conteneur.sudo stop-bots démarre la TUI. Elle nécessite root : elle réécrit /etc/nginx et charge les règles
du pare-feu.u télécharge toutes les listes : listes de bots, plages d'IP de crawlers, et tout flux ou pays que vous
avez activé.1) contient la politique globale de l'hôte : quelles catégories de bots sont bloquées,
les pays, et les détecteurs qui lisent vos logs. Sur l'écran NGINX (4), r trouve vos
sites. L'écran Blocks (5) liste chaque règle ajoutée par les détecteurs ou par vous, et pourquoi.a applique tout. Il montre d'abord ce qui changerait — les fichiers, les règles ajoutées et
supprimées, et le verdict du contrôle de verrouillage (d pour le diff) — et demande confirmation.sudo stop-bots install firewall fait survivre les règles appliquées à un redémarrage. Sans cela, un
redémarrage revient sans aucune règle.sudo stop-bots status vérifie le noyau, les unités et les fichiers, et indique ce qui
manque.sudo stop-bots status
sudo stop-bots batch --dry-run --diff
sudo stop-bots batch --apply
sudo stop-bots install firewall
sudo stop-bots status
batch --dry-run ne télécharge et n'analyse rien : sur une installation toute neuve, il affiche les
blocs NGINX issus de la liste de bots intégrée au binaire, et aucune règle de pare-feu pour l'instant, car rien
n'a été lu depuis vos journaux. sudo stop-bots batch sans --apply effectue les téléchargements
et les analyses et écrit les fichiers pour examen sans les appliquer. Voir
Unattended, from cron pour ce que fait batch.
sudo stop-bots uninstall all --dry-run
sudo stop-bots uninstall all
Les premières listent chaque étape, les secondes les exécutent. Voir Mise à niveau et désinstallation.
Bots connus, par catégorie (scanner / moteur de recherche / crawler IA), issus de
ArcJet's Well-Known Bots,
ai.robots.txt et de la
NGINX Ultimate Bad Bot Blocker
liste. Bloquer une catégorie injecte une règle if ($http_user_agent ...) dans la configuration NGINX
de chaque site.
Trop de requêtes, via le rate limiting propre à NGINX.
Politement, d'abord — un robots.txt généré listant chaque bot que vous bloquez, pour les
crawlers qui le respectent, plus le chemin honeypot ci-dessous.
Sauf là où vous en décidez autrement — exemptions de chemins par site, et adresses et
user agents de confiance (trust), auxquels aucun blocage, liste ou rate limit ne s'applique.
Requêtes qui ne ressemblent pas à un navigateur, par site. Six règles indépendantes, chacune avec son propre interrupteur et chacune désactivée par défaut — un interrupteur par règle pour que si quelque chose chez vous cesse de fonctionner, vous puissiez identifier quelle règle en est la cause :
| Règle | Rejette, outre les bots |
|---|---|
| HTTP/1.0 et HTTP/1.1 | crawlers et clients API qui ne parlent pas HTTP/2 |
Pas d'en-tête Accept | certains clients API n'en envoient aucun |
Pas d'Accept-Language | les outils de confidentialité le suppriment |
User-Agent vide/absent | les scripts et health checks l'omettent souvent |
Host est une IP nue | empêche d'atteindre le site par IP |
| TLS 1.0 / 1.1 | uniquement les clients très anciens |
Il y a sept choix :
| Option | À quoi ça sert |
|---|---|
403 Forbidden (par défaut) | indique que le blocage était délibéré ; le seul sur lequel un humain bloqué par erreur peut agir |
404 Not Found | dissimule qu'un blocage a eu lieu |
410 Gone | demande aux crawlers bien élevés d'abandonner l'URL définitivement — préférez ceci au 403 lorsque vous rejetez des crawlers plutôt que des attaquants |
429 Too Many Requests | indique à un client poli de ralentir et de réessayer |
418 I'm a teapot | la blague de la RFC 2324. Ça fonctionne ; ce n'est simplement pas enregistré auprès de l'IANA, et NGINX l'envoie avec un corps vide |
444 close connection | aucune réponse du tout ; le moins coûteux, mais indiscernable d'un serveur en panne |
Tarpit | répond 403 mais fait couler le corps à un octet par seconde, pour que le client attende au lieu de passer à autre chose |