En cas de problème, bloquez au niveau IP
(boston.conman.org)- Lors d’une récente analyse du trafic web, il a été constaté que le webbot Thinkbot était celui qui générait le plus de trafic
- Ce bot ignore
robots.txt, et son message de présentation est d’une désinvolture extrême, se résumant en substance à : « en cas de problème, bloquez l’IP » - En un mois, il a utilisé 74 adresses IP différentes, réparties sur 41 blocs réseau
- L’enquête a montré que tous ces blocs réseau étaient propriété de Tencent, ce qui fait naître le soupçon d’un possible transfert du coût du Great Firewall
- Au final, une règle de blocage massive couvrant plus de 470 000 IP a été ajoutée
L’apparition de Thinkbot
- En analysant le trafic web, il a été constaté qu’un webbot nommé Thinkbot occupait une place importante
- La chaîne User-Agent était la suivante, et particulièrement peu sérieuse
“Mozilla/5.0 (compatible; Thinkbot/0.5.8; +In_the_test_phase,_if_the_Thinkbot_brings_you_trouble,_please_block_its_IP_address._Thank_you.)”.
- En dehors de la formule « si cela pose problème pendant la phase de test, merci de bloquer l’IP », il n’y avait même pas d’URL de référence
- Le bot a procédé au crawl sans aucun respect pour le fichier
robots.txt - Même en voulant le bloquer en tant qu’administrateur de site, ce n’était pas une seule IP mais 74 adresses IP qui étaient utilisées
- En remontant leur origine et en consultant les ASN, il est apparu que cela provenait de 41 blocs réseau
- Cela signifie qu’une simple règle de blocage sur une IP unique ne permet pas de se défendre
Le lien avec Tencent
- Ces 41 blocs réseau étaient tous propriété de Tencent
- L’auteur soupçonne que le gouvernement chinois pourrait fermer les yeux sur ce comportement, voire l’encourager, et qu’on peut y voir une tentative de faire porter à l’extérieur le coût du Great Firewall
- En Chine, la collecte de contenu est autorisée, et même si elle est bloquée depuis l’extérieur, cela ne pose pas de problème du point de vue du CCP ; en revanche, cela impose une charge aux autres pays et aux sites qui essaient de bloquer ces accès
Mesures de blocage au niveau du pare-feu
- L’auteur a ajouté lui-même les blocs réseau de Tencent aux règles de pare-feu badbots
- Exemples :
43.130.0.0/18,101.32.0.0/20,150.109.96.0/19 - Plus de 40 blocs réseau ont été ajoutés au total ; cela ne couvre pas l’ensemble des IP détenues par Tencent, mais inclut plus de 476 590 IP uniques
Conclusion et comparaison
- L’auteur résume cette situation par une réalité : « sur Internet, on ne peut plus avoir de belles choses »
- Au-delà du simple blocage de trafic de bots, c’est un exemple qui montre l’érosion de la confiance dans l’écosystème Internet et l’inévitabilité des réponses défensives
6 commentaires
En réalité, l’idée d’une menace chinoise est depuis longtemps devenue une réalité dans d’autres domaines, et maintenant la Chine commence même à menacer la pérennité même de l’ensemble de l’écosystème Internet.
Il ne s’agit pas simplement de propos fondés sur un sentiment de haine ou un biais politique : il semble important que beaucoup comprennent que cela devient réellement une réalité.
Pourquoi, à chaque fois qu’on regarde de plus près ce genre d’incidents, on tombe sur le PCC...
Ouah... c'est vraiment génial...
Génial..
Encore la Chine.
Avis Hacker News
En développant un crawler web, j’ai essayé de le rendre aussi respectueux que possible. Il vérifie strictement
robots.txt, explore lentement, indique clairement son identité dans la chaîne User Agent et n’utilise qu’une seule adresse IP. Pourtant, j’ai fini par rencontrer toutes sortes d’astuces anti-bot appliquées au fichierrobots.txtlui-même. Récemment,robots.txtse téléchargeait si lentement, comme lors d’une attaque slow loris, que je le traitais par erreur comme un 404 et continuais à crawler. Après cette expérience, j’ai modifié le code pour traiter tout timeout commeDisallow /. Ironiquement, même en essayant de bien respecter les règles, on se retrouve à écrire du code pour détecter les outils anti-botÇa me fait penser à quelqu’un qui cache sa sonnette pour empêcher les voleurs d’entrer
Comme dans les applications serveur, côté client aussi, si l’autre partie agit de façon malveillante ou incorrecte, on coupe simplement la connexion TCP sans bruit. Il faut alors que l’autre gaspille des ressources pendant un moment avant de comprendre ce qui se passe
Je pense qu’il est très possible que ce ne soit pas intentionnel. Les bots malveillants qui ne respectent pas les règles de
robots.txtne téléchargent de toute façon même pas le fichier, donc il peut s’agir d’une erreur ou d’incompétence plutôt que de malveillanceJ’ai l’impression que les sanctions qui ne punissent que ceux qui essaient de respecter les règles sont au contraire contre-productives
J’apprécie beaucoup l’effort pour bien respecter les règles. Restreindre l’accès à
robots.txtpeut être une erreur, mais comme certains crawlers y trouvent des pages encore plus intéressantes, le ralentir peut aider à éviter rapidement certains problèmes. Au final, ce genre de méthode bloque des informations utiles aux bots et les ralentit, et du point de vue de l’exploitant du site, les dommages causés par les bots malveillants font qu’il ne peut pas vraiment se permettre de distinguer soigneusement les bots honnêtes des autresJe me demande ce que les sites web gravement affectés par les bots ont en commun. J’ai hébergé chez moi un serveur web pendant des années sur un TLD en
.com, avec un bon classement Google sur des mots-clés liés, sans aucune configuration spéciale de blocage de bots sur le routeur ou le serveur. Par curiosité, j’ai déjà compté les requêtes des bots, mais la plupart se contentent de scans de ports ou de récupérer la page d’index, et suivent rarement les liens chargés dynamiquement. Que ce soit à l’époque d’Apache 2 ou aujourd’hui avec plusieurs sites sous Axum, je n’ai jamais vu d’impact notable des bots. Je me demande si cela vient du listing de répertoire, et j’aimerais bien une explicationJ’ai l’impression que beaucoup de gens très intelligents s’obsèdent excessivement sur les problèmes de web scraping. À moins que l’activité des bots ne cause réellement une charge énorme ou des incidents sérieux sur un site — il peut bien sûr y avoir des exceptions — la plupart du temps, ce n’est qu’un jeu stérile de capture du drapeau. La différence ici, c’est qu’on ne trouve jamais le drapeau adverse et qu’on ne perd que du temps. À mon avis, la meilleure réponse consiste à construire un produit web rapide et bien conçu, capable d’absorber une diffusion croissante de participants difficiles à identifier même s’ils génèrent de la charge. En pratique, cette approche améliore aussi énormément la satisfaction des vrais utilisateurs
D’après mon expérience, il est possible que vous ne mesuriez pas la gravité du problème. Dans mon précédent poste, j’étais responsable des performances applicatives d’une web app : une partie des utilisateurs était extrêmement rapide, mais la majorité était lente. En analysant les logs de performance, nous avons constaté que 60 % de toutes les requêtes provenaient de bots connus, sans même compter les bots bizarres. Certaines entreprises allaient jusqu’à lancer des attaques DoS contre le service, et le site est déjà tombé à cause de cela. Le problème, c’est que les bots ne récupèrent pratiquement que des réponses mises en cache, si bien que les conversations des vrais utilisateurs sont constamment évincées du cache LRU. Certains bots rescrapent toutes les pages visitées toutes les quelques minutes, d’autres augmentent leur throughput jusqu’à ce que le service ralentisse. Parfois, ils essaient même d’exécuter du JavaScript et de soumettre des formulaires. Googlebot est le seul à se comporter poliment. Même le bénéfice tiré des bots est presque nul, avec par exemple 40 % du trafic entrant réel concentré sur une seule URL. Ce que nous avons compris trop tard, c’est que beaucoup de ces bots servaient à la collecte de données pour les premières entreprises d’IA
Un ami exploite une petite instance gitea publique, utilisée uniquement entre amis. Pourtant, elle reçoit des milliers de requêtes de bots chaque heure. Même si cela n’affecte pas directement le service, cela ressemble au minimum à du harcèlement
Pour construire un produit web rapide, j’obtiens mes données en les payant au prix fort. Donc bloquer ce genre d’entités n’est pas une perte de temps : cela permet concrètement d’économiser de la bande passante et des coûts serveur. Grâce à cela, les vrais clients bénéficient des mêmes avantages sans aucun inconvénient, même si le contenu n’est pas scrapé. Je ne comprends pas la logique de ceux qui ont l’impression d’être exploités
Je dirais que c’est moins un « capture the flag » qu’un jeu de tape-taupe. D’après mon expérience personnelle, dans les forums où l’on essaie d’identifier et de bloquer les « mauvais bots », il en apparaît toujours davantage, sans fin
Nous sommes nombreux ici à être intelligents, mais aussi à avoir tendance à trop nous focaliser sur les problèmes techniques. Si on ne fait rien, ça continue à nous trotter dans la tête ; si on bloque au moins quelque chose, c’est un peu moins agaçant
Je suis toujours surpris de voir combien de personnes sur Hacker News prennent
robots.txtau sérieux. C’est assez impressionnant de voir autant de bonnes intentions. Maisrobots.txtn’est pas une solution réelle. Encore faut-il que les gens sachent ce qu’estrobots.txtet ajoutent dans leur crawler le code qui le vérifie, ce qui introduit de la complexité. Je me demande s’il existe d’autres solutions pratiques. On parle depuis longtemps de « micropaiements » ou de « grand arbre de Merkle pour vérifier l’identité réelle », mais rien de tout cela n’a jamais réellement été mis en œuvreJe doute qu’il existe beaucoup de développeurs de bots qui ignorent
robots.txt. Il y a surtout des gens qui s’imaginent que leur projet est un cas spécial autorisé à ignorer les règles de tout le monderobots.txtn’a aucune force juridiqueNous voyons aussi ce type de schéma de bots dans nos logs. C’est assez agaçant, mais au moins ils s’identifient comme bots et le trafic réel reste faible. La majorité du trafic vient plutôt de bots qui se font passer pour de vrais navigateurs, ou de bots venant de plusieurs IP au Brésil et en Asie. Comme j’ai essayé toutes sortes de choses cette dernière semaine pour bloquer les bots, je partage une expérience qui peut être utile.
Les requêtes arrivent quelques fois par jour depuis des centaines d’IP, mais toutes se font passer pour de vrais UA
Ils envoient rarement une URL de referrer, mais les bots Huawei Cloud en envoient parfois une aussi, même si leur trafic est faible
Ma principale tentative a consisté à limiter la bande passante des URL contenant
id=à1Kb/s, en espérant qu’ils abandonneraient en devenant trop lents, mais les bots s’en moquent et continuent à requêterIls se sont aussi adaptés aux connexions keep-alive, donc j’ai carrément désactivé le keep-alive sur
/cgit/, mais ils monopolisent quand même toutes les connexionsLa méthode actuelle consiste à n’autoriser les URL contenant
id=que si elles comportent la chaîne de requêtenotbot, et s’il n’y a pas de referrer, j’affiche un message403expliquant aux utilisateurs légitimes d’ajouter le paramètrenotbot. Cette méthode a réduit la charge et amélioré les connexions des utilisateurs légitimes, mais les bots continuent quand même à envoyer des requêtes et ne reçoivent que des403En conclusion, j’ai l’impression qu’il ne reste que deux options : des méthodes ad hoc spécifiques à chaque site, ou déléguer cela à quelqu’un qui dispose de ressources suffisantes, comme Cloudflare. Les solutions standard de blocage des bots ont des limites, parce que les acteurs bien dotés peuvent soit les contourner, soit en absorber le coût
On peut aussi bloquer en amont avec un
403sur des sous-chaînes d’UA peu utilisées comme MSIE 3.0 ou HP-UX. Ensuite, on agrège les logs403pour bloquer séparément les ASN problématiques, et on continue ce jeu de tape-taupeJ’utilise des logiciels de la famille Bernstein publicfile de djbwares. J’y ai aussi ajouté des outils static GEMINI UCSPI-SSL, et j’interdis à la fois les fragments et les paramètres de requête dans les URL demandées, en reprenant une idée issue de la spécification GEMINI. La logique qui les interdit dans GEMINI peut s’appliquer telle quelle aux services HTTP statiques. Dans la configuration du serveur, gérer correctement les paramètres de requête obligerait à créer séparément toute une série de noms de fichiers atypiques, ce qui n’est pas réaliste. Grâce à cette idée, les tentatives d’exploitation de vulnérabilités CGI ou PHP n’atteignent même pas le système de fichiers : elles sont filtrées dès l’étape de découpage de la requête. Je recommande donc aux exploitants de sites statiques de bloquer eux aussi les paramètres de requête, comme GEMINI. Évidemment, cela ne vaut pas si l’on veut réellement utiliser des paramètres de requête sur un site statique
À un moment, je me suis demandé s’il serait réellement possible de fonctionner avec des plages d’IP en liste blanche. J’imagine aussi une approche entretenue par la communauté, à la manière des listes adblock
Malheureusement, les bots les plus respectueux utilisent justement des IP stables, tandis que les acteurs malveillants passent à tout moment par des proxys résidentiels. Si on bloque les IP de proxys résidentiels, on nuit à de vrais utilisateurs, et les acteurs malveillants iront immédiatement ailleurs. Pour avoir eu affaire à des milliers d’IP réelles, je peux dire qu’on ne peut pas trancher sur la seule base d’informations IP : il faut des signaux supplémentaires
L’entreprise derrière Pokémon Go a aussi tenté cette méthode juste après le lancement pour empêcher le scraping. Ils ont divisé les IP en trois catégories : liste noire (Google Cloud, AWS, etc.), IP non fiables (résidentielles) et liste blanche (IPv4 normales, etc.). Au début, cela a filtré les principaux scrapers, mais le plus gros d’entre eux contournait le système en exploitant une ferme de modems. Résultat : les utilisateurs ordinaires ont abandonné le jeu faute de carte, tandis que les joueurs hardcore ont au contraire augmenté, en payant, leur usage des scrapers. Au final, la charge sur les serveurs a encore augmenté. À mes yeux, c’était une des nombreuses mauvaises décisions prises par Pokémon Go
Beaucoup d’entreprises américaines appliquent déjà cela. Mais lorsqu’elles continuent à facturer sans offrir de moyen de résilier depuis l’étranger, c’est franchement déraisonnable
Il n’est pas nécessaire de choisir les listes blanches et noires de façon binaire. L’essentiel du trafic se situe dans une zone grise. Si une IP mise en liste blanche présente ensuite des signes anormaux, il faut la retirer de la liste blanche, l’annoncer, être notifié, puis coordonner mutuellement la résolution du problème, ce qui est en pratique très complexe. Une liste blanche n’est vraiment efficace qu’entre partenaires ayant une relation de confiance. Les listes noires sont utiles pour bloquer les adresses problématiques, ou bien la CIA, la Russie, la Chine ou des fournisseurs cloud. L’approche réaliste consiste à ne placer en liste blanche que des hôtes internes d’entreprise ou d’autres environnements disposant d’un système anti-abus robuste
Je travaille sur une liste blanche positive de bons bots avec le projet open source GoodBots. Les PR sont les bienvenues
J’utilise une méthode qui consiste à ajouter un en-tête personnalisé à toutes les requêtes, puis à bloquer toutes les autres
Côté externe, j’utilise le proxy Cloudflare, et en interne je place Crowdsec et Modsecurity CRS devant Traefik. Après réglages pour réduire les faux positifs, cela fonctionne de façon très stable. Les IP temporairement bloquées et les IP signalées sont envoyées à Crowdsec, puis publiées en logs sur un canal Discord. En moyenne, je bloque chaque jour plusieurs dizaines d’IP différentes. D’après ce que je constate, les tentatives d’accès à des ressources privées ou les recherches de CVE proviennent bien plus souvent d’IP américaines que d’IP chinoises. Je ne me soucie pas du crawling de contenu public ; tout le reste n’est accessible que via SSO ou sur l’intranet. Il est plus efficace de bloquer les tentatives d’exploit ou de flood elles-mêmes que de bloquer certains pays
Une approche comme Crowdsec est séduisante, mais je considère qu’envoyer tout le trafic du serveur à une entreprise privée représente un risque important
Les tentatives d’attaque sérieuses seront de toute façon déjà stoppées par quelque chose comme le WAF de Cloudflare
Beaucoup d’immeubles d’habitation ne peuvent sortir vers l’extérieur qu’avec quelques adresses IP (Carrier-grade NAT)
Plus de la moitié de mon trafic provient de Bing, Claude et des bots de Facebook. Ils ne représentent pas l’essentiel du trafic, mais ils monopolisent les ressources serveur et deviennent la principale cause des ralentissements du site quand cela se produit ; l’IA, Microsoft et Facebook ignorent souvent le simple bon sens. La Chine et d’autres sources ne représentent qu’une partie du trafic malveillant ; le vrai problème, ce sont les entreprises américaines qui ignorent
robots.txtou les limites de débit DNS