Suite à une cyber-attaque survenue courant septembre la majorité des données ont été détruites. À ce jour je n’ai pu restaurer qu’une partie de l’infrastructure. Pour des raisons financières je ne peux assurer un service de backup performant. Ce sont avec mes modestes moyens et temps libre que j’essaie de proposer des services libres et transparents mais seulement cela devient plus compliqué à gérer étant seul et que ma vie familiale et professionnelle mais non seulement compte tenu de l’inflation, tous cela ne permet plus de maintenir WEBLIB.RE convenablement.
C’est avec regret que j’ai décidé de mettre fin à une aventure de plusieurs années. WEBLIB.RE s’arrêtera au plus tard le 31 décembre 2023. De plus je quitterai le collectif CHATONS.
Autrement rien est fini pour autant, j’espère bien vous retrouver sous d’autres formes pourquoi pas !
Je me pose plusieurs questions, n’hésites pas à y répondre en MP si tu préfères:
vu que tu utilises YunoHost, je suis curieux de savoir la nature de cette cyber-attaque (app visée, etc.).
le nombre d’utilisateurices
le budget global de ton chaton actuellement (et le détails des coûts)
la quantité de données à sauvegarder
la nature de la destruction de données (est-ce que par exemple tu as des fichiers de base de données que tu n’arrives pas à restaurer)
à quel point la question de l’argent est prépondérante dans ta décision.
Si jamais, ta décision est vraiment arrêtée mais que CHATONS continue quand même de t’intéresser, n’hésites pas à nous rejoindre chez ARN (il y a notamment du YunoHost dans l’infra). arn-fai.net
Salut, bon courage ! Ça a dû être dur psychologiquement de se prendre une attaque, prends soin de toi.
N’hésite pas à participer aux évènements physiques et virtuels CHATONS, si tu as à nouveau le temps, tu es bienvenu.
Merci à toi
Effectivement très dur à surmonter surtout lorsque le prestataire chez qui tu loues ton serveur (OVH pour ne pas le citer) te bloque ton compte et te laisse un accès rescueftp à 10 balles pour soi-disant récupérer tes données et l’obligation de réinstaller tout pour pouvoir récupérer le serveur avec « le couteau sous la gorge ». Certes ils ont protégé leurs infrastructures ce qui est logique car le serveur après avoir été ravagé a servi à envoyer des requête UDP vers des port 22.
Tout ça pour répondre à @ljf Yunohost n’y est pour rien. Juste que j’héberge quelques sites et l’un d’entre-eux, un spip présentait une faille de sécurité. Une fois de plus je me rends compte que je n’ai pas le temps de surveiller l’activité de weblib.re. Tout seul c’est devenu ingérable. Maintenant je préfère me consacrer à d’autres projets toujours dans le libre, l’esprit serein, mais qui sont en stand-by depuis.
En quelque-sorte découragè mais si je dois remonter un CHATONS ça sera à plusieurs voire en association par exemple avec plus de moyens
Arf, ton SPIP ne devait pas être à jour et tu as été victime de la faille qu’on a corrigé en février cf https://blog.spip.net/Mise-a-jour-critique-de-securite-sortie-de-SPIP-4-2-1-SPIP-4-1-8-SPIP-4-0-10-et.html, celle-ci a été activement exploitée chez un paquet d’hébergeurs. Chez Infini on héberge beaucoup de vieux SPIP (c’est un peu le musée du SPIP chez nous) et on a du faire le ménage dans pas mal de sites après avoir déployé l’écran de sécurité de SPIP de manière globale afin de les protéger dans l’urgence.
Oui et non… En vrai, on pourrait généraliser certaines contre-mesures génériques sur ce sujet (actuellement incluses dans les paramètres de sécurité expérimentales activables via les paramètres généraux). Ça n’est pas encore fait car on a peur de casser des apps en le faisant…
Je pense qu’on est plusieurs à comprendre cette question de la sérénité. On pourrait faire un sondage anonyme « Qui est totalement serein⋅e avec ses infras ? ».
Salut,
C’est exactement ça, le spip en question etait en v4.0.8. Et pourtant je suis à cheval sur les mises à jour, sécurité…Mais encore une fois je le redis, le manque de temps et j’avoue qu’en ce moment je reporte tout au lendemain constamment.
Et en ce moment aussi c’est la nuit pour recoller les morceaux et dans la foulée faire les mises à jour
Autrement merci pour toutes ces infos, ce qui me rassure c’est que je ne suis pas un cas à part
Si je pose la question c’est parce que samvermeulenpro a visiblement mis le doigt sur un problème, ce serait dommage que son expérience ne soit pas profitable à tous. Je sais que ce n’est pas forcêment intuitif mais une catastrophe est une opportunité rare de trouver comment améliorer les choses.Pour les motivés la lecture des normes iso9000 explique ça bien mieux que moi. https://www.iso.org/obp/ui/#iso:std:iso:9000:ed-4:v2:fr
Tu fais bien de souligner ce problème firewall autant j’aurais préféré l’avoir désactivé plutôt par mégarde. Mais hélas vu le contexte je pense que le ou les hackers ont fini par prendre le contrôle du serveur. Je n’avais plus accès au root jusqu’à que OVH coupe le traffic et met le mode rescue
Je suis tout de même très étonné qu’une faille dans spip mette par terre une infra complète. Ce serait bien de revenir sur cette attaque, savoir précisément ce qui s’est passé et où étaient les failles ? Ce genre de mésaventures peut arriver à tout le monde, plus on échange là-dessus plus on se renforce.
Entièrement d’accord avec toi @manu58, le retour technique sur ce type d’attaque mériterait bien une analyse plus poussée et une transmission au collectif du résultat.
de ce qu’en a dit samvermeulenpro une faille dans spip a permis a un attaquant de spammer en udp sur le port 80, après quoi OVH a réagis en bloquant complétement le serveur qui contenait le gros de l’infra de son chaton avec obligation de le réinstaller from scratch pour pouvoir continuer a le réinstaller. Ce n’est pas la faille qui à casser le chatons mais la réaction disproportionnée de OVH (bloquer le serveur est compréhensible mais imposer une réinstallation from scratch est un peu abusé).
Que ce soit Spip ou un autre CMS, il est préférable de ne pas permettre les commandes exec de php.
Alors certes ça limite beaucoup de fonctionnalités, mais, mine de rien, ça évite beaucoup de soucis.
Ensuite, il y a la séparation dans des conteneurs ou des VM, pareil, ça ralenti ou réduit une partie de la propagation.
Je note de filtrer certains ports sortants, bonne idée.
En 2019 j’avais fait une petite présentation de comment mon serveur de l’époque s’était fait compromettre via une CVE dans mon h5ai - un soft PHP - pas patché. Ma conclusion de l’époque c’était que je connaissais les contre-mesures qui auraient évité le problème mais que je ne les avais pas mise en place, et que c’était intéressant de se questionner sur le pourquoi.
La volonté de faire cette présentation, c’était aussi que c’est un sujet tabou de se faire hacker, c’est la honte. Mais en fait ça arrive à beaucoup de monde, y compris des gens très sérieux et compétents, et souvent sur des trucs qu’on trouve un peu débile. Du coup parlons-en
