Écran de sécurité - SPIP

Ce post me permet de découvrir que les blocs de code sont un peu pétés depuis le passage en SPIP 4 => ticket par ici ▻https://git.spip.net/seenthis/squelettes/-/work_items/304

Ah oui, bien vu. J’ai cru récemment que c’est moi qui n’avait pas fait les choses correctement.

Deux Prs pour le prix d’une : ▻https://git.spip.net/seenthis/squelettes/-/merge_requests/301 & ▻https://git.spip.net/seenthis/squelettes/-/merge_requests/302

Voilà, c’est corrigé, et j’en ai profité pour faire un peu de ménage dans des fonctions obsolètes.

Merci 👍

merci !

@b_b, lors de ta mise à jour tu as réinitialisé le fichier ecran_securite.php ce qui a permis aux bots de ne plus être bloqué.

Pour l’anecdote : sur les 3 derniers jours, le trafic quotidien a été multiplié par 4. Sur 7 jours, le bot Apple a avalé 500K messages, ce qui représente la moitié des messages lus sur la période.

Conséquence : nous avons à nouveau les messages issus de RSS qui se retrouvent lus et mis en cache vide avant d’avoir été générés complètement. Il va falloir sérieusement étudier ce sujet un de ces jours.

On a sur le feu :

– Important : sanctuariser les modifications propres à seenthis réalisées sur le fichier ecran_securite.php
– Nécessaire : pouvoir contrôler le moment/la façon dont le webcron s’exécute
– Nécessaire : corriger la façon dont les messages RSS sont créés, pour éviter la création de messages à l’apparence vide
– Moins important : optimiser les requêtes SQL de calcul des blocages (déjà prototypé et testé, mais jamais réalisé de PR)

merci aux soutiers !

merci!

Illustration de comment les bots se manifestent quand on les laisse passer. Les 7 derniers jours.

Il y a 4 jours, le système de détection se désactive lors de la mise à jour, les IP des bots sortent de leur prison petit à petit. Puis hier soir, on le réactive. Entre les deux, les indexeurs s’en sont donnés à cœur joie.

Le bot d’Apple en premier lieu : il ne serait pas étonnant qu’Apple, un de ces jours, sorte du bois sur le sujet de l’IA (pour le moment il reste très en retrait par rapport aux autres GAFAM). Pour l’anecdote, l’Apple Bot, ce sont plus de 2000 IPv4 distinctes. Aucun autre moteur n’a autant d’adresses mobilisées, d’après ce qu’on observe.

https://pixelfed.zoo-logique.org/storage/m/_v2/493151427756716033/0d402c64b-2701fc/p3NPWnThN5zW/Yi5QWoHuzDIkgAIiyVBp8iMtGf3LDVcXnU6W8lcf.png

Sur 30 jours, en se basant sur le user-agent :
– Apple : 2100 IP
– Yandex : 700 IP
– Facebook : 600 IP
– Bing : 600 IP
– Google : 110 IP
– OpenAI : 40 IP
– Claude : 17 IP (il n’est quasiment jamais venu)

@biggrizzly

lors de ta mise à jour tu as réinitialisé le fichier ecran_securite.php ce qui a permis aux bots de ne plus être bloqué.

Ha ben oui, c’est le problème de :

– surcharger le fichier en le modifiant directement plutôt qu’à l’aide des modifs persos comme ►https://www.spip.net/fr_article4200.html#Configuration
– faire les mises avec le loader

Donc, si tes modifs de l’écran ne passent pas par la manière classiques, il faudra qu’on change la méthode d’install de SPIP pour la repasser en git.

Tiens moi au courant :)

sur les bots Apple, cf. ▻https://seenthis.net/messages/1174721

J’ajoute : comment se fait-il que SeenThis accepte de traiter ce genre d’URL ?

/messages/francais/mentions/article/sites/people/people/sites/tag/tag/polarisation

C’est ce qu’on reçoit comme requêtes crétines par milliers.

(attention n’essayez pas plus d’une fois de faire servir une URL de ce genre, votre IP se ferait bloquer...)

Ou aussi :
/people/people/people/people/people/tag/sites/7282461336007622462

En fait, c’est un botnet stupide.
Le bot réclame des URL qui n’existent pas.
Elles commencent par /people/people/ ou /messages/messages/ ou /sites/sites/ ou /sites/messages/ ou /people/messages/ ... vous avez compris j’imagine, le motif.
Je demande à nginx de renvoyer une erreur http 445.
Je demande à fail2ban de bloquer les IP qui génèrent des erreurs http 445.
Et ça réduit la charge.
Jusqu’à la prochaine fois.

La difficulté majeure, entre nous, c’est que ce serveur est obsolète, et que je ne peux pas le connecter sur un analyseur de log moderne. C’est vraiment pénalisant.

Rien que le fait de bloquer les requêtes via nginx et détection de motif, ça fait baisser drastiquement la charge.

fail2ban travaille bien... déjà 1200 adresses IP bloquées.

Ça va faire comme avec les chinois et leurs user-agent MSIE l’an dernier (toujours actif, et qui bloque toujours ponctuellement quelques dizaines d’IP..., on est loin des dizaines de milliers d’IP bloquées).

Je pense donc, finalement, que c’est un botnet de scraping complètement crétin.

Et je pense qu’on devrait apprendre à SeenThis à ne pas servir le genre d’URI que j’ai indiqué.

(seenthis est fabuleusement rapide, quand les botnets ne prennent plus de temps machine...)

J’ai ajouté quelques autres motifs absurdes ce matin. Ce qui fait que les bots se rabattent sur la recherche, ce qui fait chauffer le moteur de recherche... mais laisse nos fils fonctionner.
iptables est mis à rude épreuve, n’empêche. Là aussi, j’ai adapté les paramètres.
On a de la chance d’avoir un botnet aussi crétin. Ceci dit, les URI qu’il réclame doivent exister quelque part, pour qu’il décide de les parcourir... Une enquête pour #seenthis_bug

J’aimerais aussi que la fonction de recherche soit réservée aux utilisateurs connectés. Comment je dois implémenter cela ? C’est la même question que le post de tête, à savoir, quelle est la fonction que je dois utiliser pour être au courant que l’utilisateur est connecté ?

Le souci qui se pose désormais :
– On grimpe à 60000 IP bloquées...
– Puis fail2ban a un souci avec iptables... et ça libère toutes les IP, et ça recommence.

D’où, ponctuellement, le fait que ça recommence à devenir lent...

J’ai rassemblé dans un fichier toutes les IP distinctes bannies depuis que j’ai activé la détection de motif propre à ce botnet : 170000 environ.

J’ai construit un ipset dédié.

(J’ai supprimé mon IP, qui évidemment avait été flashée à un moment, parce que j’essayais de comprendre à quoi rimaient ces URI bizarres...)

Et j’ai ajouté cet ipset dans iptables, qui se retrouve allégé de plusieurs milliers de lignes distinctes. Tout comme fail2ban qui n’a plus besoin de bosser comme un dératé.

On va voir si malgré tout, d’autres IP se font flasher.

C’est spécifique à Seenthis ? Il y a d’autres SPIP qui prennent ? Ça vient d’où, ça sert à quoi ?

(s’il faut, quelqu’un tente d’éduquer une IA de gauche pour rigoler.)

J’ai compris l’origine de l’anomalie dans SeenThis.

1) C’est bien un bot d’alimentation d’une IA quelconque
2) Elle consomme toutes les URL de SeenThis, en particulier via les URL de recherches.
3) Quand elle arrive sur la page /messages/1103732 (ce post) elle regarde le code source.
4) Dans le code source, elle trouve par exemple la balise HTML <a href="people/7h36" title="7h36 (@7h36)" rel="nofollow">
5) Pour accéder à la ressource mentionnée, elle construit l’URL suivante : https://seenthis.net/messages/people/7h36 (ne cliquez pas sur cette URL, fail2ban va bloquer votre IP) et elle a raison de la construire de la sorte. Ce qui est bizarre, c’est que les navigateurs s’en sortent sans soucis ; si qq’un peut m’expliquer la subtilité.
6) Puis elle charge cette URL, parce que SeenThis accepte de la résoudre. Et ça peut de la sorte continuer à l’infini.

Le botnet en question utilise des IPv4 du monde entier, et pour le moment, j’en décompte plus de 200 000. Les user agent sont aléatoires, c’est à dire qu’ils se font passer pour de vrais navigateurs de postes de travail.

Donc deux anomalies :
1. Les urls relatives des balises href, par rapport à des routes qui ne correspondent pas vraiment.
2. Le fait d’accepter de résoudre ces URL anormales (ça devrait renvoyer 404...).

Il faut se rendre compte de ce que ça signifie, que d’avoir les moyens de mobiliser des centaines de milliers de machines pour avaler Internet. Ces gens sont fous.

Ce n’est pas nouveau, qu’internet les fait chier.

J’ai coupé sphinx (la recherche).
Pas la vocation à laisser consommer 6 cœurs H24 juste parce qu’on laisse faire les recherches aux utilisateurs anonymes.

Ça bloque déjà 220000 IP, et ça continue à bloquer 5-6 IP par seconde. 1,5 cœurs consommés H24 par fail2ban.

Yop,

Je souhaite envoyer une erreur HTTP 429 pour les accès anonymes quand la charge est supérieure à une certaine valeur.

A quel endroit du code de SPIP/SeenThis je dois placer un bout de code pour procéder à une telle action ?

C’est dans l’écran de sécurité de SPIP, tu peux surcharger la valeur du load qui déclenche l’erreur ►https://www.spip.net/fr_article4200.html#Configuration et le code envoyé est déjà un 429 cf ▻https://git.spip.net/spip-contrib-outils/securite/-/blob/master/ecran_securite.php?ref_type=heads#L795

J’ajoute : comment se fait-il que SeenThis accepte de traiter ce genre d’URL ?

C’est du au fait qu’on utilise une version de SPIP dépassée, et peut-être aussi à cause des urls arbos que je n’utilise jamais de mon côté.

La difficulté majeure, entre nous, c’est que ce serveur est obsolète, et que je ne peux pas le connecter sur un analyseur de log moderne. C’est vraiment pénalisant.

Ça tombe bien, c’est raccord avec le fait qu’on utilise une version obsolète de SPIP sur seenthis.net ^^

Et je pense qu’on devrait apprendre à SeenThis à ne pas servir le genre d’URI que j’ai indiqué.

Ça peut peut-être se faire, mais j’ai peur que ça soit plus coûteux en ressource de le faire côté PHP que côté « serveur ».

Et je pense qu’on devrait apprendre à SeenThis à ne pas servir le genre d’URI que j’ai indiqué.

Ça c’est une proposition d’évolution très simple à mettre en oeuvre côté SPIP/seenthis, tu payes ton ticket sur ►https://git.spip.net/seenthis/squelettes/-/issues ? Perso, ça ne me pose aucun pb que la recherche soit limitée aux membres du site.

Les urls relatives des balises href, par rapport à des routes qui ne correspondent pas vraiment.

Idem, c’est très facile à corriger, je peux m’en charger et reporter dans la branche spécifique à notre vieille instance, il me faudrait juste un ticket pour y penser dès que j’ai un moment :)

En tout, merci tu temps passé/perdu là dessus un we, je sais ce que c’est et parfois on aimerait faire autre chose de ses we :*

yes, un grand merci à vous deux !

eueueuh, yapu de recherche pour personne ?

https://pixelfed.zoo-logique.org/storage/m/_v2/493806419159965724/549719332-a3f277/6re5M3LvbfHW/tH2VGxtQ2srsxcZylvqks8IyRHMSxJiN1KIZJmcG.png

Le temps qu’on trouve un moyen de ne bloquer que les non-inscrits.

f2b a collecté, cette nuit, 149000 IP supplémentaires.
Et ça continue à bloquer 1 à 2 IP par seconde.

Idem : « Perso, ça ne me pose aucun pb que la recherche soit limitée aux membres du site. » @b_b
Salubrité publique, même.

Je décompte 380000 IP désormais dans ce botnet.

https://pixelfed.zoo-logique.org/storage/m/_v2/493151427756716033/549719332-a3f277/37cZxDektF3A/my7fSnSNcLga4aRCRZfDCdC5SrZFTxxKXAYc4Wlc.png

Sur les 7 derniers jours. On comprend que le botnet s’est mis en route sur SeenThis à partir du 14. A partir du 15, j’ai trouvé l’astuce pour repérer les IP en masse, mais ça a reporté la charge processeur sur la recherche, nginx, et fail2ban. Et à partir de la mi-journée du 15, j’ai enfin bloqué en masse sans fail2ban. Là, j’ai mis en dur le blocage des 380000 IP. Et je vais sans doute continuer de la sorte.

S’il y a des admins de passage qui souhaitent que je partage l’ipset pour l’implémenter sur leur système, pas de souci, je partage volontiers.

J’ai fait le test de rétablir la recherche. Grossière erreur. Ce n’est toujours pas le moment.
Le botnet grandit. Apparemment, on va dépasser les 380000 adresses IP.

Dans le haut de chaque page, il y a :

<base href="https://seenthis.net/"/>

Merci pour le rappel. Les botnets de scraping sont probablement programmés avec ChatGPT...

@biggrizzly si tu veux, tu peux déjà patcher à l’arrache en prod, il suffit d’ajouter [(#SESSION{id_auteur}|sinon_interdire_acces{#URL_SITE_SPIP,403})] sous la première ligne de plugins/seenthis_squelettes/recherche.html cf ▻https://git.spip.net/seenthis/squelettes/-/blob/master/recherche.html?ref_type=heads#L1

@b_b Merci pour la proposition. Je tente. Et ça semble être ignoré. Faut-il vider le cache ?

@biggrizzly je voulais aller vérifier sur le serveur mais on dirait que je n’y ai plus accès.

Y-a pas de raisons... Le serveur est vieux, il se peut que ton client SSH ne supporte pas les vieux algos ?

@biggrizzly ha oui, on utilise shpinx donc le squelette à surcharger est ▻https://git.spip.net/seenthis/sphinx/-/blob/master/sphinx.html?ref_type=heads

J’ai un failed password dans les logs ; il y a la clef rsa bb@tybook.

Super, ça marche. Dans le navigateur, ça ne reçoit qu’un 302 apparemment, mais au moins, sphinx n’est pas mobilisé.
On doit pouvoir faire mieux, mais dans l’immédiat, ça permet aux connectés d’effectuer des recherches.

J’ai modifié plugins/seenthis_sphinx/sphinx.html

On en cause sur ►https://web.libera.chat/#seenthis si tu veux :)

Bien vu, il me manquait un PubkeyAcceptedKeyTypes +ssh-rsa pour le host de seenthis.

Perso, ça ne me pose aucun pb que la recherche soit limitée aux membres du site.

Les quelques autres instances de seenthis que je connais ou sur lesquelles j’ai eu à travailler seraient impactées par ce changement. On peut envisager de rendre ce comportement configurable, mais ça aurait un impact minime sur les perfs, sinon ces instances devront surcharger le squelette en question (qui de toute façon ne bouge pas souvent).

+70K IP cette nuit.
Tjs 1 ban par seconde.

Si c’est ça, le déploiement de l’IA, internet ne va juste pas y survivre.

Depuis tes restrictions, seenthis est devenu « normal » à utiliser : ça laguait tellement fort que c’était souvent inutilisable pour moi.

Désolé pour l’interruption, je n’ai pas encore trouvé le moyen de mettre à jour l’ipset sans rebooter le système...

Nous en sommes à 463967 adresses IP bloquées :-)