[Sécurité] Des bots très sophistiqués avec des IP résidentielles

mickou51 · 4 Octobre 2026

Bonjour,

Je suis administrateur d’un tchat. Vers mi-septembre 2026 et ce matin, j’ai constaté quelque chose d’étrange :

Qu’il y avait plusieurs faux utilisateurs (peut-être un botnet)
Les trucs sont assez intelligents
Ils ont tous la même résolution d’écran (1366x768)
Les IP sont toujours différentes et elles sont sans limite
Les IP ne sont pas bannissables, car ce sont de vraies IP de type : Orange, Free, SFR, Bouygues, Belgacom, de la Suisse aussi…
Ils sont toujours présents en nombre de 3 ou 4 et ils restent connectés environ 10 minutes. Ils envoient que 5 - 10 messages environ quand ils sont connectés
Ils savent reconnaître le meilleur onglet là où les messages privés arrivent
100 % des robots n’ont pas de compte, ils passent tous par l’accès direct sans inscription

J’ai suivi de très près via les logs HTTP afin de les tracer, voici comment ils procèdent :

1) Il se connecte sur la page d’accueil du site (il y a le formulaire directement sur la page d’accueil)
2) Le formulaire semble rempli en 9 secondes environ
3) La connexion se lance
4) Une fois connecté, il arrive à localiser l’onglet là où arrivent tous les messages privés

Voici ce que j’ai constaté :

Vers mi-septembre, j’ai mis un CAPTCHA d’un code à 4 caractères à recopier uniquement pour l’UA « Firefox ». Ils sont incapables de le remplir.
J’ai l’impression qu’il y a un mec ou un humain qui décide ou non d’arrêter son botnet (multi-users). Mi-septembre, j’ai constaté qu’il y a un suspect qui a sûrement entré le code du CAPTCHA, il est resté longtemps, il n’a rien spammé, et il avait une résolution « 1366x768 ». Ensuite, c’est peut-être dans ces moments-là qu’il a arrêté son robot ou ses robots.

J’ai essayé d’imaginer comment il pourrait être créé ce robot, voici mon avis :

On dirait que c’est un ordinateur portable avec comme résolution d’écran 1366x768
Cet ordinateur fait toujours tourner des robots en boucle
Les robots n’ont jamais la même IP lorsqu’ils sont connectés simultanément
Les robots, quand ils se connectent sur le site (ou le tchat), restent seulement 10 minutes et ensuite ils se déconnectent et reviennent avec un nouveau pseudo, une nouvelle IP, un autre user agent, un autre user agent hint. Ils étaient sur Firefox vers mi-septembre, mais ce matin (04/10/26), c’était Chrome et plusieurs autres navigateurs et plusieurs OS. Tous sous la même résolution d'écran.
J’ai modifié le CAPTCHA pour que tous les utilisateurs de tous les navigateurs le reçoivent (tous les no accounts). Ils sont incapables de revenir, ce qui prouve que c’est automatique
On dirait qu’il y a un humain qui pourrait éventuellement localiser ou scraper des éléments HTML, et même dynamiquement, afin de les paramétrer pour y répondre automatiquement plus tard. Donc avant de tout lancer la première fois, il règle des paramètres pour scraper.

Voilà, c’était pour vous prévenir, de faire attention : il y a des bots intelligents qui visitent nos sites, se comportent comme de vrais humains, et ont des IP comme les vrais utilisateurs. Le nombre d’IP n’a pas de limite, et les bots peuvent bosser 2 jours sans interruption.

J'aurais pu faire des tests, comme par exemple afin de voir s'ils ont une « souris qui bouge », par exemple en récupérant les positions de la souris à des intervalles réguliers, ou plein de conneries comme ça, mais j'ai pas très envie de perdre des heures sur des conneries comme ça. Du coup, avec le CAPTCHA dont il faut recopier 4 caractères, ça règle le problème.

Première fois en 16 ans que je vois ça, surtout avec des vraies IP résidentielles.

Voici un exemple de botnet :

[08:02:59] SNotice Client exiting: Lily797 (@lfbn-orl-1-557-253.w86-196.abo.wanadoo.fr) [86.196.253.253]
[08:02:59] SNotice Client exiting: Lindsay78 (@88-186-77-203.subs.proxad.net) [88.186.77.203]
[08:02:59] SNotice Client exiting: Elisa65 (@89-93-9-247.hfc.dyn.abo.bbox.fr) [89.93.9.247]
[08:02:59] SNotice Client exiting: Ines65 (@amontpellier-656-1-267-112.w92-133.abo.wanadoo.fr) [92.133.11.112]
[08:02:59] SNotice Client exiting: Jade81 (@lfbn-gre-1-82-176.w92-157.abo.wanadoo.fr) [92.157.57.176]
[08:02:59] SNotice Client exiting: Livia-cyl (@89-82-249-139.abo.bbox.fr) [89.82.249.139]
[08:02:59] SNotice Client exiting: Lili529 (@lfbn-gre-1-73-232.w92-157.abo.wanadoo.fr) [92.157.49.232]

Ici le botnet, il bug, un peu, car ils se sont tous connectés à 7h52 en même temps, et ils se déconnectent en même temps et ils ont tous la résolution d'écran 1366x768 et ils ont d'autres symptomes encore plus évidents

Les IP sont impressionnantes, c'est de l'infini.

Soyons honnête, mais c'est un botnet comme ça qu'il me faudrait : il se connecterait sur Google, il taperait 300 fois le même mot clé sur Google et cela chaque jour avec le nom du site, et il resterait connecté sur le site 10 minutes... héhé.
Si vous connaissez des prestataires, faites-moi signe en privé.

colonies · 6 Octobre 2026

J'ai installé Cloudflare Turnstile aujourd'hui (c'est "gratuit").
Il n'est pas affiché à tous les utilisateurs, seulement ceux où j'ai déjà un doute. Sur les 426 défis émis dans l'heure qui vient de s'écouler, il n'y en a eu que 76 relevés (soit 15% de défis émis, avec 63 défis non interactifs et 13 interactifs) et 350 non résolus.
Bref, ça dégage pas mal de bots.

Pour ce genre de choses, on est plutôt censés utiliser WAF, mais ça demande de faire passer tout le trafic par Cloudflare, et ça n'est pas quelque chose que je veux faire - et en plus c'est payant.

EUSKAL CONSEIL · 6 Octobre 2026

Pour ma part, j'ai bien aimé utiliser la version payante de Cloudflare, mais avec les modifications faites par le staff d'Hostinger sur le builder, c'est désormais déconseillé. En effet, déléguer entièrement la gestion DNS et le proxy d'un site hébergé sur un builder propriétaire peut entrer en conflit avec leurs propres couches de cache et de routage internes. De toute manière, Hostinger dispose désormais de son propre CDN pour tous les sites faits avec son builder, ce qui rend l'ajout d'un proxy Cloudflare redondant, voire source de bugs.

Malgré tout, on peut tout à fait exploiter l'outil pour mettre en place des règles de pare-feu (WAF) intéressantes et des Workers. Tout l'enjeu est de bloquer les mauvais bots tout en laissant passer les bons, ce qui n'est pas si simple : en pratique, tous les bots de Google ou des moteurs de recherche ne sont pas systématiquement déclarés ou reconnus de manière transparente dans les bases de signatures Cloudflare, ce qui risque de pénaliser votre référencement si les règles sont trop agressives.

Il paraît que c'est en forgeant qu'on devient forgeron!

anemone-clown · 9 Octobre 2026

Pour info, et pour ce que ça vaut, depuis que j'ai bloqué ChatGPT-User en htaccess, le nombre de botnets s'est considérablement réduit. De mon côté, je pense que ce sont des groupes de spoofers qui s'amusent à ça.

Juste un détail : hier, suite à une erreur, ShapBot est passé... 5000 sessions en moins de 8 mn... je corrige, et je refais une erreur 2 heures après (un mauvais jour!

), ShapBot a claqué 1500 sessions en moins de 3 mn! Depuis, c'est quasiment la 1ère ligne du htaccess pour le bloquer !

colonies · 9 Octobre 2026

anemone-clown a dit:
Pour info, et pour ce que ça vaut, depuis que j'ai bloqué ChatGPT-User en htaccess, le nombre de botnets s'est considérablement réduit. De mon côté, je pense que ce sont des groupes de spoofers qui s'amusent à ça.

Juste un détail : hier, suite à une erreur, ShapBot est passé... 5000 sessions en moins de 8 mn... je corrige, et je refais une erreur 2 heures après (un mauvais jour! ), ShapBot a claqué 1500 sessions en moins de 3 mn! Depuis, c'est quasiment la 1ère ligne du htaccess pour le bloquer !

Tu as vérifié que c'était bien lui en croisant avec la liste d’IP officielle ?
https://docs.parallel.ai/resources/shapbot.json

mickou51 · 9 Octobre 2026

Depuis que j'ai créé ce post dimanche dernier, ils sont revenus depuis, c'était mercredi peut-être. Ils sont arrivés dans la nuit et tout s'est arrêté vers 14h30.

Ce soir (vendredi 09 octobre), ils sont de retour. Voici un log http pour un seul bot :

93.12.194.15 - - [09/Oct/2026:18:21:21 +0200] "GET / HTTP/1.1" 200 15887 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/125.0.0.0 Safari/537.36"

Ici, la connexion à la page d'accueil se fait à 18:21:21

93.12.194.15 - - [09/Oct/2026:18:21:26 +0200] "POST /connexion HTTP/1.1" 200 2892
93.12.194.15 - - [09/Oct/2026:18:21:29 +0200] "GET /captcha.php?t=1791562886 HTTP/1.1" 200 5406

A 18:21:26, l'action du formulaire est enclenché. Le captcha s'affiche aussitôt. C'est un captcha dont il faut recopier 4 caractères.

93.12.194.15 - - [09/Oct/2026:18:21:37 +0200] "GET /app/_chat?nick=Liana_3336

Le bot a l'air de recopier le code du captcha avec succès.

Pour le moment, j'ai restreint l'accès à l'application node.js depuis le formulaire sans inscription. Il faut désormais utiliser un compte. Il n'y a plus aucune connexion depuis.

Je n'ai tout de même pas restreint l'accès à 100 %, je teste des méthodes d'accès basées sur des empreintes que les bots n'ont jamais eues, mais que les vrais utilisateurs possèdent, ce sont des éléments classiques.

Pour l'attaque de mercredi, elle était spéciale, car les bots étaient capables d'écrire dans les canaux.

J'ai aussi l'impression qu'ils sont capables de remplacer nos fonctions JavaScript. Par exemple, ils pourraient remplacer une fonction qui leur appartient (exemple : function test() { return true; }), alors qu'une autre fonction porte déjà le même nom sur le site.

Du coup, pour rendre un contournement plus difficile, j'ai remplacé function test() { } par const test = () => { }. J'ai aussi bricolé les réponses "OK" que les API peuvent renvoyer, car un simple "OK" peut être contourné à l'aide d'une fausse URL en local sur une machine. Par exemple, si vous ajoutez 127.0.0.1 api.NotreDomaine.fr dans le fichier hosts, un mec peut contourner la vérification en renvoyant lui aussi un "OK" depuis son propre serveur web local (exemple : Wamp).

colonies · 9 Octobre 2026

Tu as demandé à une IA de te donner un coup de main ?

De ce que je lis, j'ai l'impression que le serveur débloque des choses dans ton JS, et qu'ensuite tu fais confiance à ce que le navigateur envoie. En tout cas que c'était le cas avant et que maintenant tu as "bricolé les réponses OK".
Je ne sais pas ce que ça veut dire, mais pour sécuriser les échanges, il te faut au minimum une clé produite par le serveur et jointe à chaque envoi depuis le navigateur, clé que le serveur vérifie avant de traiter toute donnée.

anemone-clown · Samedi à 08:24

@colonies : oui, j'ai bien vérifié l'IP pour ShapBot...

EUSKAL CONSEIL · Dimanche à 21:42

Bonsoir,

Je lis cette discussion avec intérêt, et j’ai l’impression qu’on peut passer énormément de temps à vouloir filtrer les bots au-delà de ce qu’un bon WAF fait déjà très bien. C'est d'ailleurs ce que j'avais commencé par faire dès la mise en ligne de mon modeste site et ce qui fut à l'origine de mon aventure avec Cloudflare....Pourtant aujourd'hui je vois les choses autrement.

Un exemple concret : j’administre le site WordPress d’une paroisse. Rien de stratégique, a priori aucune cible. En septembre, le WAF a pourtant bloqué 111 menaces, sans aucune intervention de ma part et sans impact sur les performances (environ 6 ms par requête en moyenne). Ce trafic existait sans doute avant, personne ne le voyait, c’est tout. Et comme le site s’est étoffé et est bien plus crawlé cette année, il attire mécaniquement plus de bots, bons comme mauvais. C’est le revers de la visibilité.

Scrapers basiques, scanners de failles, faux user-agents, pics de requêtes : un WAF avec gestion des bots en élimine l’essentiel, et mieux qu’à la main.

Le reste, des bots sur IP résidentielles, dans de vrais navigateurs, qui remplissent un formulaire et résolvent un captcha en 8 secondes, est quasiment impossible à distinguer d’un humain au niveau du réseau. Courir après, c’est une course sans fin, avec en prime le risque de bloquer de vrais visiteurs ou Googlebot.

À mon sens, la vraie question n’est pas « comment bloquer tous les bots ? », mais « qu’est-ce que ce trafic me menace ou me coûte réellement ? »

mickou51 · Dimanche à 22:21

Hier, j'ai mis en place le captcha de Cloudflare Turnstile directement à l'entrée de l'application Node.js pour tout le monde. Puis hier soir assez tard, j'ai fait en sorte que le captcha ne soit pas appelé pour les utilisateurs qui sont identifiés sous un compte membre.
Cette technique est en test actuellement afin de voir si le boulet relance sa sorte de botnet-IA.

Vendredi, j'ai aussi constaté vers 18h, pendant au moins 45 minutes, des pseudos qui venaient avec plusieurs IP différentes, donc c'étaient toujours les mêmes pseudos, mais avec des IP différentes, et il n'y avait pas de spam au début. On dirait qu'à ce moment-là, le mec codait ou configurait un truc pour pouvoir lancer son bot. Ensuite, l'appli Node.js a été bloquée pour les noaccounts, puis il s'est arrêté net.

Je verrai ce que ça donne avec Cloudflare Turnstile, mais ça va, ce truc n'a pas l'air de bloquer les vrais utilisateurs, il n'y a pas de baisse.

C'est l'accès à l'application Node.js (côté client) que je souhaite protéger avant tout.

anemone-clown · Lundi à 09:00

@mickou51 : je suis intéressé par ton retour d'expérience avec Turnstile...

Sur Aquaportail, ça devient un peu fou les botsnet et tout le monde y va de son petit robot d'exploration du site. Juste avec les règles 403 en htaccess, j'ai au moins 40 000 hits bloqués par jour. Il y a 2 ans, c'était 3 000...

colonies · Lundi à 09:13

anemone-clown a dit:
@colonies : oui, j'ai bien vérifié l'IP pour ShapBot...

J'ai vérifié dans mes logs, chez moi il se tient bien : 155 pages pour le jour avec le plus de visites.
Ça m'a quand même décidé à mettre en place un rate-limiter et à le définir à 2 secondes pour ce bot, on ne sait jamais.

mickou51 · Lundi à 18:50

Les robots arrivent quand même à passer avec Turnstile, mais ils sont moins fréquents.
J'ai aussi repéré un autre truc : dans l'application Node.js, il y a forcément des API à l'intérieur, et parfois, il y a la récupération de l'IP dans chaque API avec $_SERVER['SERVER_ADDR']. J'ai constaté que l'IP exécutée en premier pour afficher l'appli n'est jamais la même que celle de l'API principale qui est appelée en JS. Du coup, peut-être que je vais coder un petit truc pour empêcher ce type d'accès avec plusieurs IP.

colonies · Lundi à 21:41

mickou51 a dit:
Les robots arrivent quand même à passer avec Turnstile, mais ils sont moins fréquents.
J'ai aussi repéré un autre truc : dans l'application Node.js, il y a forcément des API à l'intérieur, et parfois, il y a la récupération de l'IP dans chaque API avec $_SERVER['SERVER_ADDR']. J'ai constaté que l'IP exécutée en premier pour afficher l'appli n'est jamais la même que celle de l'API principale qui est appelée en JS. Du coup, peut-être que je vais coder un petit truc pour empêcher ce type d'accès avec plusieurs IP.

$_SERVER['SERVER_ADDR'] est l'IP de ton serveur, pas celle du navigateur de l'utilisateur ($_SERVER['REMOTE_ADDR']).
Mais ça c'est du PHP, et tu parles de Node.js... c'est assez flou comme situation.

mickou51 · Lundi à 22:44

@colonie : ah mince oui c'est bien $_SERVER['REMOTE_ADDR'] que j'utilise. Tout à l'heure pour aller chercher cette fonction sur Google i'ai recherché "php $_SERVER addr", j'ai pris server_addr sans faire attention.
Dans l'application node.js, dans le côté client, il y a des API en PHP pour rejoindre la session.

anemone-clown · Mardi à 12:19

Pour Chrome (et Edge), tu peux aussi tester diverses valeurs supplémentaires:

Code:

$ua = $_SERVER['HTTP_USER_AGENT'] ?? '';
$accept = $_SERVER['HTTP_ACCEPT'] ?? '';
$encoding = $_SERVER['HTTP_ACCEPT_ENCODING'] ?? '';
$header_SEC = $_SERVER['HTTP_SEC_CH_UA'] ?? '';

Avec Chrome, $_SERVER['HTTP_SEC_CH_UA'] ne doit pas être vide (sauf le cas des robots, y compris les officiels, il faut donc les filtrer avant!!!) et les versions indiquées dans le user-agent et secure-je sais plus quoi- (SEC) doivent être les mêmes.
Avec Chrome et Safari, 'gzip' doit être présent dans le encoding...

Bref, vérifier si c'est un humain ou un fake est déjà vraiment très compliqué, mais la plupart des robots (y compris pour le spoofing) respecte ces règles, il faudrait analyser si il y a un mouvement de souris ou un évènement du type pour savoir si c'est vraiment un humain. Et ce dernier cas, c'est uniquement en JS, et ça implique que la page est déjà servie...

@spout : tu confirmes mes propos?

La base consiste quand même à bloquer tous les user-agents très très vieux (plus de 10 ans ou existaient que sur les vieux windows 95 à 8!) ou les "spoofs" évidents (Safari avec une lettre, Opera d'une autre ère, les distributions linux sur 32 bits, etc.)

Code:

RewriteCond %{HTTP_USER_AGENT} (Chrome/([1-9][0-9]?|10[0-9]|110)\.|Firefox/([4-9][0-9]?|1(0[0-9]|1[0-5]))\.|MSIE|Trident/[4-7]|Firefox/[0-9]{2,3}\.[0-9]{2,3}\.[0-9]{2,3}|WebKit/[7-9]|Opera/[1-8]|Safari/([A-Z]|[7-9])|Linux[\x20](i686|null)) [NC]
RewriteRule ^ - [F]

ps: pour Firefox, je démarre à 4, car certains outils de GG utilisent une vieille version en 3x...

spout · Mardi à 13:59

@anemone-clown : oui

mickou51 · Mardi à 17:49

anemone-clown a dit:
il faudrait analyser si il y a un mouvement de souris ou un évènement du type pour savoir si c'est vraiment un humain

Il faudrait cacher quelque chose comme ça dans le code :

JavaScript:

let souris = [0, 0];

document.addEventListener('mousemove', (event) => {
    souris = [event.clientX, event.clientY];
});

souris[0]; // x
souris[1]; // y

Et ensuite, il me faudrait un accès dynamique, par exemple, j'envoie un message au bot avec un début de message, ça doit être quelque chose d'unique, comme : [testsourisxy]. Je fais en sorte qu'il ne s'affiche nulle part avec des "return", etc., mais juste avant le return, il faudrait que ça me retourne un message à l'admin. Du coup, je recevrais le message suivant : souris[0] + " - " + souris[1].
Et je dois appeler cette commande au moins 3 fois en 3 minutes, pour voir si les positions sont différentes, et si ce sont toujours les mêmes, c'est suspect.
Mais c'est long à mettre en place. J'essaierai de le faire, mais aujourd'hui, il n'y a pas eu de bot, car hier, j'ai fait un système pour ne plus qu'il y a plusieurs IP qui exécutent chaque appel aux API par rapport à la page originale

anemone-clown · Mardi à 18:15

@mickou51 : je ne peux pas me permettre avec l'affichage de Pubs. Et de toute façon, pour le JS, la page est déjà servie, c'est donc trop tard...

Je viens d'avoir une discussion avec mon conseiller chez OptiDigital pour les Pubs, il m'a dit de ne pas me préoccuper du trafic généré automatiquement/informatiquement et de ne pas perdre de temps sur ça. Il m'a juste fait intégrer un script SecurePubs de GG pour éviter trop d'appels inutiles chez eux (et accessoirement, accélérer un peu le chargement de certaines pubs).

Il m'explique que les bots les plus récents savent naviguer sur une page : "Actuellement il n'existe pas de solution facile à mettre en place, de notre côté nous pouvons couper la monétisation s' il y a pas activité de l'internaute mais ça ne solutionne pas tous les problèmes et beaucoup contourne ce problème en faisant des bots qui naviguent. "

Bref, j'arrête la lutte... c'est beaucoup trop énergivore! Et comme une partie en anglais va prochainement ouvrir sur mon site, je ne pourrais de toute façon plus filtrer via le langage ou certains autres paramètres des headers.

cthierry · Mercredi à 07:59

Pour ma part, j'ai résolu une partie du problème (parfois jusqu'à 80 - 100 000 accès par jour pour les botnets) en mettant en place une gestion fine des useragent, couplée à un cookie de session particulier, un filtre sur les versions des navigateurs avec une pincée de challenge JavaScript (comme un calcul mathématique rapide ou le rendu d'un canvas léger) en moins de 10 secondes pour prouver que le navigateur est un vrai navigateur humain et pas un simple bot HTTP headless ou cURL, ou le frigo connecté de Brigitte. J'ai même eu le luxe de remettre à zéro ma liste (plage) d'IP bloquées (plus de 80 ko), car à force de tailler dans la masse, je bloquais aussi les VPN. Et comme de plus en plus de personnes passent par un VPN...

Bon, par contre, comme le dit si bien anemone-clown, c'est hénergivore et pratiquement sans fin.

anemone-clown · Mercredi à 08:48

@cthierry : oui, c'est sans fin...

Ensuite, il y a quand même quelques plages d'IP à bloquer, notamment celles de UAB code2000 ou Bite Code (lithuanie, mais avec des serveurs partout dans le monde) et Cox Communications (Seychelles, idem avec des serveurs dans le monde : donc faire attention à bien repérer le nom quand on vérifie une IP). Le problème est : leurs IP changent de temps en temps, il faut donc remettre à 0 ces blocages.

Si certains ont ont une liste positive de robots autorisés (Google, bing, etc.) pour fixer une variable d'environnement nommée SKIP_TOUT à 'oui' (je sais, ce n'est pas un simple 0 ou 1, mais c'est fait exprès), ces deux règles en htaccess en bloquent déjà pas mal:

Code:

RewriteCond %{ENV:SKIP_TOUT} ^oui$ [OR]
RewriteCond %{HTTP:Accept-Language} ^(fr|es)
RewriteRule .*    -    [S=5]
RewriteCond %{HTTP:Accept-Language} ^-?$|^en-US,en;q=0\.9$
RewriteCond %{HTTP_REFERER} ^$
RewriteCond %{ENV:GEOIP_COUNTRY_CODE} ^(US)$ [OR]
RewriteCond %{ENV:GEOIP_CONTINENT_CODE} ^(SA|AS|AF)$
RewriteRule ^ - [F]
RewriteCond %{HTTP:Accept-Encoding} ^zstd,gzip,deflate,br$
RewriteCond %{HTTP_USER_AGENT} Macint.*Chrome/14
RewriteRule ^ - [F]

et voici la liste des pays que je bloque préalablement:

Code:

RewriteCond %{ENV:GEOIP_COUNTRY_CODE} ^(AZ|BD|BY|CN|EE|IN|IQ|IR|KZ|LT|LV|NP|PK|RU|SC|SG|UA|UZ|AE)$

(il faudrait les trier par ordre orthographique pour mieux faire -afin de créer une arborescence lexicale pour les RegEx- mais je suis faignant...

il y a l’Ukraine, mais il subsiste beaucoup de spam en provenance de UA, peut être la partie russe qui n'est pas encore modifiée à l'heure actuelle)

WebzineMusik · Mercredi à 11:11

CloudFlare est tout de même une véritable usine à gaz non ?

anemone-clown · Mercredi à 16:47

Pour info, même GG semble faire des erreurs dans ses user-agents :

Code:

Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_3) AppleWebKit/[WEBKIT_VERSION] (KHTML, like Gecko, Mediapartners-Google) Chrome/[CHROME_VERSION] Safari/[WEBKIT_VERSION]

Evidemment, la ligne met la puce à l'oreille... mais l'IP 74.125.150.2 est vraiment du domaine de GG ( https://developers.google.com/crawling/ipranges/special-crawlers.json )

colonies · Mercredi à 18:27

anemone-clown a dit:
il y a l’Ukraine, mais il subsiste beaucoup de spam en provenance de UA, peut être la partie russe qui n'est pas encore modifiée à l'heure actuelle)

Même si la guerre s'arrête et que les zones occupées par les Russes passent au TLD .ru, t'en fais pas, tu verras toujours du bot nuisible avec des IP en .ua.
il n'y a pas eu à attendre que l'Ukraine se fasse envahir pour qu'on y trouve de la cybercriminalité.

Perso, ma liste est bien plus longue, mais je ne les bloque pas systématiquement : que les user-agents dépassés (ou impossibles), les ASN chelous... et Turnstile en bonus.
Après, je me suis mangé un certain nombre de vagues de bots très internationales, ce qui m'amené à considérer l'intérêt de mon site pour des utilisateurs de Kazakhstan, du Kirghizistan, du Népal, de la Barbade, de l'Arabie saoudite, de la Syrie, de Malaisie, de Mongolie, de Serbie, de Colombie, du Honduras...).
Autant dire qu'il est faible.