Petite annonce : nous avons passé les routes /tag/ et /sites/ sous authentification obligatoire. La charge s’est très rapidement réduite.
110000 IP distinctes dans les 4 dernières heures. 60000 dans les 2 dernières heures. En fait, c’est un roulement de 30000 IP distinctes par heure, du monde entier.
Tu as fait les modifs direct dans plugins/seenthis_squelettes, peut-être qu’il serait temps de poser nos modifs persos dans squelettes à la racine et de versionner tout ça dans un repo ? À moins qu’on valide ces changements et qu’on les push dans le repo principal ?
Je considère que ces corrections sur l’accès public aux ressources de seenthis sont des pansements temporaires, afin de nous permettre de profiter de SeenThis malgré les botnets internationaux.
Si nous décidions de pérenniser ces règles, j’imagine que nous devrions en discuter collectivement au préalable : voulons-nous que le réseau soit diffusé publiquement, sur l’ensemble de ses fonctionnalités. Nous avions eu le débat, rapide, sur la recherche. Là, d’une certaine façon, je l’ouvre sur les accès /tag/ et /sites/, et je n’ai pas pris le temps de savoir quel serait mon opinion. De suite, ça me facilite la vie et ça nous permet de temporairement profiter de nos publications respectives.
Comme je le disais la semaine dernière, il me semble que la seule solution viable, face aux #botnets, c’est une solution « à la #cloudflare », comme #anubis ou équivalent, c’est à dire d’imposer une preuve de travail côté navigateur. Même si les botnets finiront parfois par la fournir, cela augmentera de leur côté le coût de venir nous rendre visite, plutôt que de continuer uniquement de notre côté à augmenter les ressources et systèmes de mitigation.
(c’est amusant, on a à nouveau le botnet qui réclame les urls absurdes /messages/messages/messages/sites/people/etc)
J’ajoute un dernier commentaire.
Soit le code suivant inséré dans un squelette SPIP :[(#SESSION{id_auteur}|sinon_interdire_acces{#URL_SITE_SPIP,403})]
J’avoue que je m’attends, côté client, à recevoir une erreur 403, et côté serveur, à voir dans les journaux une erreur 403. Seulement, en l’état, on ne trouve qu’une redirection 302. C’est ballot, et ça ne permet pas de procéder à d’éventuels traitements, et pire, ça génère une seconde requête sur le serveur, alors qu’on aurait pu simplement afficher une page 403. J’ignore s’il est facile d’améliorer ce fonctionnement défectueux, et je ne sais pas si ça vaut le coup, modulo ce que je disais précédemment, comme quoi je considère ces solutions comme temporaires.
No problemo, je te comprends :)
Concernant Anubis, je vois qu’il y a un paquet debian cf ▻https://anubis.techaro.lol/docs/admin/native-install et que ça peut se déployer/configurer directement depuis nginx cf ▻https://anubis.techaro.lol/docs/admin/environments/nginx => ça vaudrait le coup d’essayer
Je viens de lire la page nginx. En effet, vue la facilité de mise en œuvre je crois qu’on va faire le test.
J’ai trouvé un moyen de doublement réduire la charge, mais c’est malveillant. Les non-authentifiés qui réclament /tag ou /sites sont redirigés vers /tag/tag, ou /sites/sites, ce qui est traité par nginx en direct par une erreur 445, et peut potentiellement envoyer le visiteur dans fail2ban s’il insiste. C’est radical. Donc temporaire.
Étrange pour le statut 302, car c’est celui renvoyé par défaut si on n’en passe pas au filtre cf ▻https://search.spip.net/git.spip.net/spip/ecrire/-/blob/inc/filtres.php?L5140:10
> J’ai trouvé un moyen de doublement réduire la charge, mais c’est malveillant.
Héhé, je me suis fait bloquer en voulant tester le statut renvoyé par la redirection de SPIP ^^ Mon accès au serveur m’a sauvé sur ce coup là.
Le botnet, comme il parvient à traiter plus d’URL, parce que SeenThis est plus rapide à fournir une réponse, il nous présente plus d’IP à chaque instant. On va atteindre les 50000 IP par heure, parce que le serveur est capable de fournir 50000 pages d’erreurs par heure. En fait, on comprend que le botnet il a une liste d’URL à traiter, et il demande à son réseau de les traiter, via des terminaux compromis aux 4 coins de la planète.
Concernant sinon_interdire_acces() je viens de comprendre pourquoi ça ne peut pas fonctionner. Celui-ci utilise redirige_par_entete() qui n’autorise que les statuts 301 & 302 cf ▻https://search.spip.net/git.spip.net/spip/ecrire/-/blob/inc/headers.php?L39
Donc, la doc du filtre est fausse ▻https://www.spip.net/fr_article5668.html#sinon_interdire_acces ainsi que son phpdoc :\
Anubis est un bel outil très puissant. J’en avais jusqu’alors mésestimé l’intérêt. Nous allons le mettre en œuvre d’ici quelques heures à quelques jours.
Pour sinon_interdire_acces, tu confirmes donc que ce n’est pas lié à SeenThis, et que c’est Spip lui même qui n’est pas très carré de ce point de vue là ? Pas d’chance pour nous.
> Pour sinon_interdire_acces, tu confirmes donc que ce n’est pas lié à SeenThis, et que c’est Spip lui même qui n’est pas très carré de ce point de vue là.
Non, c’est la doc qui est pourrite, cf les échanges dans le ticket que j’ai créé. Je viens de corriger seenthis sur ce point cf ▻https://git.spip.net/seenthis/squelettes/-/commit/8bf4996bd3209e0913075c540b025cfd8fb6fa76 il faut donc utiliser [(#SESSION{id_auteur}|sinon_interdire_acces{'',403})].
La PR pour le plugin sphinx est à jour ▻https://git.spip.net/seenthis/sphinx/-/merge_requests/8 et je la merge dans la foulée.
Merci pour tes actions.
Du coup, j’ai enlevé les redirections, et j’ai désormais des erreurs 403. Et on a donc deux fois moins de requêtes issues du monde entier. Et une charge faible comme jamais.
Les #botnets, le retour.
L’assaut du jour, c’était un millier d’#adresses #IP réclamant simultanément des milliers de pages. Chaque requête était identifiée d’un user-agent différent. Ce qui nous a permis, donc, de les identifier sans difficultés, et de les ajouter au #pare-feu. Ouf. On a eu de la chance.
En fin de nuit, rebelote, pendant 2 heures, saturation. Vérification de ce qu’on trouve. Plus de 4000 adresses, dans des blocs contigus, du monde entier, Singapore, US, ...
Les pays du monde entier votent des lois pour imposer l’installation d’applications gouvernementales sur les périphériques. Je serais un politicien bien malveillant comme pour ceux qu’on vote dans mon coin de Lyon, j’utiliserais ces applications pour faire des #DDOS sur les contenus qui ne me conviennent pas, afin que les IP de mon pays soient blacklistées par les administrateurs des contenus qui ne me conviennent pas. Voire, je ferais des accords avec les pays qui ont les mêmes velléités que moi, pour que ça soit plus discret.
Les changements de version notables :
– Debian 8 > Debian 13
– PHP7.1 > PHP8.4
– SPIP 3.2 > SPIP 4.4.13
– Sphinx 2.3 > Manticore 17.5
La nouvelle VM a les mêmes ressources que l’ancienne :
– Hyperviseur Proxmox
– RAM 24Go
– Processeur 6 cœurs
– Disque 650Go (NVMe)
Elle est hébergée sur Roubaix quand l’ancienne est à Gravelines. Nous allons ramener la nouvelle VM sur Gravelines d’ici quelques jours.
Un succès total, merci @biggrizzly !
Maintenant les gens vont pouvoir poster des webp... (même s’il y a certainement d’autres nouveautés que je n’ai plus en tête).
Au top ! Merci à vous qui vous y collez...
On voit sur ▻https://git.spip.net/groups/seenthis/-/activity que vous êtes bien peu à vous démener pour que ça tourne
谢谢
(car pour moi, c’est du chinois)
Je poste un svg sans faire râler le serveur !
je ne sais si cela est en rapport avec le bond technologique effectué mais un seen qui ne se présentait pas ainsi auparavant (?) est en ligne ▻https://seenthis.net/messages/1161496
J’aime vraiment @seenthis comme Cosmic Psychos Really Really Really Like Beer
Sinon, la prochaine étape, c’est le datacenter ? Non, parce que vu l’orientation que prennent certains ici, il va falloir s’y atteler ...
▻https://seenthis.net/messages/1162307
C’est exactement ce qu’on a vécu avec le Minilecte hier :
@colporteur comme je le disais plus haut, suite au passage en #SPIP 4 @seenthis prend enfin en charge les images webp.
oui, bravo et merci à tou·te·s !
pour la rénovation, bien sûr, mais aussi, pour le quotidien
sans parler, des concepteurs/ conceptrices aux petites mains, qui ont pondu les mécaniques et les algos qui font tourner tout ça
Les emails doivent être de retour.
J’ai réalisé deux sélections d’IP louches. Cela a représenté une moisson de 22000 IP.
Potentiellement, une des sélections peut avoir inclus les adresses IP de personnes fréquentant SeenThis en mode non-connecté. J’espère que vous n’en faites pas partie. N’hésitez pas à le signaler par un canal ou un autre...
La charge du serveur est divisée par 2. Et j’espère que les gros pics d’indisponibilité vont avoir été bloqués, eux aussi.
Par contre ce matin, impossible d’accéder à la page d’accueil ni aux liens diffusés par le mail de @7h36.
Super bravo et mille mercis pour ce travail inestimable ! Apprécié vraiment à sa juste valeur qui est immense.
❤️
Et c’est quoi les canaux parallèles @biggrizzly ? À qui on s’adresse en cas be black-out de @seenthis comme le week-end dernier. J’ai pas trop insisté, enfin je me suis connecté avec un autre appareil pour conclure que ça venait de #Seenthis et de son déménagement. à Roubaix (encore LFI qui fout la merde Guiraud grand favori pour le second tour avec 46,64% (8560 voix pour 62,38% d’abstention).Hier tout semblait être revenu à la normale, comme avant que vous changiez de machine. Mais ce mardi, voilà que ça recommence
502Gateway (connexion impossible) ça commençait à branler du manche début mars déjà. Je crois que je vais faire une pause quelques temps. Le beau temps revient, je vais aller faire un tour plutôt que de me prendre la tête avec vos problèmes techniques
Désolé pour le #blacklistage @vanderling c’est parfois compliqué de ne pas moissonner trop large. J’ignore quels pourraient être les canaux parallèles. Mastodon ? J’y suis, et d’autres ici y sont. Tu aurais pu insister, j’aurais tâché de corriger plus vite mon empressement à bloquer les #botnets.
Si j’ai bien compris @biggrizzly tu as mon adresse IP, donc je ne suis pas un botnet. J’ai bien repéré @monolecte @davduf @7h36 S. Bortzmeyer… sur Mastodon/Piaille mais je ne suis que sur seenthis aucun autre compte ailleurs et surtout pas sur X ou autre Meta-bollocks. Enfin pour l’instant la connexion à l’air de tenir.
vos problèmes techniques
=> nos problèmes techniques à tout⋅es
Rappel : il n’y a pas de magie derrière seenthis, juste du code qui tourne sur une machine , et tout ça est géré par des humains pour d’autres humains qui aiment utiliser le bouzin :)
@vanderling, je n’ai pas compris que tu aies été spécifiquement bloqué. Cet après-midi, c’est tout le site qui a affiché l’erreur 502 pendant de longues minutes pour tout le monde, pas juste pour toi.
Parce qu’on a subi une attaque assez massive, avec 1000 machines avec chacune une dizaine de user-agent différents qui ont bloqué Seenthis. Ce que @biggrizzly a finalement réussi à bloquer.
▻https://seenthis.net/messages/1163113
Ce qui se passe, encore une fois, c’est qu’on se prend des passages absolument massifs de bots, avec des milliers de machines qui se branchent sur Seenthis et qui rendent son utilisation très lente voire totalement bloquée.
Et c’est justement l’une des principales raisons du déménagement de la semaine dernière : passer sur une machine plus moderne, ce qui permet à @biggrizzly d’accéder à des outils plus précis et performants pour identifier ces attaques et les bloquer. Ce qu’il fait au fur et à mesure, c’est évidemment ça ne va pas se faire du jour au lendemain, encore aujourd’hui lui et @b_b ont discuté de configurations (auxquelles je ne comprends pas grand chose) pour améliorer la détection de ces bots.
Il faut donc comprendre que le déménagement n’était que la première étape pour qu’ils disposent d’outils (impossibles à installer sur l’ancienne machine) pour pouvoir mieux contrer ces passages massifs de bots, et au fur et à mesure mettre en place les contre-mesures techniques. Mais forcément, ça va se faire au fur et à mesure.
–---
Signalons aussi que Seenthis est sur une seule machine, et qu’avec un seul serveur on tente de bloquer les bots qui, eux, viennent de centaines de machines en même temps. Le souci écologique est clairement de notre côté…
Vous faites un sacré boulot en tout cas, vu de mon passif dev puis admin puis enseignant-chercheur (et bientôt retraité, youpiiiii !), je loue votre constance. Osana et toutes ces sortes de choses. Longue vie à seenthis.
En fin de semaine dernière, j’ai étudié les IP qui se connectaient, et tenté de détecter un schéma de consultation qui permettrait de décider qu’une IP est un bot. J’ai décidé un petit peu rapidement que les IP qui consultent certaines pages sans être connecté étaient des bots. Ça m’a permis de bloquer 10000 IP distinctes, et je ne me suis rendu compte que je m’étais auto-bloqué à mon domicile qu’au moment de couper le VPN pro... Il m’a fallu le WE pour m’en rendre compte, et encore 24 heures de plus pour décider de supprimer ces 10000 IP du firewall ; parfois, je suis lent à la détente. Je ne connais donc pas ton IP en particulier @vanderling, mais par contre, ton IP peut se retrouver au milieu de milliers d’autres sans autre raison qu’une erreur de jugement de l’un d’entre nous, et comme c’est moi en ce moment en particulier qui m’y colle, et bien voilà.
Aujourd’hui, dans l’après-midi, nous avons, comme le relate @arno, eu à gérer un millier d’IP particulièrement sauvages, qu’il a heureusement été relativement facile d’identifier, au moyen des nouveaux outils d’analyse des logs, que nous avons enfin pu mettre en place, du fait de la nouvelle machine.
Tout ce que nous avons fait ces dernières semaines nous permet de relancer des projets d’évolution, qui avaient été à tort laissés de côté. Travailler sur un environnement obsolète, ça ne motive pas forcément pour réaliser des évolutions, et quand je constate que nous avons entamé l’installation de ce nouvel environnement il y a déjà 2 ans, je me dis que mieux vaut tard que jamais... mais on pourrait sans doute être un petit peu plus efficace ! :-))
Entre autres travaux de fond, que nous avons pu commencer, merci @b_b pour ta disponibilité et ton accompagnement, nous tâchons d’optimiser et d’isoler certains traitements présents dans le code de SeenThis et de SPIP qui normalement ne posent pas de difficultés, mais qui lorsque les bots agressifs deviennent la normalité sont de vraies failles de sécurité pour la stabilité de l’environnement. Je pense par exemple à la façon dont SeenThis calcule les blocages de comptes. Quand il est nécessaire de calculer la page d’accueil d’une page /people/, les requêtes effectuées sur la base de données sont peu performantes, en particulier quand le people en question bloque beaucoup de monde. Ces requêtes sont probablement améliorables. Et toute amélioration assure que la prochaine attaque fera moins de dégâts, et ce sans nécessité de rajouter des ressources (processeur, mémoire...).
Ci-dessous, le nombre de processus simultané qui servent des pages pour SeenThis. En général, on sert moins de 20 pages en même temps. Quand la barre est toute rouge, cela signifie qu’on a 100 processus qui tournent en même temps. Et ce sont ces moments où on se retrouve bloqué, à ne rien pouvoir lire ni publier, avec des erreurs 502, des gateway time-out, etc.
Le botnet était passé, visiblement, déjà une fois dans la nuit. Puis à nouveau dans l’après-midi. On constate qu’une fois le blocage en place, le serveur est revenu dans le vert, sans dépasser les 40 processus actifs. Pourvu que ça dure !
Je ne mesure pas la tache du problème mais je plussoie à vos efforts et à votre perspicacité pour faire tourner la boutique ainsi que la maintenance de ce formidable rézo. J’y passe bcp de temps, trop peut-être mais bon je ne vais quand même pas aller travailler. V’là le printemps qui pointe, je préfère laisser mon temps de cerveau aux petits oiseaux ou sur seenthis. @biggrizzly @arno @b_b
des nouveaux outils d’analyse des logs
@biggrizzly, quels sont ces nouveaux outils, j’ai des problèmes similaires.
Les gens qui vous occupez du « bouzin », vous menez un combat d’arrière-garde et vous faites partie de l’obsolescence programmée par les instances IA/LLM et c’est pour ça qu’on vous aime :-)) Maintenant, quand ça rame, je me dis qu’il faut savoir patienter et revenir plus tard car je sais que vous êtes au charbon pour décoincer tout ça. Force à vous et grand merci pour votre investissement personnel ! 🖤🖤🖤
@george : nous utilisons des outils à la fois artisanaux, et industriels.
Industriels : nous transférons les journaux du serveur web dans un entrepôt de donnée de type ElasticSearch (ELS). Ce transfert n’est pas naturel, il faut disposer d’un format de log plus ou moins normalisé, et créer un index dans ELS pour recevoir ces données, puis générer des visualisations et des tableaux de bord, pour analyser ces données.
Artisanaux : L’analyse dans ELS est réalisée à la main. Pas d’automatisme actuellement. Il faudrait ajouter de l’intelligence à tout cela, des automatismes, pour détecter les comportements manifestement malveillants, et les bloquer dans le pare-feu sans intervention humaine. Mais là, il faudrait faire le travail que fait CloudFlare par exemple.
Et puis il y a le fait que ce n’est pas logique de décider de bloquer le monde entier, parce que le monde entier est utilisé comme un botnet.
Si tu as des soucis sur un petit site, je conseille d’installer Anubis. C’est une solution à moindre coût et qui rend le service attendu dans la plupart des cas.
▻https://github.com/TecharoHQ/anubis
Peut-être qu’ici aussi on y arrivera... :-/
J’ai installé Anubis sur un serveur avec un site moyennement fréquente mais a part le ralentissement j’ai l’impression que les bots réussissent à le traverser.
J’ai du m’y reprendre à 3 fois, du fait que LibreOffice, pour manipuler 10000 lignes, c’est décidément beaucoup moins performant que de le faire avec Excel. C’est même carrément source d’erreurs de calculs. Pénible et décevant.
Bref, j’avais 10000 adresses IP candidates. Il fallait tout de même que je retire les adresses susceptibles d’être de vrais utilisateurs. Par exemple cette adresse IP Orange, avec 3 ou 4 user-agent différents, et 10 ou 20 pages consultées seulement... par exemple.
J’ai bloqué, finalement, seulement 8700 adresses IP de plus. De longues séries de blocs d’IP avec quelques requêtes, et un nombre équivalents de user-agent distincts. Il se peut qu’on soit tranquille pour quelques jours avec ce dernier filtrage. On verra.
Comme je le disais hier soir : « jusqu’à la prochaine fois ».
A priori, on a gagné, donc, un répit de quelques jours/semaines. Les processeurs vont moins travailler, et on va moins avoir envie de réécrire certaines fonctionnalités.
La formule « nombre de user-agent distincts » vs « nombre de requêtes » vs « nombre d’ip sur la même classe B » semble fonctionner.
Je viens de collecter à nouveau des IP sur la base de ces critères sur les dernières 24 heures. 8200 adresses IP bloquées.
– critère 1 : « nombre de requêtes » / « nombre de user-agent distincts » < 5
– critère 2 : « nombre d’ip sur la même classe B » > 5
Notre second ipset contient désormais 61K adresses IP distinctes.
Pour rappel, le premier ipset a été construit l’an dernier, il contient 1,5M d’adresses IP distinctes, et les IP ont été découvertes du fait qu’elles réclamaient des URLs invalides.
Le serveur vit bien mieux sans ces 61K adresses, vous l’aurez constaté, du fait qu’il n’y a pour ainsi dire quasiment plus de lenteurs. Nous allons probablement pouvoir rouvrir la porte aux vrais bots.
Pool FPM sur les 5 derniers jours :
Les #botnets...
Vous me suivez régulièrement, sur ces problématiques. Nous avons des botnets qui interrogent SeenThis avec régularité. Certains de ces botnets provoquent des montées en charge violentes, ce qui provoque, pour les utilisateurs, des indisponibilités pénibles.
J’avais remarqué, il y a quelques semaines, que les navigateurs concernés, portaient la signature « MSIE », Internet Explorer (et arrivant tous de Chine, apparemment, d’après leurs IP). Or, ce #navigateur n’est plus supposé fonctionner désormais. Aussi, j’ai implémenté une protection soulageant fortement le serveur : si le serveur web constate cette signature, il répond directement l’erreur « 444 », sans autre forme de traitement. J’ai aussi ajouté ClaudeBot et AmazonBot à ce traitement. Les autres bots sont traités par la protection de SPIP, c’est à dire que si la charge est trop élevée, ils reçoivent une erreur 429.
Jusqu’à hier, cela fonctionnait plutôt de manière satisfaisante. Mais hier, nous nous retrouvions bloqués plusieurs fois par heure, au moment de publier ou de lire.
Aussi, j’ai pris le temps d’implémenter le blocage des erreurs 444 par fail2ban. Et... depuis... la charge du serveur est normale. Epatant.
Pour expliquer : #fail2ban regarde quelles IP ont fait l’objet d’un blocage par le serveur web (l’erreur 444), et s’il y a eu plus d’un blocage, on décide de bloquer l’#IP directement dans le #pare-feu, c’est à dire qu’on refuse toute connexion. On réalise le #blocage encore plus tôt, pour encore plus soulager la machine.
Par contre, dans l’heure qui a suivi, 200 à 300 IP bloquées. Une demi-journée après, 5000 IP bloquées. Et ce matin, on en est déjà à 36928 IP bloquées !
Face à un tel afflux d’IP, fail2ban va vite être insatisfaisant, le pare-feu ne va pas pouvoir ingurgiter des IP à l’infini... mais c’est une expérience intéressante malgré tout... A suivre :-)
C’est proprement hallucinant cette vitesse d’emmerdification.
47033 IP bloquées ce soir. :-)
Face à un tel afflux d’IP, fail2ban va vite être insatisfaisant, le pare-feu ne va pas pouvoir ingurgiter des IP à l’infini...
Et en étendant le blocage au sous-réseau, genre /24 ? J’imagine que beaucoup de bots MSIE sont sur les mêmes infra...
Les /24 les plus présentes, sur les 43000 IP environ bloquées ce jour (je conserve le blocage 24 heures) :
157 112.194.192
157 114.104.135
157 117.69.191
158 114.104.134
158 121.225.84
158 183.166.137
162 117.69.159
164 117.69.190
165 112.194.194
165 183.166.170
166 183.166.136
179 175.155.3
186 175.155.2
221 125.72.106Et on décompte 3225 blocs distincts /24. Je suis en train de réclamer le décompte des « country » de chacun de ces blocs. C’est un petit peu long...
Voilà, les pays des blocs d’IP :
12 cn
2998 CN
1 FR
11 HK
8 JP
1 NL
1 PH
21 USAh, on se rapproche de 256...
215 175.155.3
216 112.194.193
216 112.194.194
216 112.194.195
226 175.155.2
248 125.72.106Depuis que j’ai augmenté la rétention des IP bloquées à 10 jours, on est monté à 75254 IP bloquées.
Je constate aussi que nous avons des surcharges différentes. Plus difficiles à bloquer, j’imagine, puisque de la part de machines qui ne se déclarent pas « MSIE ». Si je parviens à trouver qq chose, je vous tiens au courant :-))
On arrive à un palier : 75480 IP. Les bots à base de MSIE sont tous recensés. Il faudrait maintenant parvenir à bloquer les autres...
215 121.225.84
215 175.155.3
216 112.194.193
216 112.194.195
217 112.194.194
227 175.155.2
248 125.72.106Depuis ce matin, croissance à nouveau des IP bloquées : 91183.
On se rapproche des 256 IP pour certains blocs :-)
230 183.166.170
231 112.194.194
232 112.194.195
233 112.194.193
234 175.155.3
241 175.155.2
251 125.72.106Ce matin, 105414.
Explication : les PC qui font partie du botnet sont connectés à des lignes Internet dont les IP ne sont pas fixes. Quand le bail DHCP expire, l’IP change. Ce qui explique que les blocs aussi se rapprochent des 256 adresses. En somme, ce n’est pas le botnet qui grandit, ce sont les IP des connexions qui changent.
241 112.194.194
243 112.194.195
245 112.194.192
245 112.194.193
245 175.155.2
246 175.155.3
251 125.72.106Les IP s’amoncellent.
250 175.155.2
252 112.194.192
252 112.194.195
252 125.72.106
253 112.194.193
253 175.155.3
254 112.194.194Décompte IP : 131667
Blocs /24 : 4449 (soit un potentiel de 1,1 millions d’IP)
Répartition des blocs par pays :
4095 CN
45 HK
25 US
19 cn
8 DE
8 FR
8 JP
3 GB
3 TW
2 NL
2 PH
2 RO
1 AT
1 ES
1 KR
1 MA
1 PL
1 SE
1 SG
1 ZAUne vraie galère pour pouvoir poster quelque chose hier ...
Des news. Apparemment, les chinois sont en vacances. Ou SeenThis n’est plus dans leurs objectifs.
Plus que 220 IP bloquées.
L’appartenance des blocs reste majoritairement en Chine.
1 AT
34 CN
1 DE
1 ES
3 FR
15 HK
1 JP
1 KR
3 NL
1 SG
2 TW
10 US Apparemment, les chinois sont en vacances.
Ou alors, ils en ont appris suffisamment sur nos « démocraties » ...
OVHcloud reports DDoS attacks by botnet of MikroTik core routers
▻https://stackdiary.com/ovhcloud-reports-ddos-attacks-by-botnet-of-mikrotik-core-routers
A recent analysis by OVHcloud reveals a new trend in Distributed Denial of Service (DDoS) attacks. The cloud provider’s security team has identified a botnet of compromised MikroTik core routers responsible for high packet rate attacks, which have increased significantly in frequency and intensity since the start of 2023.
Si les MikroTik forment des #botnets, on est mal barré... (ces matériels étaient supposés être les rolls du routeur).
C’est intéressant : il y a quelques semaines, il y a eu ▻https://blog.sofiane.cc/ssh_honeypot qui explicitement citait les MikroTiks comme des cibles potentielles.
RFC 8073 : Coordinating Attack Response at Internet Scale (CARIS) Workshop Report
Ce nouveau #RFC fait le bilan de l’atelier CARIS (Coordinating Attack Response at Internet Scale) qui s’est tenu à Berlin le 18 juin 2015. Cet atelier avait pour but d’explorer les problèmes de coordination entre les victimes et témoins d’une attaque portant sur l’Internet. Ce RFC est un compte-rendu, les positions exprimées ne sont pas forcément celles de l’IAB ou de l’Internet Society (organisateurs de l’atelier). D’autant plus que les participants ont mis les pieds dans le plat, expliquant très bien pourquoi il n’y a toujours pas de coordination globale des acteurs de l’Internet face aux attaques. (La plupart des rapports sur la #cybersécurité sont des monuments de lourde langue de bois, où on ne dit jamais ce que tout le monde sait, mais qui fâche. Par exemple que les acteurs de l’Internet ne partagent pas facilement avec les autorités, tout simplement parce qu’ils n’ont pas confiance - et ils ont bien raison.)
(bon, j’ai un peu de retard dans mes lecture)
La liste des participants figure dans l’annexe B du RFC
Or, il n’y pas d’annexe B, uniquement une annexe A avec la liste des participants.
Les tentatives des certains États
de*
@claudex Exact, l’annexe A avait été supprimée au dernier moment, faisant que l’ancienne B devienne A. Merci, c’est corrigé.
J’ai lu "Confession d’un pédophile : l’impossible filtrage du Web"
▻http://archives-lepost.huffingtonpost.fr/article/2010/02/01/1918529_j-ai-lu-confession-d-un-pedophile-l-impossibl
PS : Je rappelle que le PDF téléchargeable est gratuit et ne contient aucun élément de pédophilie
▻http://www.ilv-bibliotheca.net/librairie/confession_dun_pedophile_limpossible_filtrage_du_web.html
▻http://www.ilv-edition.com/images/librairie/couvertures/confession_dun_pedophile_limpossible_filtrage_du_web.jpg
bon voilà, avec trois ans de retard j’ai lu ce #livre ; en me bouchant un peu le nez pour la préface (Robert Ménard). Il propose notamment trois longs textes, assez intéressants, sur la problématique du #filtrage (ou #censure) du net qui se met en place pour lutter contre la pédopornographie.
Le journaliste Fabrice Epelboin présente un texte rédigé par un ancien administrateur (anonyme) de serveur d’images pédophiles. Il explique en détails comment selon lui fonctionne techniquement et économiquement ce business, qui selon ses estimations « pèse » environ 20 millions de dollars/an ; il souligne au passage que (d’après lui toujours) ce sont les opérateurs financiers (banques fermant les yeux, etc.) qui en extraient le maximum d’argent.
Et il décrit (c’est peut-être ça le plus intéressant) comment les opérateurs de ce genre de service emploient des spécialistes de différents types de criminalité électronique (blanchiment, piratage de carte bancaire, #botnets, virus, et surtout le #spam qui permet d’atteindre les clients, notamment quand le DNS est bloqué).
Deux « chasseurs de pédophiles », un expert judiciaire britannique et un ancien gendarme-enquêteur français, prennent ensuite position contre le filtrage du Web, arguant que ça ne sert à rien, à part à rassurer le public de TF1 en montrant qu’on fait quelque chose, et attraper des petits consommateurs imprudents : « filtrer internet ne portera atteinte ni à la capacité des marchands de commercialiser leur offre, ni à celle des consommateurs d’y accéder ». Et tandis qu’on privilégie ces non-solutions, les moyens manquent pour mener de vraies enquêtes qui pourraient remonter les filières.
Je n’évoque pas le reste (Champeau, Pasquini et Zimmerman), mais c’est bien aussi.
ah mais je suis con, c’était suite à ton post, j’aurais dû le citer :
▻http://seenthis.net/messages/211584
Windows XP : 2014 un vrai risque
▻http://www.commentcamarche.net/faq/38256-windows-xp-2014-un-vrai-risque
Migrer vers Windows 7 voir 8 aura un coût, si votre ordinateur en support les recommandations.
Je vois mal un Pentium avec 512 Mo de ram tourner.
Vous pouvez migrer vers Linux qui aura les avantages d’avoir aucun coût, de fonctionner sur de vieille machine et être à l’abri de toutes infections.
#windows-xp
#gnu/linux
#512-Mo-de-ram
#hackers
#pirates
#botnets
#avril-2014
Une carte animée illégale d’Internet par 420.000 botnets sous Linux
▻http://neosting.net/actualite/carte-internet-420-000-carnabotnets-linux.html
Pour le fun, un chercheur anonyme a voulu créer une carte pour montrer l’activité d’Internet. Mais, pour réaliser son exploit, il a créé un hack, le Carna Botnet, afin de faire des botnet dont le but est de définir leur présence sur la toile grâce au ping. Les cibles sont ... #botnets #carte #internet #linux
Les gérants du groupe #HostExploit compilent un rapport régulier sur les plus grosses sources de Mal de l’Internet, c’est à dire les systèmes autonomes hébergeant le plus de centres de commande de #botnets, le plus de serveurs de #hameçonnage, envoyant le plus de #spam... Un Who’s who des acteurs de l’Internet, sous l’angle négatif. Dans le dernier rapport, numéroté Q32012, on note un nouveau n° 1 de ce classement, #Confluence, et l’arrivée du français #OVH dans le sommet.
Bitcoins: What are they, and how do they work? | Technology | guardian.co.uk
►http://www.guardian.co.uk/technology/2011/jun/22/bitcoins-how-do-they-work
Credible reports suggest some individuals connected to Anonymous have #botnets with more than 100,000 active computers. A network of this size, even mining #Bitcoins inefficiently, has the potential to generate 400 to 500 coins a day – worth in excess of $7,500 before the crash.