Salut!
Je peux donner quelques infos sur ce que je fais chez moi.
0. Les bases
- Pour Google, Bing et les moteurs de recherche classique: j'ai configuré un "Crawl-Delay" dans le fichier robots.txt. Cela leur demande de ne pas faire plus d'une requête toutes les quelques secondes (on choisit combien) et réduit leur traffic de façon acceptable. C'est bien respecté par les crawlers des moteurs de recherche.
- Pour les scrappers "honnêtes" (bot SEO par exemple, mais certains trucs de LLM aussi): blocage par une liste d'identifiants de bots dans le robots.txt avec une règle "Disallow /"
Là on a les bases pour les trucs implémentés correctement. Ensuite il faut lutter contre les trucs malveillants et/ou mal fichus.
1. Blocage des bots ne respectant pas le robots.txt
Dans mon robots.txt j'ai mis un Disallow /url-interdite.
L'URL en question est également présente dans les en-têtes ou en bas de page de mon site, avec un texte disant "si vous êtes un humain, ne cliquez pas ici vous allez vous faire bannir". Le lien est également en nofollow.
Si un bot accède à cette URL, c'est blocage direct.
Pour implémenter le blocage: règle spécifique dans le serveur web, qui retourne une erreur spécifique (j'ai choisi le code HTTP 429). J'ai ensuite une règle fail2ban qui scanne les logs de mon serveur HTTP pour trouver ces erreurs 429 et bloquer les IP correspondantes au niveau du pare-feu. Le même principe est utilisé dans les sections suivantes.
On peut aussi faire la même chose pour plein d'URLs "classiques" utilisés par des scanners de vulérabilités qui cherchent des wordpress, phpmyadmin, et autres nids à failles connus.
2. Filtrage par user agent
Pour certains bots ne respectant pas le robots.txt (typiquement, ne respectant pas le crawl-delay), mais qui s'identifient avec un user agent unique, filtrage des user agents "interdits" au niveau du serveur web.
3. Les bots "cachés"
Comme je ne suis pas le seul à mettre en place ce genre de mesures, il y a maintenant des bots qui se déclarent avec un user agent "classique" (typiquement une version de Chrome, mais il commence à y avoir aussi du Firefox). On peut tenter de bloquer les IPs "non résidentielles" quand on repère une plage d'IP (il y a eu Tencent et Alibaba il me semble, mais il y en a de nouvelles régulièrement).
Là, on peut au choix bannir ces IPs "préventivement" de façon statique dans le pare-feu, ou bien attendre la première requête sur le serveur web pour réagir.
4. Les proxys résidentiels
C'est la dernière nouveauté. Comme les IPs de datacenters sont de plus en plus mal vues par les sites internets, les robots utilisent maintenant des relais déployés via des applications sur des téléphones ou des télés connectées chez plein de gens.
J'ai lu un blog de quelqu'un indiquant que son site avait reçu des requêtes venant de un quart de l'espace d'addresage IP. En gros, quasiment toutes les IP possibles vont être utilisées, et ça devient très difficile de faire un blocage par IP (même les pare-feus ne suivent plus: il y a tellement d'IPs qu'il faut plusieurs Go de mémoire juste pour stocker la liste des IP bloquées...). Et chaque IP ne va typiquement faire qu'une seule requête, donc le blocage est peu efficace si on attend d'avoir plusieurs requêtes avant de bloquer.
Le blocage géographique peut être une solution (si vous acceptez de restreindre l'accès pour certains pays, mais il risque d'y en avoir de plus en plus tant qu'il n'y aura pas de législation pour interdire ces pratiques).
Chez moi, j'ai fini par bloquer toutes les versions un peu anciennes de Chrome et Firefox pour Windows. Comme ces robots ont tendance à utiliser des user agents ne correspondant pas à la toute dernière version, ça limite assez les problèmes. Et les gens utilisant un autre OS ou un autre navigateur ne sont pas impactés.
5. Pourquoi ces attaques?
Ce que j'observe, c'est que les interfaces web de dépôts git comportent une quasi infinité de liens (historique des versions, puis affichage de chaque fichier dans chaque version, etc). C'est le "tarpit" parfait pour un robot scrapper d'entraînement LLM, tout plein de contenu à lire!
Je pense qu'avec un site comportant moins de liens, il y a moins de problèmes, le robot va rapidement en faire le tour et aller voir ailleurs.
Dans certains cas j'ai fini par mettre mon interface web de dépôt Git accessible uniquement après login.
6. Conclusion
Je vous donne volontairement peu de détails spécifiques sur ma configuration.
Le déploiement de solutions "universelles" (Anubis, iocaine, ou de façon générale une config standardisée avec une liste de user agent connue) pousse les développeurs de bots à trouver un contournement spécifique pour la solution la plus populaire. Le seul moyen de leur rendre la vie impossible, c'est que chaque site web aie ses propres règles. Donc, adapter votre configuration à ce que vous observez est la bonne démarche. Et aussi choisir vos propres durées de ban, pour pas que tout le monde aie la même.
J'arrive à garder le traffic à un niveau acceptable chez moi (pour un serveur auto hébergé sur ma connexion fibre à la maison, sans que ça pénalise les autres utilisations du serveur et de la connexion internet), mais régulièrement (tous les quelques mois) je dois mettre à jour ma liste de bans suite à un nouvel user agent ou une nouvelle forme d'attaque. Donc il faut garder un oeuil sur les accès au serveur web, c'est pas vraiment un truc qu'on peut configurer une fois et laisser tourner tout seul
7. Bonus: le monitoring.
J'utilisais awstats pour surveiller le traffic sur mon site. ça marchait bien pour repérer les pics de traffic et autres trucs louches. Mais awstats sur mon serveur n'arrive plus à suivre quand il y a des millions de requêtes à scanner dans les logs.
Je l'ai remplacé par goaccess, il est moins bien, mais plus rapide.
Bon courage!
