Un piège .htaccess coupe 80 % du trafic des bots

Ce qui se passe

Le site de l'auteur, OpenBenches.org, un recensement de bancs publics, a transféré plus de 2,5 To en un mois. Il y voit surtout des robots d'IA qui aspirent les données et les images. Sa réponse, qu'il appelle B6, est un piège minimal. Résultat annoncé après une semaine : plus de 400 adresses bloquées, un trafic quotidien passé d'un pic de 216 Go à environ 25 Go, soit plus de 80 % de moins, sans plainte d'utilisateur. Ce sont des mesures sur un seul site, par son auteur.

Le mécanisme

Un dossier /honeypot/ contient un index.php.
robots.txt l'interdit explicitement :
TEXT
```
User-agent: *
Disallow: /honeypot/
```
Chaque page du site porte un lien vers ce dossier, retiré de l'arbre d'accessibilité (aria-hidden), avec un texte impossible à cliquer (un joint de largeur nulle) et une règle CSS qui le masque et cache le curseur.
Quand quelque chose ouvre ce dossier, le script lit l'adresse IP et l'agent utilisateur, et les inscrit dans un bloc délimité de .htaccess, avec la date.
Ce bloc se place avant les autres règles de réécriture : une condition sur REMOTE_ADDR suivie d'une règle qui répond 402, avec un message en texte brut défini par ErrorDocument 402.

Un humain ne peut pas suivre ce lien, et un robot poli ne le suit pas. Celui qui l'ouvre ignore donc robots.txt, et c'est ce qui le désigne. L'auteur y voit un avantage sur les défis du type Anubis, longs à installer et gênants pour les vrais visiteurs. Il s'inspire librement du piège Blackhole de Jeff Starr, mais fonctionne aussi sur un site très mis en cache. Le code est publié sous AGPL v3 ; cette fiche ne le reproduit pas.

Les limites, dites par l'auteur

Le bannissement est immédiat et sans appel : pas d'avertissement, pas de procédure de déblocage automatique.
Les robots légitimes qui ignorent robots.txt peuvent être pris ; il faut retirer leurs entrées à la main ou prévoir une liste d'exceptions. Les robots qui respectent robots.txt mais abusent passent au travers.
Les adresses détournées ou tournantes : un innocent peut hériter d'une adresse bannie. Chaque blocage est daté pour qu'on puisse purger les plus anciens.
Un robot averti peut ignorer un lien masqué par CSS ou un chemin qui s'appelle honeypot : choisissez un autre nom.
Un .htaccess très long pourrait coûter un peu à chaque requête ; l'auteur ne juge pas cela préoccupant.

Une limite de plus, qui tient à la conception : pour écrire dans .htaccess, le processus web doit en avoir le droit. C'est un droit d'écriture sur la configuration du serveur, à n'accorder qu'en connaissance de cause.

Comment s'y prendre

Cette version suppose Apache : .htaccess n'existe pas sous Nginx, où il faudrait un autre moyen de tenir la liste d'adresses.
Essayez d'abord sur un site secondaire.
Gardez les entrées horodatées et purgez-les régulièrement ; ajoutez une exception pour les robots dont vous avez besoin (moteurs de recherche, flux).

Source : shkspr.mobi, en anglais.