J'ai un modeste serveur Gemini. Le protocole Gemini qui est antérieur à l'assistant IA de Google du même nom a été conçu contre le « pourrissement du web », et par un malheureux hasard Google a eu l'idée d'utiliser ensuite le même nom pour son service, rendant d'autant plus difficile les recherches sur le protocole et entretenant une petite confusion. Quelle ironie ! Niveau "marketing", pour le protocole, c'est devenu absolument nul, mais je ne pense pas qu'ils changeront le nom à l'avenir.
Pour faciliter la vie des internautes, et aussi pour ouvrir les informations contenue sur un serveur gemini, en attendant que le protocole Gemini conquiert un jour le monde, il est courant de rajouter une passerelle web, qui transcrit les pages et les rend lisible depuis n'importe quel navigateur. J'ai installé htmgem qui fonctionne plutôt bien.
=> https://gmi.sbgodin.fr/htmgem/docs/installation-fr.gmi
Mes pages qui fonctionnaient correctement on finit par afficher ces derniers jours une erreur 500, je n'ai pas trop analysé ce qui s'est passé, mais après consultation rapide des logs et installation de php8.2-mbstring, qui n'était pas présent, cela a refonctionné. Il aurait fallu étudier si c'est lié à une erreur lors d'une mise à jour, ou si c'est à cause d'une intrusion (je n'ai rien remarqué, j'ai fail2ban et la configuration de base de yunohost), quoi qu'il en soit, cela m'a poussé à remarquer dans les logs d'accès aux pages qu'il y avait une quantité de bot IA qui récupéraient de manière aggressive et très récurrente mes pages, bouffant ma bande passante par la même occasion.
Par exemple :
216.73.216.140 - - [06/Nov/2025:13:34:19 +0100] "GET /gemlog/2022-09-18.gmi HTTP/2.0" 200 3057 "-" "Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)"
Le bot Amazon notamment allait scanner chaque jour les mêmes pages. Je n'ai pas envie de cela.
Il y a aussi des tentatives de récupération de fichiers qui n'existent pas, probablement pour scanner des failles de sécurité :
4.216.107.25 - - [06/Nov/2025:14:25:08 +0100] "GET /file2.php HTTP/1.1" 301 162 "-" "-"
4.216.107.25 - - [06/Nov/2025:14:25:08 +0100] "GET /file2.php HTTP/1.1" 404 27 "-" "-"
4.216.107.25 - - [06/Nov/2025:14:25:08 +0100] "GET /vee.php HTTP/1.1" 301 162 "-" "-"
4.216.107.25 - - [06/Nov/2025:14:25:08 +0100] "GET /vee.php HTTP/1.1" 404 27 "-" "-"
En me renseignant un peu, j'ai vu qu'évidemment certains robots ia ne respectent pas la directive robots.txt, mais il y a des idées lorsqu'ils s'identifient avec un user-agent déclaré :
=> https://rknight.me/blog/blocking-bots-with-nginx/
=> https://phpc.social/@stefanzweifel/112608837688404741
Faute de mieux, j'ai donc rajouté dans mon fichier de configuration nginx ces informations :
/etc/nginx/conf.d/site.d/my_capsule.conf
location = /robots.txt {
alias /var/www/site/robots.txt ;
}
location / {
# Path to source
alias /var/www/my_capsule/www/;
# Default indexes and catch-all
index index.gmi index.php index.html;
if ($http_user_agent ~* (AdsBot-Google|Amazonbot|anthropic-ai|Applebot|Applebot-Extended|AwarioRssBot|AwarioSmartBot|Bytespider|CCBot|ChatGPT-User|ClaudeBot|Claude-Web|cohere-ai|DataForSeoBot|Diffbot|FacebookBot|FriendlyCrawler|Google-Extended|GoogleOther|GPTBot|img2dataset|ImagesiftBot|magpie-crawler|Meltwater|omgili|omgilibot|peer39_crawler|peer39_crawler/1.0|PerplexityBot|PiplBot|scoop.it|Seekr|YouBot|dotbot|HaloBot|Barkrowler|babbar|Baiduspider|amazon|bot)) {
return 404;
}
J'ai mis une erreur 404 (page absente) au lieu de la 403 préconisée (forbidden, accès interdit), car je me suis dit que cela pouvait mettre la puce à l'oreille aux robots si on leur bloque directement l'accès.
J'ai aussi déclaré le location = /robots.txt avant la racine, dans le cas où des robots respecteraient les directives de ce fichier (on peut toujours rêver), ils peuvent y accéder, sinon cela aussi serait caché.
J'ai trouvé une méthode encore plus radicale ici :
=> https://melkat.blog/p/unsafe-pricing
où un fichier de 10 Go est renvoyé lors de l'accès aux pages. J'ai donc remplacé le "return 404" par :
return 301 https://hil-speed.hetzner.com/10GB.bin;
Mais je ne pense pas que cela soit la meilleure idée, en consultant les logs ce matin, j'ai vu qu'un robot amazon était bien tombé sur le 301 :
18.214.238.178 - - [12/Nov/2025:07:41:51 +0100] "GET /cyoa/section53.gmi HTTP/1.1" 301 162 "-" "Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; Amazonbot/0.1; +https://developer.amazon.com/support/amazonbot) Chrome/119.0.6045.214 Safari/537.36"
et 3 minutes plus tard, avec une autre ip et un identifiant similaire, mais en omettant "Amazonbot" dans l'user-agent, la même page avait été récupérée quand même :
3.230.224.12 - - [12/Nov/2025:07:44:19 +0100] "HEAD /cyoa/section53.gmi HTTP/1.1" 200 0 "-" "Mozilla/5.0 AppleWebKit/605.1.15 (KHTML, like Gecko) Chrome/139.0.0.0 Safari/605.1.15"
C'est peut-être juste une coïncidence, mais je pense qu'amazon triche à ce niveau.
C'est de toute façon un fait avéré que certains "mentent" sur leur user-agent, comme démontré ici :
https://rknight.me/blog/perplexity-ai-is-lying-about-its-user-agent/
Quoi qu'il en soit, on peut trouver une liste des IA particulièrement aggressives ici, cela peut donner une idée de filtrage à essayer d'utiliser : https://github.com/ai-robots-txt/ai.robots.txt/tree/main
Sur un site j'ai donc utilisé la redirection 404 et sur un autre la redirection vers le fichier de 10 Go, on verra ce que ça donne au final, si une méthode est mieux que l'autre ou si c'est peine perdue…
Si vous avez de meilleures idées ou des réflexions à ce sujet, n'hésitez pas :)
# Intéressant
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 6 (+3/-0).
Intéressant. Mais je doute qu'une redirection même vers un truc énorme change quoi que ce soit : ces machins sont intéressés par du texte. Une redirection, ça ajoute juste une URL à la liste des pages qu'ils connaissent déjà non ?
Est-ce qu'il n'existe pas des projets pour envoyer du contenu bidon spécifiquement destiné à pourrir les LLM par exemple ?
[^] # Re: Intéressant
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 10 (+7/-0).
Habtiuellement on met plutôt une gzip bomb: une réponse avec un content-encoding gzip, et un contenu construit pour être assez petit, mais se décompresser en un très très gros fichier. Avec gzip, un fichier de 100Mo se décompresse en 100Go, avec brotli, on peut faire encore mieux, un fichier de 78Ko qui se décompresse en 100Go par exemple.
Cela va occuper le CPU et la mémoire du robot pendant quelques temps, pour rien.
L'idée étant de rendre le scrapping du site encore moins rentable qu'il ne l'est déjà, en gaspillant les ressources du scrapper, et pas celles du serveur web. Avec un fichier non compressé, on gaspille les deux (enfin dans l'exemple ici on gaspille celles du scrapper et celles de Hetzner, qui n'avait rien demandé).
[^] # Re: Intéressant
Posté par Nicolas Boulay (site web personnel) . Évalué à 10 (+8/-0). Dernière modification le 12 novembre 2025 à 15:12.
J'ai lu aussi un article, ou il détectait des pattern (genre une IP qui va aller chercher des blame de plusieurs projet sur un git). L'idée est de détecter une IP qui va fouiller dans plusieurs pages rarement accéder. Il blacklistait tout ensuite. De mémoire, il arrivait à plusieurs millions d'IP bloqué.
L'enfer des robot IP est qu'il passe aussi par des lib embarqués dans application mobile (!), il utilise les mobiles comme proxy.
il y aussi la simple detection de javascript : https://fxgn.dev/blog/anubis/
leur générer du bullshit infini : https://maurycyz.com/misc/the_cost_of_trash/
"La première sécurité est la liberté"
[^] # Re: Intéressant
Posté par MicP . Évalué à 4 (+3/-0). Dernière modification le 12 novembre 2025 à 15:48.
Peut-être avec un pot de miel pour LLM : LLM Honeypot Project
… et dans ce royaume, ceux qui y voient un peu plus clair sont parfois très mal vus.
[^] # Re: Intéressant
Posté par alberic89 🐧 . Évalué à 6 (+5/-0).
Ça existe :
https://iocaine.madhouse-project.org/
L'informatique n'est pas une science exacte, on n'est jamais à l'abri d'un succès
[^] # Re: Intéressant
Posté par zurvan . Évalué à 4 (+2/-0).
ça semble intéressant, mais je n'arrive pas à comprendre si on place ça juste pour pourrir les IA, ou si on peut l'interfacer avec un site existant (probablement), et le cas échéant, comment mettre ça en place facilement avec une installation sous yunohost… à suivre…
Rappel important : vos amis qui se sont retournés contre vous parce que la TV leur a dit de le faire : ils le feront encore.
[^] # Re: Intéressant
Posté par zurvan . Évalué à 4 (+2/-0).
la redirection remplace la page que l'IA connaît actuellement (il doit avoir une base de donnée des pages déjà consultées puisqu'elle arrive directement dessus) par une redirection vers un fichier de 10 go. Si elle continue le chargement, cela va lui faire télécharger inutilement un fichier, à supposer effectivement qu'elle aille au bout. Je ne suis pas certain qu'il n'y ait que le texte qui les intéresse, les trucs genre SEO récupèrent aussi des binaires et des pdf. J'ai récemment eu "petalsearch.com" qui semble lié à Huawei qui procède de même.
Rappel important : vos amis qui se sont retournés contre vous parce que la TV leur a dit de le faire : ils le feront encore.
[^] # Re: Intéressant
Posté par devnewton 🍺 (site web personnel) . Évalué à 6 (+3/-0). Dernière modification le 14 novembre 2025 à 14:52.
Tu peux leur envoyer une copie du flURSS de linuxfr.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
# code erreur HTTP
Posté par BAud (site web personnel) . Évalué à 5 (+4/-1).
Le 404 n'est pas approprié, vu que la page existe mais pas pour une IA ;-)
Dommage, il n'y a pas (encore) de code HTTP correspondant pour rejeter une IA (ce qui serait discriminatoire envers les IA).
Perso, j'aurais plutôt utilisé le 418 pour voir si l'IA s'en sort à faire du thé.
Sinon, il y a le 444 pour indiquer que tu ne souhaites pas donner de réponse, même si j'aurais aussi regardé du côté des codes 5xx pour indiquer un comportement côté serveur (rejet des IA).
[^] # Re: code erreur HTTP
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 7 (+4/-0).
Je ne comprends pas cette précision explicite du caractère discriminatoire, dans la mesure où c'est une évidence : il est ici question de traiter différemment les humains et les IA, ce qui est par définition une discrimination.
Est-ce pour suggérer que ce serait mal, dans la mesure où le terme « discrimination » est chargé d'une connotation négative ? (Connotation regrettable à mon avis, dans la mesure où une discrimination peut être justifiée, assumée et tout à fait souhaitable, par exemple lorsqu'il s'agit d'appliquer de tarifs réduits selon des critères particuliers d'âge, de ressources, de situation familiale ou que sais-je encore.)
[^] # Re: code erreur HTTP
Posté par BAud (site web personnel) . Évalué à 2 (+2/-2).
2 négations font neutre, balle au centre ;-)
cela annule le jugement de valeur des IA à « rejeter » (ce qui me semble légitime, ou en tout cas leur octroyant un traitement de faveur, pour leur apporter de l'information de qualitaÿ bien sûr)
toi aussi tu fais partie de la Team1erDegré ? o_O
[^] # Re: code erreur HTTP
Posté par zurvan . Évalué à 4 (+2/-0).
je ne comprends pas ta remarque. La page existe effectivement et est servie pour un navigateur "normal" (mais qu'une IA peut usurper), cela affiche une erreur 404 seulement pour les user agents d'IA, dans le but de les tromper (comme si la page avait disparue ou que le site avait une erreur) et qu'elles ne trouvent pas d'autres liens. Si on bloque avec un 403, le bot risque de modifier son user-agent pour en savoir plus.
Rappel important : vos amis qui se sont retournés contre vous parce que la TV leur a dit de le faire : ils le feront encore.
[^] # Re: code erreur HTTP
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 8 (+5/-0).
Moi j'ai mis un 429 (too many requests) qui m'a semblé approprié (IA ou pas, je surveille les statistiques du site une fois de temps en temps et je bannis des range d'IP à la main si ils génèrent trop de requêtes).
# Erreurs
Posté par barmic 🦦 . Évalué à 5 (+3/-0).
Tu peut tracker les débits de requêtes et ban l’IP un certain temps, non ?
Je suis pas encore passé à la partie WAF, mais mon serveur perso j’ai fais en sorte que si tu envoi un paquet n’importe où de bizarre (c’est dire ailleurs que sur les services que j’expose), tu prends un ban de 31 jours (et j’ai ban de manière statique les /24 dont beaucoup d’IP génèrent du trafic. J’ai aussi mis mon serveur SSH uniquement sur IPv6 et si tu envoi un paquet en IPv4 sur le port 22, tu prends le ban de 31 jours.
Je me demande si passer en IPv6 ne réglerais pas le problème. Est-ce que tu pense qu’ils sont venu à toi par ta notoriété ou parce qu’ils scannent tout IPv4 ? Scanner les noms de domaines me parait « un peu » compliqué.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Erreurs
Posté par zurvan . Évalué à 3 (+1/-0).
pour le ssh j'ai mis un port personnalisé, cela limite les tentatives.
je ne sais pas, possible que j'ai posté un lien quelque part, ou dans un moteur de recherche à un moment donné. Ce qui est étrange c'est qu'en faisant une recherche google sur un truc précis, je suis tombé sur une page de mon site qui n'a aucun lien en page d'accueil ou ailleurs, c'est un brouillon de blog non publié. L'option autoindex on; est activé, mais les pages non publiées sont "cachées" derrière un index.
Dans l'exemple de fichier nginx, j'ai rajouté un |bot à la fin pour bloquer tous les user-agent avec le mot bot dedans, mais cela n'est pas forcément pertinent si on souhaite référencer son site de manière classique, là j'ai vu que cela avait renvoyé la redirection 300 à DuckDuckBot, j'aime bien ce canard :)
Rappel important : vos amis qui se sont retournés contre vous parce que la TV leur a dit de le faire : ils le feront encore.
[^] # Re: Erreurs
Posté par Voltairine . Évalué à 3 (+1/-0).
C'est bien plus efficace (et plus sécurisé) de mettre le serveur SSH en écoute uniquement sur IPv6. Tu vas passer de milliers de tentatives venant de bots essayant des combinaisons utilisateur mot de passe triviale, à pratiquement aucune.
Il y a bon nombre de robots qui n'ont pas « bot » dans leur nom. Mieux vaut faire un filtrage par liste blanche en autorisant uniquement certains moteurs de recherche, ou une liste noire de user-agent suspects (à mettre à jour régulièrement) spécifiquement interdite, par un robots.txt (ou autre méthode).
https://badbot.org/
[^] # Re: Erreurs
Posté par zurvan . Évalué à 2 (+0/-0).
oui, pour les bot il vaut mieux effectivement les cibler plus finement, je suis d'accord. Merci pour le lien, je vais le rajouter dans les pistes à étudier.
pourquoi pas, en revanche si je suis "bloqué" derrière une connexion ipv4 je souhaite pouvoir accéder à mon serveur si nécessaire. Quoi qu'il en soit, en modifiant le port au lieu du 22 par défaut cela limite les tentatives : si jamais il tombe directement sur le bon port (moins d'1 chance sur 10000), il faudra encore avoir le mot de passe (plus de 10 caractères) ou la clé ssh, et après 4 ou 5 tentatives il y a fail2ban qui va bloquer son ip.
Rappel important : vos amis qui se sont retournés contre vous parce que la TV leur a dit de le faire : ils le feront encore.
[^] # Re: Erreurs
Posté par Benoît Sibaud (site web personnel) . Évalué à 7 (+4/-0). Dernière modification le 13 novembre 2025 à 18:56.
En scannant des IP, tu trouves du TLS et des certificats X.509, avec des noms de domaines. En regardant les logs Certificate Transparency, tu trouves d'autres noms de domaines et sous-domaines. Rajoutes des requêtes DNS pour trouver des serveurs de noms, des serveurs via les enregistrements SPF/DKIM/etc., etc., et aussi d'autres IP (en particulier des IPv6, ou même des IPv4 dans une autre plage IP), plus le DNS inverse (et plus rarement la zone complète). En cherchant dans les moteurs de recherche ou sur des archives du web, tu peux trouver des sous-domaines. Et il y a des moteurs dédiés à la recherche de failles connues ou d'équipements à problèmes. Etc.
Bref c'est moins facile que parcourir l'IPv4 mais c'est pratiqué par des pénibles quand ils sont un peu motivés.
[^] # Re: Erreurs
Posté par barmic 🦦 . Évalué à 4 (+2/-0).
C’est drastiquement plus compliqué ça ne veut pas dire que ça n’existe pas.
Aujourd’hui le premier énergumène qui se croit malin scanne en boucle IPv4. Je bloque des milliers d’IP qui tentent de faire des trucs pour un serveur qui pour le moment n’héberge rien. En IPv6 j’ai les même protections mais j’ai aucune IP bloquée.
Le volume de noms de domaine est tel qu’il devient bien moins probable qu’on vienne te trouver.
Là ça devient de l’attaque ciblée ce qui n’a, il me semble pas grand chose à voir.
Se protéger des scripts kiddies qui balancent leur sauce à l’aveugle sur tout ce qu’ils peuvent trouver n’est pas la même chose que de se protéger d’un attaquant motivé qui t’en veut.
Mon serveur SSH est sur IPv6 pour éviter que les premiers ne saturent ma bande passante avec des tentatives de connexion, il n’accepte des connexions que par clef pour bloquer les second.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
# Coïncidence, je ne crois pas
Posté par seveso . Évalué à 1 (+0/-0).
Je ne vois pas comment on peut imaginer une coïncidence ici, ces 2 requêtes n'ont quasiment aucun point commun. Ou bien j'ai raté un truc ?
Moi par contre, ce qui me parait louche, c'est qu'une requête GET sur /cyoa/section53.gmi puisse retourner un code 301 alors qu'une requête HEAD sur le même URL retourne un 200.
Ça ressemble à un bug dans htmgem ça, on devrait avoir le même code HTTP dans les 2 cas, non ?
[^] # Re: Coïncidence, je ne crois pas
Posté par Colin Pitrat (site web personnel) . Évalué à 4 (+2/-0).
La coïncidence curieuse c'est qu'il a 2 requêtes en 3 minutes à 7:45 sur un site qui, j'imagine, à maximum une dizaine de visiteurs par jour.
La première est rejetée par son filtre car identifiée comme un bot. La deuxième non car, justement, le user agent a changé.
Comme niveau de preuve c'est effectivement minimal et il faut que l'auteur est un sacré a priori pour considérer que l'explication la plus probable est que le bot ait changé son user agent, passe par une autre IP, etc… pour rescraper le site. D'autant qu'il n'y a aucune urgence et que si ils ont un service pour re-scraper les pages rejetées, y'a pas de raison de ne pas queuer plus longtemps.
Mais si ça se reproduit plusieurs fois et que, comparé au traffic usuel du site c'est surprenant, alors ça pourrait commencer à ressembler à ine preuve.
[^] # Re: Coïncidence, je ne crois pas
Posté par zurvan . Évalué à 2 (+0/-0).
oui, tu as bien résumé.
Je maintiens ma théorie, mais je la modifie un peu, je pense qu'Amazon soit scrape le site, se rend compte qu'il y a un blocage, et rescrape depuis une autre ip et avec un autre user agent, soit lance des aspirations de site en parallèle depuis des ip différentes, et ensuite compare. Le site a relativement peu de visite (en dehors des robots)
En tout cas, si j'ai eu ça comme indiqué plus haut à 7h41 et 3 minutes plus tard, le même schéma s'est retrouvé le même jour, à 15h42 et 3 minutes plus tard, toujours sur le même "livre jeu", sur un autre chapitre. Difficile de croire que c'est juste une coïncidence dans ce cas…
Ensuite j'ai eu encore des visites sur ces "sections" du livre jeu, mais plus d'Amazonbot, mais je ne peux pas vraiment savoir si ce sont des visiteurs légitimes ou des bots
Rappel important : vos amis qui se sont retournés contre vous parce que la TV leur a dit de le faire : ils le feront encore.
# Htmgem
Posté par Benjamin Henrion (site web personnel) . Évalué à 3 (+1/-0).
Htmgem, c'est un proxy qui converti a la volée du gmi vers du html?
Si c'est le cas, peut-être considérer de statifier toutes les pages?
https://techrights.org/n/2025/07/27/New_Techrights_Soon_Turns_2_A_Few_Days_Before_the_FSF_Turns_40.shtml
Un site statique doit bien mieux résister aux visites des robots.
[^] # Re: Htmgem
Posté par ploum (site web personnel, Mastodon) . Évalué à 2 (+0/-0).
Perso, c’est ce que je fais : j’écris en gemtext sur mon gemlog, je commit dans git, je push et j’ai un hook qui génère à ce moment là une version HTML de mon billet (et qui génère également l’index et qui génère en fait tout le blog)
https://sr.ht/~lioploum/ploum.net/
Mes livres CC By-SA : https://ploum.net/livres.html
[^] # Re: Htmgem
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 3 (+1/-0).
Ah, un SSG maison :)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Htmgem
Posté par ploum (site web personnel, Mastodon) . Évalué à 4 (+2/-0).
Oui et très très personnel.
Et très mal codé parce que je n’avais rien prévu. J’ai fait un script pour générer le fichier index de ma capsule gemini.
Puis, juste pour voir, j’ai tenté de voir si je pouvais convertir le gmi en html.
Puis j’ai ajouté le support du format mail pour ma newsletter (et ça a certainement le plus dur et le plus long)
Et puis je me suis retrouvé avec « ce truc » qui ne sert qu’à moi mais qui me sert vachement bien !
Mes livres CC By-SA : https://ploum.net/livres.html
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.