Derniers messages
Dernier message par Lyne - 09 Juillet 2026 à 22:04:53
Cliquez pour afficher le message
Compte-rendu du point hebdo du 09/07/2026
Zatalyz
Ces dernières semaines, j'ai pris la décision de transférer les mails de Khaganat (et Numenaute) à OVH, le temps que j'ai réellement l'énergie de refaire un serveur mail propre, avec tout ce que ça demande autour. Ce n'est clairement pas une solution que j'apprécie pour le long terme : les MX plan d'OVH dépannent mais souffrent de plein de défauts à mon goût. Mais : c'est fait, et ça va me permettre de rendre mon appart (vu que le serveur était associé à mon ip et donc mon domicile, et que non, ça ne se déménage pas si facilement), ce qui est une bonne chose. Au passage j'ai remis en route Freescout pour Khaganat, même si c'est un choix questionnable pour le moment.
Au final c'est le compte de Numenaute qui a payé les MX plan (5€ pour chaque asso, une seule fois), y'a les sous et le compte était déjà paramétré, j'ai fait au plus simple
Lyne
J'ai envoyé le compte-rendu de l'AG à la préfecture, avec la liste des membres du Collège mise à jour
Merci à celles qui ont relu et corrigé
Et j'ai commencé un article de blog : https://carnets.numenaute.org/p/Blog_AG_2026
Il n'est pas finalisé, et j'aimerais vos avis sur les images que j'ai proposées (à la fois sur leur pertinence / style, et pour un œil critique au cas où y'aurait de l'IA dedans)
Zatalyz
Ces dernières semaines, j'ai pris la décision de transférer les mails de Khaganat (et Numenaute) à OVH, le temps que j'ai réellement l'énergie de refaire un serveur mail propre, avec tout ce que ça demande autour. Ce n'est clairement pas une solution que j'apprécie pour le long terme : les MX plan d'OVH dépannent mais souffrent de plein de défauts à mon goût. Mais : c'est fait, et ça va me permettre de rendre mon appart (vu que le serveur était associé à mon ip et donc mon domicile, et que non, ça ne se déménage pas si facilement), ce qui est une bonne chose. Au passage j'ai remis en route Freescout pour Khaganat, même si c'est un choix questionnable pour le moment.
Au final c'est le compte de Numenaute qui a payé les MX plan (5€ pour chaque asso, une seule fois), y'a les sous et le compte était déjà paramétré, j'ai fait au plus simple
Lyne
J'ai envoyé le compte-rendu de l'AG à la préfecture, avec la liste des membres du Collège mise à jour
Merci à celles qui ont relu et corrigé
Et j'ai commencé un article de blog : https://carnets.numenaute.org/p/Blog_AG_2026
Il n'est pas finalisé, et j'aimerais vos avis sur les images que j'ai proposées (à la fois sur leur pertinence / style, et pour un œil critique au cas où y'aurait de l'IA dedans)
Dernier message par Zatalyz - 03 Juillet 2026 à 11:39:06
Cliquez pour afficher le message
Je suis personnellement attachée à la vue à la 3e personne.
Je trouve que c'est plus adapté au JDR. Cela met justement une distance entre "nous" et le personnage. En ce sens, ce n'est pas "je suis la ra ; elle et moi sommes la même personne" mais "j'anime la ra, qui sert de support à raconter une histoire". C'est sacrément clair quand on se retrouve à avoir plusieurs clients, et puis cela aide à mettre en scène le personnage, comme un metteur en scène guiderait une actrice : "un peu plus à gauche ; ha oui, pas mal dans cette position. Essaie voir de te rapprocher de Bidule ? Enlève le chapeau, et il va falloir revoir le maquillage, pas du tout adapté". Il y a un aspect cinématographique à certaines scènes, vraiment délicat à rendre en étant coincé en première personne. D'autant plus en jeu vidéo où on a peut de retour sur son "corps" : il devient facile d'oublier qu'on porte un gros sac dans le dos, ou qu'on a fait une coiffure punk qu'on ne comptait pas assumer au bal de Vaiatua.
Historiquement les jeux vidéos à la première personne sont ceux où la visée est importante, avec le tir en premier lieu ; si bien que pour moi ça reste un peu associé à des gameplay nerveux.
Idéalement, j'adorerais que les deux soient possibles, car je peux comprendre qu'on préfère l'un ou l'autre, ne serait que suivant les phases de jeu. Sur du pvp, c'est certain que la 1ere personne est plus cool ! Si on peut le faire, c'est bien, mais je sais que techniquement c'est un peu chaud de faire ça "bien", et à tout prendre je préfère que les efforts soient mis sur la 3e personne.
Je trouve que c'est plus adapté au JDR. Cela met justement une distance entre "nous" et le personnage. En ce sens, ce n'est pas "je suis la ra ; elle et moi sommes la même personne" mais "j'anime la ra, qui sert de support à raconter une histoire". C'est sacrément clair quand on se retrouve à avoir plusieurs clients, et puis cela aide à mettre en scène le personnage, comme un metteur en scène guiderait une actrice : "un peu plus à gauche ; ha oui, pas mal dans cette position. Essaie voir de te rapprocher de Bidule ? Enlève le chapeau, et il va falloir revoir le maquillage, pas du tout adapté". Il y a un aspect cinématographique à certaines scènes, vraiment délicat à rendre en étant coincé en première personne. D'autant plus en jeu vidéo où on a peut de retour sur son "corps" : il devient facile d'oublier qu'on porte un gros sac dans le dos, ou qu'on a fait une coiffure punk qu'on ne comptait pas assumer au bal de Vaiatua.
Historiquement les jeux vidéos à la première personne sont ceux où la visée est importante, avec le tir en premier lieu ; si bien que pour moi ça reste un peu associé à des gameplay nerveux.
Idéalement, j'adorerais que les deux soient possibles, car je peux comprendre qu'on préfère l'un ou l'autre, ne serait que suivant les phases de jeu. Sur du pvp, c'est certain que la 1ere personne est plus cool ! Si on peut le faire, c'est bien, mais je sais que techniquement c'est un peu chaud de faire ça "bien", et à tout prendre je préfère que les efforts soient mis sur la 3e personne.
Citation de: YannK le 30 Juin 2026 à 12:05:31Cela permettrait aussi de mieux voir les personnages des autres joueuses vu que la caméra serait plus proche d'elles.Là dessus, ça dépend beaucoup plus de la caméra, et justement, en copiant Ryzom, nous avons une caméra très paramétrable. On va même ajouter des options. Quand on est posé tranquillement pour un rp, il est donc assez facile de gérer un bon cadrage, permettant de voir les détails des personnages impliqués.
Dernier message par Lyne - 02 Juillet 2026 à 22:51:08
Cliquez pour afficher le message
Compte-rendu du point hebdo du 02/07/2026
YannK
J'ai posté une question sur le forum à propos de la vue caméra pour le client IRIS, savoir si on était bien à la troisième personne ou si on devait être à la première. je ne me souviens pas qu'on ait acté une décision définitive donc je préférrais que ça soit évoqué avant que je commence à bosser dessus
Et il y a toujours la question sur les noms des services qui est en cours
J'ai aussi organisé un peu quelques éléments pour la suite du client 0.1, sur la forge. Les titres des tickets sont en anglais, mais j'y parle français, donc n'hésitez pas à venir donner votre avis : https://port.numenaute.org/Khaganat-games/Khanat/issues
Et j'ai posté quelques images du travail en cours d'Honora sur la ucikara sur le canal #khanat. Trop tôt pour lui faire des retours, mais ça fait plaisir de voir que ça avance
YannK
J'ai posté une question sur le forum à propos de la vue caméra pour le client IRIS, savoir si on était bien à la troisième personne ou si on devait être à la première. je ne me souviens pas qu'on ait acté une décision définitive donc je préférrais que ça soit évoqué avant que je commence à bosser dessus
Et il y a toujours la question sur les noms des services qui est en cours
J'ai aussi organisé un peu quelques éléments pour la suite du client 0.1, sur la forge. Les titres des tickets sont en anglais, mais j'y parle français, donc n'hésitez pas à venir donner votre avis : https://port.numenaute.org/Khaganat-games/Khanat/issues
Et j'ai posté quelques images du travail en cours d'Honora sur la ucikara sur le canal #khanat. Trop tôt pour lui faire des retours, mais ça fait plaisir de voir que ça avance
Dernier message par YannK - 02 Juillet 2026 à 21:13:16
Cliquez pour afficher le message
Update: Dans la partie caméra du GDD, je parle de 3e personne : https://khaganat.net/wikhan/fr:gamedesign:khanat:camera
Néanmoins je ne me souviens pas si j'ai écrit ça après une discussion où on avait décidé ou si j'ai écrit ça par défaut.
Néanmoins je ne me souviens pas si j'ai écrit ça après une discussion où on avait décidé ou si j'ai écrit ça par défaut.
Dernier message par alcyone - 01 Juillet 2026 à 11:34:36
Cliquez pour afficher le message
Petite news, depuis la charte autorisant pleinement les IA chez Godot elles font un petit pas en arrière : https://godotengine.org/article/contribution-policy-2026/
Le geste est pleinement pour diminuer l'afflue de nouvelles contributions par IA qui coulent les mainteneuses. Elles y prennent conscience que oui accepter l'IA augmente en effet le nombre de "contributions" mais y observent maintenant aussi que ça ne créé vraiment pas de nouvelles contributrices (et la qualité des contributions ne suit pas).
Je trouve personnellement toujours que ce point que l'on trouve couramment dans les chartes IA - "No use of AI to generate substantial pieces of code" - est révélateur d'une incompréhension sur les pratiques courantes : les personnes utilisant couramment l'IA souhaitent pondre du code, massivement, vite, souvent. Ça ne fait aucun sens d'indiquer que son usage ne doit pas être dans cet état d'esprit, qui plus est en étant sur GitHub qui est un réseau social/CV du code : une partie des utilisatrices sont là avec l'IA pour remplir les carrés verts (le diagramme croisant le nombre de commits par jour) et montrer qu'ils commit vers de gros projets Open Source bien installés. De fait, la précédente charte n'a pas suffit une seule seconde à stopper ce genre de comportement, on verra donc pour celle-ci.
Le billet de blog ne dit rien sur les contributrices existantes. On peut cependant noter que la dernière fois que j'ai regardé, elles n'avaient même pas vraiment conscience de l'existence du tag "Assisted by [nom_IA]" et ont ban Claude Code, donc bon, on peut être optimiste ?
___________________________
Sur un autre point, je me retrouve assez dans ce (court) article de Tante sur le rapport à l'usage de l'IA comme source d'information et autorité : https://tante.cc/2026/06/30/trying-to-manufacture-permission/
Le geste est pleinement pour diminuer l'afflue de nouvelles contributions par IA qui coulent les mainteneuses. Elles y prennent conscience que oui accepter l'IA augmente en effet le nombre de "contributions" mais y observent maintenant aussi que ça ne créé vraiment pas de nouvelles contributrices (et la qualité des contributions ne suit pas).
Je trouve personnellement toujours que ce point que l'on trouve couramment dans les chartes IA - "No use of AI to generate substantial pieces of code" - est révélateur d'une incompréhension sur les pratiques courantes : les personnes utilisant couramment l'IA souhaitent pondre du code, massivement, vite, souvent. Ça ne fait aucun sens d'indiquer que son usage ne doit pas être dans cet état d'esprit, qui plus est en étant sur GitHub qui est un réseau social/CV du code : une partie des utilisatrices sont là avec l'IA pour remplir les carrés verts (le diagramme croisant le nombre de commits par jour) et montrer qu'ils commit vers de gros projets Open Source bien installés. De fait, la précédente charte n'a pas suffit une seule seconde à stopper ce genre de comportement, on verra donc pour celle-ci.
Le billet de blog ne dit rien sur les contributrices existantes. On peut cependant noter que la dernière fois que j'ai regardé, elles n'avaient même pas vraiment conscience de l'existence du tag "Assisted by [nom_IA]" et ont ban Claude Code, donc bon, on peut être optimiste ?
___________________________
Sur un autre point, je me retrouve assez dans ce (court) article de Tante sur le rapport à l'usage de l'IA comme source d'information et autorité : https://tante.cc/2026/06/30/trying-to-manufacture-permission/
Dernier message par YannK - 30 Juin 2026 à 12:05:31
Cliquez pour afficher le message
Je ne me souviens pas qu'on en ait particulièrement parlé, sauf à dire qu'il n'était pas forcément dans no moyens techniques d'alors de proposer les deux vues comme Ryzom. Mais ayant vu quelques jeux où on est à la première personne, je trouve que l'immersion est meilleure. Et que ça pourrait donc bien convenir aux joueuses, vu que Khanat est un jeu d'ambiance. Cela permettrait aussi de mieux voir les personnages des autres joueuses vu que la caméra serait plus proche d'elles.
D'un autre côté, la troisième personne permet de contempler son eprsonnage en permanence
Je suis parti sur l'idée qu'on serait à la troisième personne pour IRIS et ça semblait faire consensus, mais je préfère qu'on le valide formellement avant d'attaquer les scènes 3D.
D'un autre côté, la troisième personne permet de contempler son eprsonnage en permanence
Je suis parti sur l'idée qu'on serait à la troisième personne pour IRIS et ça semblait faire consensus, mais je préfère qu'on le valide formellement avant d'attaquer les scènes 3D.
Dernier message par Zatalyz - 30 Juin 2026 à 11:02:29
Cliquez pour afficher le message
Merci Pulkomandy pour ces infos
Ho, ça, c'est tout simple et génial. Aucun risque qu'un "légitime" suive, et c'est trop tentant pour un bot néfaste par contre, donc une chance de le chopper tout de suite. Je bloque déjà sur des mot-clés d'url régulièrement recherché, mais parfois le comportement des bots est étrange et ces mots-clés arrivent tard. Là, on leur ajoute un appât.
CitationDans mon robots.txt j'ai mis un Disallow /url-interdite.
L'URL en question est également présente dans les en-têtes ou en bas de page de mon site, avec un texte disant "si vous êtes un humain, ne cliquez pas ici vous allez vous faire bannir". Le lien est également en nofollow.
Ho, ça, c'est tout simple et génial. Aucun risque qu'un "légitime" suive, et c'est trop tentant pour un bot néfaste par contre, donc une chance de le chopper tout de suite. Je bloque déjà sur des mot-clés d'url régulièrement recherché, mais parfois le comportement des bots est étrange et ces mots-clés arrivent tard. Là, on leur ajoute un appât.
CitationLe seul moyen de leur rendre la vie impossible, c'est que chaque site web aie ses propres règles.Pas faux... Il y a certains trucs qui peuvent se partager, mais d'autres où en effet, ça se fait dépasser. C'est toujours une course de toute façon. On peut se partager des trucs en privés aussi, mais... dans le fond, les grandes lignes sont là, et reste surtout à appliquer.
Dernier message par pulkomandy - 30 Juin 2026 à 09:52:35
Cliquez pour afficher le message
Salut!
Je peux donner quelques infos sur ce que je fais chez moi.
0. Les bases
- Pour Google, Bing et les moteurs de recherche classique: j'ai configuré un "Crawl-Delay" dans le fichier robots.txt. Cela leur demande de ne pas faire plus d'une requête toutes les quelques secondes (on choisit combien) et réduit leur traffic de façon acceptable. C'est bien respecté par les crawlers des moteurs de recherche.
- Pour les scrappers "honnêtes" (bot SEO par exemple, mais certains trucs de LLM aussi): blocage par une liste d'identifiants de bots dans le robots.txt avec une règle "Disallow /"
Là on a les bases pour les trucs implémentés correctement. Ensuite il faut lutter contre les trucs malveillants et/ou mal fichus.
1. Blocage des bots ne respectant pas le robots.txt
Dans mon robots.txt j'ai mis un Disallow /url-interdite.
L'URL en question est également présente dans les en-têtes ou en bas de page de mon site, avec un texte disant "si vous êtes un humain, ne cliquez pas ici vous allez vous faire bannir". Le lien est également en nofollow.
Si un bot accède à cette URL, c'est blocage direct.
Pour implémenter le blocage: règle spécifique dans le serveur web, qui retourne une erreur spécifique (j'ai choisi le code HTTP 429). J'ai ensuite une règle fail2ban qui scanne les logs de mon serveur HTTP pour trouver ces erreurs 429 et bloquer les IP correspondantes au niveau du pare-feu. Le même principe est utilisé dans les sections suivantes.
On peut aussi faire la même chose pour plein d'URLs "classiques" utilisés par des scanners de vulérabilités qui cherchent des wordpress, phpmyadmin, et autres nids à failles connus.
2. Filtrage par user agent
Pour certains bots ne respectant pas le robots.txt (typiquement, ne respectant pas le crawl-delay), mais qui s'identifient avec un user agent unique, filtrage des user agents "interdits" au niveau du serveur web.
3. Les bots "cachés"
Comme je ne suis pas le seul à mettre en place ce genre de mesures, il y a maintenant des bots qui se déclarent avec un user agent "classique" (typiquement une version de Chrome, mais il commence à y avoir aussi du Firefox). On peut tenter de bloquer les IPs "non résidentielles" quand on repère une plage d'IP (il y a eu Tencent et Alibaba il me semble, mais il y en a de nouvelles régulièrement).
Là, on peut au choix bannir ces IPs "préventivement" de façon statique dans le pare-feu, ou bien attendre la première requête sur le serveur web pour réagir.
4. Les proxys résidentiels
C'est la dernière nouveauté. Comme les IPs de datacenters sont de plus en plus mal vues par les sites internets, les robots utilisent maintenant des relais déployés via des applications sur des téléphones ou des télés connectées chez plein de gens.
J'ai lu un blog de quelqu'un indiquant que son site avait reçu des requêtes venant de un quart de l'espace d'addresage IP. En gros, quasiment toutes les IP possibles vont être utilisées, et ça devient très difficile de faire un blocage par IP (même les pare-feus ne suivent plus: il y a tellement d'IPs qu'il faut plusieurs Go de mémoire juste pour stocker la liste des IP bloquées...). Et chaque IP ne va typiquement faire qu'une seule requête, donc le blocage est peu efficace si on attend d'avoir plusieurs requêtes avant de bloquer.
Le blocage géographique peut être une solution (si vous acceptez de restreindre l'accès pour certains pays, mais il risque d'y en avoir de plus en plus tant qu'il n'y aura pas de législation pour interdire ces pratiques).
Chez moi, j'ai fini par bloquer toutes les versions un peu anciennes de Chrome et Firefox pour Windows. Comme ces robots ont tendance à utiliser des user agents ne correspondant pas à la toute dernière version, ça limite assez les problèmes. Et les gens utilisant un autre OS ou un autre navigateur ne sont pas impactés.
5. Pourquoi ces attaques?
Ce que j'observe, c'est que les interfaces web de dépôts git comportent une quasi infinité de liens (historique des versions, puis affichage de chaque fichier dans chaque version, etc). C'est le "tarpit" parfait pour un robot scrapper d'entraînement LLM, tout plein de contenu à lire!
Je pense qu'avec un site comportant moins de liens, il y a moins de problèmes, le robot va rapidement en faire le tour et aller voir ailleurs.
Dans certains cas j'ai fini par mettre mon interface web de dépôt Git accessible uniquement après login.
6. Conclusion
Je vous donne volontairement peu de détails spécifiques sur ma configuration.
Le déploiement de solutions "universelles" (Anubis, iocaine, ou de façon générale une config standardisée avec une liste de user agent connue) pousse les développeurs de bots à trouver un contournement spécifique pour la solution la plus populaire. Le seul moyen de leur rendre la vie impossible, c'est que chaque site web aie ses propres règles. Donc, adapter votre configuration à ce que vous observez est la bonne démarche. Et aussi choisir vos propres durées de ban, pour pas que tout le monde aie la même.
J'arrive à garder le traffic à un niveau acceptable chez moi (pour un serveur auto hébergé sur ma connexion fibre à la maison, sans que ça pénalise les autres utilisations du serveur et de la connexion internet), mais régulièrement (tous les quelques mois) je dois mettre à jour ma liste de bans suite à un nouvel user agent ou une nouvelle forme d'attaque. Donc il faut garder un oeuil sur les accès au serveur web, c'est pas vraiment un truc qu'on peut configurer une fois et laisser tourner tout seul
7. Bonus: le monitoring.
J'utilisais awstats pour surveiller le traffic sur mon site. ça marchait bien pour repérer les pics de traffic et autres trucs louches. Mais awstats sur mon serveur n'arrive plus à suivre quand il y a des millions de requêtes à scanner dans les logs.
Je l'ai remplacé par goaccess, il est moins bien, mais plus rapide.
Bon courage!
Je peux donner quelques infos sur ce que je fais chez moi.
0. Les bases
- Pour Google, Bing et les moteurs de recherche classique: j'ai configuré un "Crawl-Delay" dans le fichier robots.txt. Cela leur demande de ne pas faire plus d'une requête toutes les quelques secondes (on choisit combien) et réduit leur traffic de façon acceptable. C'est bien respecté par les crawlers des moteurs de recherche.
- Pour les scrappers "honnêtes" (bot SEO par exemple, mais certains trucs de LLM aussi): blocage par une liste d'identifiants de bots dans le robots.txt avec une règle "Disallow /"
Là on a les bases pour les trucs implémentés correctement. Ensuite il faut lutter contre les trucs malveillants et/ou mal fichus.
1. Blocage des bots ne respectant pas le robots.txt
Dans mon robots.txt j'ai mis un Disallow /url-interdite.
L'URL en question est également présente dans les en-têtes ou en bas de page de mon site, avec un texte disant "si vous êtes un humain, ne cliquez pas ici vous allez vous faire bannir". Le lien est également en nofollow.
Si un bot accède à cette URL, c'est blocage direct.
Pour implémenter le blocage: règle spécifique dans le serveur web, qui retourne une erreur spécifique (j'ai choisi le code HTTP 429). J'ai ensuite une règle fail2ban qui scanne les logs de mon serveur HTTP pour trouver ces erreurs 429 et bloquer les IP correspondantes au niveau du pare-feu. Le même principe est utilisé dans les sections suivantes.
On peut aussi faire la même chose pour plein d'URLs "classiques" utilisés par des scanners de vulérabilités qui cherchent des wordpress, phpmyadmin, et autres nids à failles connus.
2. Filtrage par user agent
Pour certains bots ne respectant pas le robots.txt (typiquement, ne respectant pas le crawl-delay), mais qui s'identifient avec un user agent unique, filtrage des user agents "interdits" au niveau du serveur web.
3. Les bots "cachés"
Comme je ne suis pas le seul à mettre en place ce genre de mesures, il y a maintenant des bots qui se déclarent avec un user agent "classique" (typiquement une version de Chrome, mais il commence à y avoir aussi du Firefox). On peut tenter de bloquer les IPs "non résidentielles" quand on repère une plage d'IP (il y a eu Tencent et Alibaba il me semble, mais il y en a de nouvelles régulièrement).
Là, on peut au choix bannir ces IPs "préventivement" de façon statique dans le pare-feu, ou bien attendre la première requête sur le serveur web pour réagir.
4. Les proxys résidentiels
C'est la dernière nouveauté. Comme les IPs de datacenters sont de plus en plus mal vues par les sites internets, les robots utilisent maintenant des relais déployés via des applications sur des téléphones ou des télés connectées chez plein de gens.
J'ai lu un blog de quelqu'un indiquant que son site avait reçu des requêtes venant de un quart de l'espace d'addresage IP. En gros, quasiment toutes les IP possibles vont être utilisées, et ça devient très difficile de faire un blocage par IP (même les pare-feus ne suivent plus: il y a tellement d'IPs qu'il faut plusieurs Go de mémoire juste pour stocker la liste des IP bloquées...). Et chaque IP ne va typiquement faire qu'une seule requête, donc le blocage est peu efficace si on attend d'avoir plusieurs requêtes avant de bloquer.
Le blocage géographique peut être une solution (si vous acceptez de restreindre l'accès pour certains pays, mais il risque d'y en avoir de plus en plus tant qu'il n'y aura pas de législation pour interdire ces pratiques).
Chez moi, j'ai fini par bloquer toutes les versions un peu anciennes de Chrome et Firefox pour Windows. Comme ces robots ont tendance à utiliser des user agents ne correspondant pas à la toute dernière version, ça limite assez les problèmes. Et les gens utilisant un autre OS ou un autre navigateur ne sont pas impactés.
5. Pourquoi ces attaques?
Ce que j'observe, c'est que les interfaces web de dépôts git comportent une quasi infinité de liens (historique des versions, puis affichage de chaque fichier dans chaque version, etc). C'est le "tarpit" parfait pour un robot scrapper d'entraînement LLM, tout plein de contenu à lire!
Je pense qu'avec un site comportant moins de liens, il y a moins de problèmes, le robot va rapidement en faire le tour et aller voir ailleurs.
Dans certains cas j'ai fini par mettre mon interface web de dépôt Git accessible uniquement après login.
6. Conclusion
Je vous donne volontairement peu de détails spécifiques sur ma configuration.
Le déploiement de solutions "universelles" (Anubis, iocaine, ou de façon générale une config standardisée avec une liste de user agent connue) pousse les développeurs de bots à trouver un contournement spécifique pour la solution la plus populaire. Le seul moyen de leur rendre la vie impossible, c'est que chaque site web aie ses propres règles. Donc, adapter votre configuration à ce que vous observez est la bonne démarche. Et aussi choisir vos propres durées de ban, pour pas que tout le monde aie la même.
J'arrive à garder le traffic à un niveau acceptable chez moi (pour un serveur auto hébergé sur ma connexion fibre à la maison, sans que ça pénalise les autres utilisations du serveur et de la connexion internet), mais régulièrement (tous les quelques mois) je dois mettre à jour ma liste de bans suite à un nouvel user agent ou une nouvelle forme d'attaque. Donc il faut garder un oeuil sur les accès au serveur web, c'est pas vraiment un truc qu'on peut configurer une fois et laisser tourner tout seul
7. Bonus: le monitoring.
J'utilisais awstats pour surveiller le traffic sur mon site. ça marchait bien pour repérer les pics de traffic et autres trucs louches. Mais awstats sur mon serveur n'arrive plus à suivre quand il y a des millions de requêtes à scanner dans les logs.
Je l'ai remplacé par goaccess, il est moins bien, mais plus rapide.
Bon courage!
Dernier message par Zatalyz - 29 Juin 2026 à 09:36:32
Cliquez pour afficher le message
C'est dense, et hyper intéressant. Mais dense ! Merci pour le lien, c'est de bonnes bases, par contre je trouve cela difficile à exploiter "tel quel" : je ne saurais pas trop comment utiliser et mettre en place certains morceaux, certaines règles me semblent un peu légères (= peu durables dans le temps, vite contournées, comme avec les ip Tencent). Cependant comme il explique la logique, ça devrait permettre d'affiner.
Et là pour le coup c'est à la fois intéressant et... j'en veux plus (mais je vais regarder le reste de ce qu'il a partagé) : bien comprendre les patterns qu'il détecte.
Je ne pense pas l'utiliser tel quel, mais l'intégrer dans notre logique.
Je pense de mon côté qu'il y a trois niveaux :
- Un set d'ip identifiées comme problématiques, qu'on va bannir sur des temps longs (1 à 6 mois sans souci) et très certainement par plage d'ip ; ce genre de set devrait juste être partagé sur nos reseaux et bloqué au niveau des proxy (via nftables). La détection de ces ip pourrait passer par du honeypot, avec potentiellement greylisting sur certains acteurs (genre si on veut être référencé par certains moteurs de recherche pour ce qui concerne le web), ainsi que par l'analyse des logs de Reaction.
- Des comportements tellement problématiques que ça sera géré direct avec Reaction et donc bloqué ensuite via le pare-feu.
- Des comportements qui sont ok... suivant le flux, et là c'est avec nginx/apache qu'on commence à les gérer.
Exemple qui ne pose pas question : le bot qui scanne "bêtement" si on a un "wp-login" => c'est du pur badbot, ça je bannis 1 mois sans souci.
Exemple qui me pose plus question : les bots d'indexeurs. Dans l'absolu, on n'est pas contre se faire trouver par les moteurs de recherche. Et j'inclue dans ces derniers même les IA, puisque la recherche par LLM est en train de remplacer l'ancienne. Mais ces bots posent soucis à cause de leur fréquence de visite. Une fois par jour, avec une navigation tranquille sur nos pages ça va ; par contre scanner tout notre site non stop c'est juste une charge trop lourde. Donc on doit leur balancer une erreur 429 : Too Many Requests. Ça, c'est géré par nginx/apache.
Là où ça devient complexe, c'est que le bot qui reçoit une 429 et se calme dans la foulée est OK, mais il y en a qui vont continuer à frapper à la porte non-stop (ouais, les bots, c'est aussi cons que leurs concepteurs) et ces requêtes continuent de peser sur nginx. Donc à un moment : trop de 429 sur une ip = ban par le firewall. Pour le bot ce sera comme si le serveur était tombé. Là dessus, je serais d'avis de bannir 24h. Faut pas pousser. Mais aussi d'analyser si on a certains qui abusent toutes les 24h => ils passent dans la liste à virer.
Maiiiiis ça veut aussi dire, très certainement, questionner ce qu'on fait de Google et Bing (entre autre). Et vu ce que dit blablalinux, sans doute des instances Searx. Est-ce qu'on souhaite les bannir définitivement si elles se comportent mal ? Est-ce qu'on les met dans un set spécial "vous êtes des chieuses, mais on vous autorise à l'être entre minuit et 2h du matin pour alimenter vos index et qu'on nous trouve" ?
Concernant le partage des IP bannies à long terme, mon idée est la suivante :
- Sur chaque serveur, quand Reaction banni une ip, cela alimente un fichier de log avec la raison (et la durée).
- Ces logs sont envoyés à un serveur central (une fois par jour ?)
- Ils sont analysés avec un script bash, histoire de voir les ips qui reviennent, encore et encore, ou bien celles dont les "raisons" justifient un ban à long terme. Les ips sont amalgamé, si cela concerne des plages, on se contente de la plage. On publie alors sur ce serveur central notre liste d'ip bannies (en mode API idéalement, mais ce sera ptet plus basique) et nos autres serveurs viennent se servir pour alimenter leur set "banni à long terme".
C'est assez basique. Très probablement, je pourrais utiliser la même logique dans les deux cas : les logs accessibles en lecture via le web (oui, *peut-être* derrière une api, ou pas), et des processus internes pour en faire un truc. Avec mes connaissances actuelles, ça serait wget+bash mais les devs auront ptet plus pertinent à proposer.
Et là pour le coup c'est à la fois intéressant et... j'en veux plus (mais je vais regarder le reste de ce qu'il a partagé) : bien comprendre les patterns qu'il détecte.
Je ne pense pas l'utiliser tel quel, mais l'intégrer dans notre logique.
Je pense de mon côté qu'il y a trois niveaux :
- Un set d'ip identifiées comme problématiques, qu'on va bannir sur des temps longs (1 à 6 mois sans souci) et très certainement par plage d'ip ; ce genre de set devrait juste être partagé sur nos reseaux et bloqué au niveau des proxy (via nftables). La détection de ces ip pourrait passer par du honeypot, avec potentiellement greylisting sur certains acteurs (genre si on veut être référencé par certains moteurs de recherche pour ce qui concerne le web), ainsi que par l'analyse des logs de Reaction.
- Des comportements tellement problématiques que ça sera géré direct avec Reaction et donc bloqué ensuite via le pare-feu.
- Des comportements qui sont ok... suivant le flux, et là c'est avec nginx/apache qu'on commence à les gérer.
Exemple qui ne pose pas question : le bot qui scanne "bêtement" si on a un "wp-login" => c'est du pur badbot, ça je bannis 1 mois sans souci.
Exemple qui me pose plus question : les bots d'indexeurs. Dans l'absolu, on n'est pas contre se faire trouver par les moteurs de recherche. Et j'inclue dans ces derniers même les IA, puisque la recherche par LLM est en train de remplacer l'ancienne. Mais ces bots posent soucis à cause de leur fréquence de visite. Une fois par jour, avec une navigation tranquille sur nos pages ça va ; par contre scanner tout notre site non stop c'est juste une charge trop lourde. Donc on doit leur balancer une erreur 429 : Too Many Requests. Ça, c'est géré par nginx/apache.
Là où ça devient complexe, c'est que le bot qui reçoit une 429 et se calme dans la foulée est OK, mais il y en a qui vont continuer à frapper à la porte non-stop (ouais, les bots, c'est aussi cons que leurs concepteurs) et ces requêtes continuent de peser sur nginx. Donc à un moment : trop de 429 sur une ip = ban par le firewall. Pour le bot ce sera comme si le serveur était tombé. Là dessus, je serais d'avis de bannir 24h. Faut pas pousser. Mais aussi d'analyser si on a certains qui abusent toutes les 24h => ils passent dans la liste à virer.
Maiiiiis ça veut aussi dire, très certainement, questionner ce qu'on fait de Google et Bing (entre autre). Et vu ce que dit blablalinux, sans doute des instances Searx. Est-ce qu'on souhaite les bannir définitivement si elles se comportent mal ? Est-ce qu'on les met dans un set spécial "vous êtes des chieuses, mais on vous autorise à l'être entre minuit et 2h du matin pour alimenter vos index et qu'on nous trouve" ?
Concernant le partage des IP bannies à long terme, mon idée est la suivante :
- Sur chaque serveur, quand Reaction banni une ip, cela alimente un fichier de log avec la raison (et la durée).
- Ces logs sont envoyés à un serveur central (une fois par jour ?)
- Ils sont analysés avec un script bash, histoire de voir les ips qui reviennent, encore et encore, ou bien celles dont les "raisons" justifient un ban à long terme. Les ips sont amalgamé, si cela concerne des plages, on se contente de la plage. On publie alors sur ce serveur central notre liste d'ip bannies (en mode API idéalement, mais ce sera ptet plus basique) et nos autres serveurs viennent se servir pour alimenter leur set "banni à long terme".
C'est assez basique. Très probablement, je pourrais utiliser la même logique dans les deux cas : les logs accessibles en lecture via le web (oui, *peut-être* derrière une api, ou pas), et des processus internes pour en faire un truc. Avec mes connaissances actuelles, ça serait wget+bash mais les devs auront ptet plus pertinent à proposer.
Dernier message par deed - 28 Juin 2026 à 20:07:07
Cliquez pour afficher le message
mise à jour du script
https://joplin.blablalinux.be/shares/SDdcZYIFiccbk7MSe807PE
si quelqu'un veut donner son avis ??
(c'est du home en vdsl)
https://joplin.blablalinux.be/shares/SDdcZYIFiccbk7MSe807PE
si quelqu'un veut donner son avis ??
(c'est du home en vdsl)
