Comment bloquer les bots de crawling de manière efficace ?

Domains and Hosting
1

Bonjour,

Nous rencontrons de plus en plus de souci à cause des bots IA crawlant notre site de manière abusive.

Les comportements sont tellement abusifs que notre site tombe régulièrement en erreur 500 du fait de la restriction en nombre de requêtes à la base de données. Nous recevons des mails d'informations d'OVH à ce sujet et constatons dans nos logs ces pics de trafic anormaux.
Nous sommes en performance 1 et ceci est amplement suffisant pour l'usage générale que nous en avons.
En temps normal, nous plafonnons à peine à 5% des capacités du système.

La réalité est que nous subissons régulièrement des crawls intensifs de bots qui entrainent cette sur-consommation excessive de requêtes, parfois à plus de 6 requêtes/secondes de pages distinctes.

Ceux-ci sont facile à repérer puisqu'il s'agit d'un unique GET à une page.

Nous avons mis en place dans un Htaccess une première protection pour bloquer le traffic des bots agissant de manière transparente.
Celle-ci a fonctionné un temps.

Nous avons ensuite identifié des IP, voire plages d'IP, problématiques.
Idem, cela à fonctionner un temps, mais sur une seule matinée, nous avons pu constater plus de 800 IPs différentes … impossible de maintenir à jour un tel nombre et en plus au risque d'exclure des utilisateurs légitimes en fonctionnant par plage.

Maintenant, les bots utilisent des générations de User-Agent frauduleux pour se faire passer pour de véritables utilisateurs. Nous avons repéré que la plupart utilisaient des déclarations de UserAgent de navigateurs ou plateformes obsolètes, voire incohérent :
- Chrome obsolète (<142)
- Firefox obsolète (<110)
- Internet Explorer < 9
- anciens Safari / WebKit (<400)
- systèmes d’exploitation obsolètes Windows\s(95|98|NT\s5|2000)|PPC\ Mac

Nous avons donc mis en place des règles basées sur le user agent pour détecter des incohérences mais certains bots arrivent encore à passer et nous ne pouvons pas non plus imposé systématiquement des versions trop récentes ce qui serait au dépend de nos vrais utilisateurs.

Cela devient vraiment problématique.
Êtes-vous également concerné par ce genre de souci ?
Comment bloquer ces comportements abusifs ?
Avez-vous des astuces permettant de sécurisé l'accès à nos sites à de "vrais humains" ?

2

Bienvenue dans le nouveau monde.
Je gère une petite infra de serveurs Dédié et moi aussi j'ai pas mal de problème depuis qq mois.
Ce que tu décrits peut avoir plusieurs causes mais tes remarques font penser à un scrap abusif trop agressif via du proxy résidentiel (regarde les AS des IP).

Malheureusement c'est une course entre scrapeur et anti scrapeur qui n'aurat pas de fin.
Normalement cela ne dure pas pas trop longtemps.
Si ton site est important avec un grosse notoriété -> serveur barre métal avec un bon infogérant.
Ou alors Cloudflare et te plongeant dans la doc antibot.

3

Pour le site de mon client, ça fait 6 mois que ça dure avec des vagues plus ou moins intense.
Juste sur les 3 derniers jours, j'ai identifié plus de 8000 ips différentes à se connecter et qui ont passer le filtrage basique par htaccess.
À la louche, j'estime que seulement à peine 10% du traffic à vraiment un intérêt et est légitime (et encore je laisse passer GoogleBog, Ahref, et autres bots utilise au SEO, …).

Au final, j'ai consacré une petite journée à développer un mini WAF.
Le site étant basé sur un Prestashop et 90% des requêtes passant par le fichier index.php, j'ai développé une petite classe d'analyse du traffic en scoring comportemental (présence de cookie, analyse de session, fréquence des requêtes, …) en complément de l'analyse des incohérences des user agents que j'appelle avant le chargement de quoi que ce soit d'autres.

Si jamais, l'analyse ressort un profil "louche", je fais afficher un petit message avec un bouton à cliquer pour prouver que l'utilisateur est bien un humain, et lui permettre de passer en whitelist.

Ça fait 4 jours que ça tourne et ça fait bien le job. La surcharge de quelques millisecondes que représente ce traitement est largement compensé par le fait que le serveur ne tombe plus en erreur 500 faute de ressources indisponibles. Les stats en console OVH montrent également que la charge à drastiquement diminué.