Bonjour, J'ai un serveur "bare metal" chez OVH, avec une Ubuntu, inclus (ex LXD) et une série de containers. Ce matin mes services étaient hors ligne : le serveur était passé en mode "hack" par OVH. J'ai redémarré le serveur et stoppé tous les containers. D'après vous, comment procéder pour isoler et nettoyer le container fautif ? Merci
Simple : - Détruire le container - Installer un container propre.
De: "Franck Routier (perso) via FRsAG" <frsag@frsag.org> À: "frsag" <frsag@frsag.org> Envoyé: Mardi 1 Octobre 2024 13:16:03 Objet: [FRsAG] Container hacké, que faire
Bonjour,
J'ai un serveur "bare metal" chez OVH, avec une Ubuntu, inclus (ex LXD) et une série de containers. Ce matin mes services étaient hors ligne : le serveur était passé en mode "hack" par OVH. J'ai redémarré le serveur et stoppé tous les containers. D'après vous, comment procéder pour isoler et nettoyer le container fautif ?
Merci
_______________________________________________ Liste de diffusion du %(real_name)s http://www.frsag.org/
Xav, Je crois que Franck ne sait pas quel container est fautif… J’ai envie de dire d’éteindre tous les containers, les allumer un par un, et prendre une trace réseau à chaque fois à la sortie de chaque container pour tenter de détecter du traffic anormal. Je suppose qu’ils sont en privée et que l’hôte les NAT ? Dav
Le 1 oct. 2024 à 13:27, Xavier Beaudouin via FRsAG <frsag@frsag.org> a écrit :
Simple : - Détruire le container - Installer un container propre.
De: "Franck Routier (perso) via FRsAG" <frsag@frsag.org> À: "frsag" <frsag@frsag.org> Envoyé: Mardi 1 Octobre 2024 13:16:03 Objet: [FRsAG] Container hacké, que faire Bonjour,
J'ai un serveur "bare metal" chez OVH, avec une Ubuntu, inclus (ex LXD) et une série de containers. Ce matin mes services étaient hors ligne : le serveur était passé en mode "hack" par OVH. J'ai redémarré le serveur et stoppé tous les containers. D'après vous, comment procéder pour isoler et nettoyer le container fautif ?
Merci
_______________________________________________ Liste de diffusion du %(real_name)s http://www.frsag.org/ _______________________________________________ Liste de diffusion du %(real_name)s http://www.frsag.org/
Bonjour L'outils trivy (https://github.com/aquasecurity/trivy) permet de détecter les vulnérabilités connues inclues dans les containers. David Dr David ANSART Formateur en Informatique : Réseau Système Cybersécurité Développement C/C++ https://github.com/Raizo62 david.ansart@seineetmarne.cci.fr +33 1 60 37 41 11 CFA UTEC INT<https://www.utec77.fr/> (https://www.utec77.fr<https://www.utec77.fr/>) 6 Boulevard Olof Palme CS 60150 Émerainville 77436 Marne-la-Vallée CEDEX 2 [https://ci3.googleusercontent.com/proxy/femEefITJ0c36VknQvisYFKWAiJicpdYWDkXQYrwj4EyW8HzTIwM-OiPIgvc-3hMshCt5-2X4sasp4qtihNhdntEdqk1OyohTJlawto0NKna_RTy2q4bYUlMRzGbruYITiSy-9yyKAnk6mns3uHWq_xxMFOMA0aEsHT9dO881YZl1igkFgpP34bV8X_VRL0AWkurrvw_xSc00kzDwJi8tVE=s0-d-e1-ft#https://cdn-assets.facelift-cloud.com/uploads/assets/2541/20210222085007_6anjgfig444c4wwsg804kc0040ggc0okwwg00gg44ckkkw8cs4.png?1613983841961]<https://www.utec77.fr/> [https://ci3.googleusercontent.com/proxy/PrAv608xsWQ17Jtudf-ZkhHZmZ8lh6TXBNnFAR6RMIFnJY_My2QFV_UHLki3hcZxxjbNifwhG3Krrf59lkCCyKmNDnkbN1PESaVs4rtcDfDpL0UvS-Pnad7sgpNB1CG0dcEP8VPpBF4z3BFCIqfbQHm8ZGfWl0ug1d2mpDP0ruUSVGc2yQJ4bG06q0mZBW0InvU=s0-d-e1-ft#https://cdn-assets.facelift-cloud.com/uploads/assets/2541/20210121073258_2b5vkt4cpqhww0ogoss0w8kcs44c80ko0w8ws4g48k8k08oc40.png]<https://www.linkedin.com/company/utec77-cfa-utec> [https://ci3.googleusercontent.com/proxy/AIzrqWTFNKF5v5i9fDWhKKJKcXWDJ9Z5hXyo...] <https://fr-fr.facebook.com/utec77.formations/> [https://ci6.googleusercontent.com/proxy/8Jn-_XkFHlT_Fo67dJ-_mnkYfmfpCvb5RZXx...] <https://twitter.com/utec_77> [https://ci6.googleusercontent.com/proxy/UzISzyJKz18dGYAuUjE0fYjVrb4OXaZRqcDM...] <https://www.instagram.com/utec77/?hl=fr> ________________________________ De : David Ponzone <david.ponzone@gmail.com> Envoyé : mardi 1 octobre 2024 14:39 À : Xavier Beaudouin <kiwi@oav.net> Cc : frsag <frsag@frsag.org> Objet : [FRsAG] Re: Container hacké, que faire Xav, Je crois que Franck ne sait pas quel container est fautif… J’ai envie de dire d’éteindre tous les containers, les allumer un par un, et prendre une trace réseau à chaque fois à la sortie de chaque container pour tenter de détecter du traffic anormal. Je suppose qu’ils sont en privée et que l’hôte les NAT ? Dav Le 1 oct. 2024 à 13:27, Xavier Beaudouin via FRsAG <frsag@frsag.org<mailto:frsag@frsag.org>> a écrit : Simple : - Détruire le container - Installer un container propre. ________________________________ De: "Franck Routier (perso) via FRsAG" <frsag@frsag.org<mailto:frsag@frsag.org>> À: "frsag" <frsag@frsag.org<mailto:frsag@frsag.org>> Envoyé: Mardi 1 Octobre 2024 13:16:03 Objet: [FRsAG] Container hacké, que faire Bonjour, J'ai un serveur "bare metal" chez OVH, avec une Ubuntu, inclus (ex LXD) et une série de containers. Ce matin mes services étaient hors ligne : le serveur était passé en mode "hack" par OVH. J'ai redémarré le serveur et stoppé tous les containers. D'après vous, comment procéder pour isoler et nettoyer le container fautif ? Merci _______________________________________________ Liste de diffusion du %(real_name)s http://www.frsag.org/ _______________________________________________ Liste de diffusion du %(real_name)s http://www.frsag.org/ Ce message et toutes les pièces jointes sont confidentiels et/ou couverts par le secret professionnel et transmis à l'intention exclusive de ses destinataires. Toute modification, édition, utilisation ou diffusion non autorisée est interdite. Si vous avez reçu ce message par erreur, merci d'en informer son émetteur ou le signaler à cpdp@cci-paris-idf.fr. La CCI Paris-IdF décline toute responsabilité au titre de ce message s'il a été altéré, déformé, falsifié ou encore édité ou diffusé sans autorisation. Si l'objet de ce message est indiqué comme "privé", son contenu est sous la seule responsabilité de son auteur.
Je ne connais pas ce mode « hack » d’OVH ni si il y a des précisions mais qui dit que ce n’est pas le serveur hôte qui est hacké ? — Kevin
Le 1 oct. 2024 à 14:39, David Ponzone <david.ponzone@gmail.com> a écrit :
Xav,
Je crois que Franck ne sait pas quel container est fautif…
J’ai envie de dire d’éteindre tous les containers, les allumer un par un, et prendre une trace réseau à chaque fois à la sortie de chaque container pour tenter de détecter du traffic anormal. Je suppose qu’ils sont en privée et que l’hôte les NAT ?
Dav
Le 1 oct. 2024 à 13:27, Xavier Beaudouin via FRsAG <frsag@frsag.org <mailto:frsag@frsag.org>> a écrit :
Simple : - Détruire le container - Installer un container propre.
De: "Franck Routier (perso) via FRsAG" <frsag@frsag.org <mailto:frsag@frsag.org>> À: "frsag" <frsag@frsag.org <mailto:frsag@frsag.org>> Envoyé: Mardi 1 Octobre 2024 13:16:03 Objet: [FRsAG] Container hacké, que faire Bonjour,
J'ai un serveur "bare metal" chez OVH, avec une Ubuntu, inclus (ex LXD) et une série de containers. Ce matin mes services étaient hors ligne : le serveur était passé en mode "hack" par OVH. J'ai redémarré le serveur et stoppé tous les containers. D'après vous, comment procéder pour isoler et nettoyer le container fautif ?
Merci
_______________________________________________ Liste de diffusion du %(real_name)s http://www.frsag.org/ _______________________________________________ Liste de diffusion du %(real_name)s http://www.frsag.org/
_______________________________________________ Liste de diffusion du $real_name http://www.frsag.org/
Bonjour, Le 01/10/2024 à 15:27, Kevin Labécot a écrit :
Je ne connais pas ce mode « hack » d’OVH ni si il y a des précisions mais qui dit que ce n’est pas le serveur hôte qui est hacké ?
De manière générale : serveur compromis, serveur détruit. L'accès a pu avoir lieu n'importe quand et a pu être revendu plusieurs fois avant de déclencher une activité //visible// entraînant son blocage par le fournisseur. Ou pas, je n'en sais strictement rien et je n'ai pas à en juger, mais c'est malheureusement "courant"... Là concrètement il faut repartir d'une sauvegarde externe n'ayant pas pu être compromise (donc tirée par un robot externe et non poussée vers) pour l'injecter dans un serveur propre. Garde le serveur compromis au chaud pour la récupération de preuves en vue d'une procédure en justice, et prépare le dossier pour la CNIL si tu es dans le cas où la déclaration est obligatoire. Bon courage. Bien cordialement, -- Maxime DERCHE OpenPGP public key ID : 0xAE5264B5 OpenPGP public key fingerprint : 7221 4C4F D57C 456F 8E40 3257 47F7 29A6 AE52 64B5 <https://www.mouet-mouet.net/maxime/blog/>
Salut ! Bon si j'étais toi j'aurais dans tous les cas une confiance limitée au fait que la compromission ait été limitée aux containers. En tous c'est c'est une bonne illustration de pourquoi il faut éviter l'utilisation de containers privilégiés. Prends un snapshot et réimage, ne prends pas de risque
Le mardi 1 octobre 2024, 15:27:30 CEST Kevin Labécot a écrit :
Je ne connais pas ce mode « hack » d’OVH ni si il y a des précisions mais qui dit que ce n’est pas le serveur hôte qui est hacké ?
l'intuition et l'espoir... En fait j'ai arrêté tous les containers et le problème ne réapparaît pas. Mon suspect principal est un site Spip, ou le reverse proxy nginx qui dispatch les requêtes... Mais en effet, ça pourrait (aurait pu ...:-) ) être le serveur principal...
— Kevin
Le 1 oct. 2024 à 14:39, David Ponzone <david.ponzone@gmail.com> a écrit :
Xav,
Je crois que Franck ne sait pas quel container est fautif…
J’ai envie de dire d’éteindre tous les containers, les allumer un par un, et prendre une trace réseau à chaque fois à la sortie de chaque container pour tenter de détecter du traffic anormal. Je suppose qu’ils sont en privée et que l’hôte les NAT ?
Dav
Le 1 oct. 2024 à 13:27, Xavier Beaudouin via FRsAG <frsag@frsag.org <mailto:frsag@frsag.org>> a écrit :
Simple : - Détruire le container - Installer un container propre.
De: "Franck Routier (perso) via FRsAG" <frsag@frsag.org <mailto:frsag@frsag.org>> À: "frsag" <frsag@frsag.org <mailto:frsag@frsag.org>> Envoyé: Mardi 1 Octobre 2024 13:16:03 Objet: [FRsAG] Container hacké, que faire Bonjour,
J'ai un serveur "bare metal" chez OVH, avec une Ubuntu, inclus (ex LXD) et une série de containers. Ce matin mes services étaient hors ligne : le serveur était passé en mode "hack" par OVH. J'ai redémarré le serveur et stoppé tous les containers. D'après vous, comment procéder pour isoler et nettoyer le container fautif ?
Merci
_______________________________________________ Liste de diffusion du %(real_name)s http://www.frsag.org/ _______________________________________________ Liste de diffusion du %(real_name)s http://www.frsag.org/
_______________________________________________ Liste de diffusion du $real_name http://www.frsag.org/
Le 01/10/2024 à 16:29, Franck Routier via FRsAG a écrit :
Le mardi 1 octobre 2024, 15:27:30 CEST Kevin Labécot a écrit :
Je ne connais pas ce mode « hack » d’OVH ni si il y a des précisions mais qui dit que ce n’est pas le serveur hôte qui est hacké ? l'intuition et l'espoir... En fait j'ai arrêté tous les containers et le problème ne réapparaît pas. Mon suspect principal est un site Spip, ou le reverse proxy nginx qui dispatch les requêtes... Spip est un suspect crédible, comme tout CMS très populaire en PHP :-/
Mais en effet, ça pourrait (aurait pu ...:-) ) être le serveur principal...
Quoiqu'il en soit, la seule solution vraiment fiable pour gérer un serveur compromis c'est de tout réinstaller sur un serveur initialement vierge et en n'y important que des données inertes (absolument non exécutables) de tes sauvegardes (tirées depuis l'extérieur comme décrit par Maxime et inaccessibles depuis le serveur sauvegardé). Il est même possible que ce ne soit pas forcément plus long que de tester les containers un par un. Quoiqu'il en soit, bon courage ! Si tu pouvais nous en dire plus sur la compromission tel que les symptômes qui ont fait passer ton serveur en mode "hack", la façon dont il aurait été compromis, ou autres, cela pourrait nous aider…
— Kevin
Le 1 oct. 2024 à 14:39, David Ponzone <david.ponzone@gmail.com> a écrit :
Xav,
Je crois que Franck ne sait pas quel container est fautif…
J’ai envie de dire d’éteindre tous les containers, les allumer un par un, et prendre une trace réseau à chaque fois à la sortie de chaque container pour tenter de détecter du traffic anormal. Je suppose qu’ils sont en privée et que l’hôte les NAT ?
Dav
Le 1 oct. 2024 à 13:27, Xavier Beaudouin via FRsAG <frsag@frsag.org <mailto:frsag@frsag.org>> a écrit :
Simple : - Détruire le container - Installer un container propre.
De: "Franck Routier (perso) via FRsAG" <frsag@frsag.org <mailto:frsag@frsag.org>> À: "frsag" <frsag@frsag.org <mailto:frsag@frsag.org>> Envoyé: Mardi 1 Octobre 2024 13:16:03 Objet: [FRsAG] Container hacké, que faire Bonjour,
J'ai un serveur "bare metal" chez OVH, avec une Ubuntu, inclus (ex LXD) et une série de containers. Ce matin mes services étaient hors ligne : le serveur était passé en mode "hack" par OVH. J'ai redémarré le serveur et stoppé tous les containers. D'après vous, comment procéder pour isoler et nettoyer le container fautif ?
Merci
_______________________________________________ Liste de diffusion du %(real_name)s http://www.frsag.org/ _______________________________________________ Liste de diffusion du %(real_name)s http://www.frsag.org/
Liste de diffusion du $real_name http://www.frsag.org/
_______________________________________________ Liste de diffusion du $realname https://www.frsag.org/
On Tue, Oct 1, 2024 at 7:31 PM Laurent Barme <2551@barme.fr> wrote:
Le 01/10/2024 à 16:29, Franck Routier via FRsAG a écrit :
Le mardi 1 octobre 2024, 15:27:30 CEST Kevin Labécot a écrit :
Je ne connais pas ce mode « hack » d’OVH ni si il y a des précisions mais qui dit que ce n’est pas le serveur hôte qui est hacké ? l'intuition et l'espoir... En fait j'ai arrêté tous les containers et le problème ne réapparaît pas. Mon suspect principal est un site Spip, ou le reverse proxy nginx qui dispatch les requêtes... Spip est un suspect crédible, comme tout CMS très populaire en PHP :-/
Spip est une très bonne piste si tu n' avais pas une version à jour. Je m' en suis fait pirater un aussi. Vu que spip a très peu de squelettes disponibles, et qu 'ils ne sont jamais compatibles avec les nouvelles versions qui n' ont plus de failles de sécurité, les propriétaires ont tendance à laisser traîner des vieilles versions vulnérables. Vérifie la version de spip que tu avais, si elle est vulnérable . . . C' est sûrement ton coupable.
Mais en effet, ça pourrait (aurait pu ...:-) ) être le serveur principal... Quoiqu'il en soit, la seule solution vraiment fiable pour gérer un serveur compromis c'est de tout réinstaller sur un serveur initialement vierge et en n'y important que des données inertes (absolument non exécutables) de tes sauvegardes (tirées depuis l'extérieur comme décrit par Maxime et inaccessibles depuis le serveur sauvegardé).
Il est même possible que ce ne soit pas forcément plus long que de tester les containers un par un.
Quoiqu'il en soit, bon courage !
Si tu pouvais nous en dire plus sur la compromission tel que les symptômes qui ont fait passer ton serveur en mode "hack", la façon dont il aurait été compromis, ou autres, cela pourrait nous aider…
— Kevin
Le 1 oct. 2024 à 14:39, David Ponzone <david.ponzone@gmail.com> a écrit :
Xav,
Je crois que Franck ne sait pas quel container est fautif…
J’ai envie de dire d’éteindre tous les containers, les allumer un par un, et prendre une trace réseau à chaque fois à la sortie de chaque container pour tenter de détecter du traffic anormal. Je suppose qu’ils sont en privée et que l’hôte les NAT ?
Dav
Le 1 oct. 2024 à 13:27, Xavier Beaudouin via FRsAG <frsag@frsag.org <mailto:frsag@frsag.org>> a écrit :
Simple : - Détruire le container - Installer un container propre.
De: "Franck Routier (perso) via FRsAG" <frsag@frsag.org <mailto:frsag@frsag.org>> À: "frsag" <frsag@frsag.org <mailto:frsag@frsag.org>> Envoyé: Mardi 1 Octobre 2024 13:16:03 Objet: [FRsAG] Container hacké, que faire Bonjour,
J'ai un serveur "bare metal" chez OVH, avec une Ubuntu, inclus (ex LXD) et une série de containers. Ce matin mes services étaient hors ligne : le serveur était passé en mode "hack" par OVH. J'ai redémarré le serveur et stoppé tous les containers. D'après vous, comment procéder pour isoler et nettoyer le container fautif ?
Merci
_______________________________________________ Liste de diffusion du %(real_name)s http://www.frsag.org/ _______________________________________________ Liste de diffusion du %(real_name)s http://www.frsag.org/
Liste de diffusion du $real_name http://www.frsag.org/
_______________________________________________ Liste de diffusion du $realname https://www.frsag.org/
_______________________________________________ Liste de diffusion du French Sysadmin Group https://www.frsag.org/
Le mardi 1 octobre 2024, 20:42:05 CEST neo futur a écrit :
Spip est une très bonne piste si tu n' avais pas une version à jour. Je m' en suis fait pirater un aussi. Vu que spip a très peu de squelettes disponibles, et qu 'ils ne sont jamais compatibles avec les nouvelles versions qui n' ont plus de failles de sécurité, les propriétaires ont tendance à laisser traîner des vieilles versions vulnérables.
oui, c'était bien mon problème sur Spip : squelette pas compatible, donc "vieille" version...
Le mardi 01 oct. 2024 à 19:30:21 (+0200), Laurent Barme a écrit :
Quoiqu'il en soit, la seule solution vraiment fiable pour gérer un serveur compromis c'est de tout réinstaller sur un serveur initialement vierge et en n'y important que des données inertes (absolument non exécutables) de tes sauvegardes (tirées depuis l'extérieur comme décrit par Maxime et inaccessibles depuis le serveur sauvegardé).
Sans oublier de comprendre d'où a pu venir la compromission initiale. Si c'est pour réinstaller un serveur vulnérable, ça n'a pas trop de sens. -- Il est *absolument* essentiel, si l'on veut se regarder dans un miroir sans frémir, quand on prône la liberté par l'utilisation de la technologie de s'opposer aussi à la censure de masse. Il n'y a pas d'autre possibilité. Toute autre option, c'est pactiser avec l'ennemi.
Le 01/10/2024 à 22:04, Christophe Moille a écrit :
Le mardi 01 oct. 2024 à 19:30:21 (+0200), Laurent Barme a écrit :
Quoiqu'il en soit, la seule solution vraiment fiable pour gérer un serveur compromis c'est de tout réinstaller sur un serveur initialement vierge et en n'y important que des données inertes (absolument non exécutables) de tes sauvegardes (tirées depuis l'extérieur comme décrit par Maxime et inaccessibles depuis le serveur sauvegardé). Sans oublier de comprendre d'où a pu venir la compromission initiale. D'où vient la compromission ni comment elle s'est produite n'est pas une information toujours accessible ; un bon pirate efface ses traces. De quelle façon le serveur est compromis est par contre une information très utile ; cela permet de vérifier si d'autres serveurs le sont aussi.
Si c'est pour réinstaller un serveur vulnérable, ça n'a pas trop de sens.
Si l'installation d'un nouveau serveur donne un serveur compromis, on a un gros problème car alors tous les serveurs que l'on a installé avec le même processus sont d'emblée compromis !
Le mardi 1 octobre 2024, 22:04:39 CEST Christophe Moille a écrit :
Sans oublier de comprendre d'où a pu venir la compromission initiale. Si c'est pour réinstaller un serveur vulnérable, ça n'a pas trop de sens.
c'est là que je suis un peu démuni : je ne sais pas trop par quel bout le prendre pour comprendre ce qui s'est passé. Pour la suite, je suis aussi en train de regarder comment renforcer mon container reverse-proxy. Aujourd'hui j'ai un nginx, pas de WAF. J'hésite à changer pour traefik/ModSecurity (mais j'ai l'impression que Traefik prend une orientation commerciale...) , ou pour Caddy/Coraza. Je ne connais nin l'un ni l'autre. Des avis là-dessus ?
tu as aussi la piste du faux positif du mode hack d'ovh. Il y a longtemps, il suffisait de lancer un test de charge (gatling au hasard) depuis un serveur OVH pour qu'il passe en hack Dans la notif que OVH envoie pour signaler le passage en mode hack, ils ne donnent plus de traces réseau de la cause ? On Wed, Oct 2, 2024 at 5:51 AM Franck Routier via FRsAG <frsag@frsag.org> wrote:
Le mardi 1 octobre 2024, 15:27:30 CEST Kevin Labécot a écrit :
Je ne connais pas ce mode « hack » d’OVH ni si il y a des précisions mais qui dit que ce n’est pas le serveur hôte qui est hacké ?
l'intuition et l'espoir... En fait j'ai arrêté tous les containers et le problème ne réapparaît pas. Mon suspect principal est un site Spip, ou le reverse proxy nginx qui dispatch les requêtes...
Mais en effet, ça pourrait (aurait pu ...:-) ) être le serveur principal...
— Kevin
Le 1 oct. 2024 à 14:39, David Ponzone <david.ponzone@gmail.com> a
écrit :
Xav,
Je crois que Franck ne sait pas quel container est fautif…
J’ai envie de dire d’éteindre tous les containers, les allumer un par
un, et prendre une trace réseau à chaque fois à la sortie de chaque container pour tenter de détecter du traffic anormal.
Je suppose qu’ils sont en privée et que l’hôte les NAT ?
Dav
Le 1 oct. 2024 à 13:27, Xavier Beaudouin via FRsAG <frsag@frsag.org <mailto:frsag@frsag.org>> a écrit :
Simple : - Détruire le container - Installer un container propre.
De: "Franck Routier (perso) via FRsAG" <frsag@frsag.org <mailto: frsag@frsag.org>> À: "frsag" <frsag@frsag.org <mailto:frsag@frsag.org>> Envoyé: Mardi 1 Octobre 2024 13:16:03 Objet: [FRsAG] Container hacké, que faire Bonjour,
J'ai un serveur "bare metal" chez OVH, avec une Ubuntu, inclus (ex LXD) et une série de containers. Ce matin mes services étaient hors ligne : le serveur était passé en mode "hack" par OVH. J'ai redémarré le serveur et stoppé tous les containers. D'après vous, comment procéder pour isoler et nettoyer le container fautif ?
Merci
_______________________________________________ Liste de diffusion du %(real_name)s http://www.frsag.org/ _______________________________________________ Liste de diffusion du %(real_name)s http://www.frsag.org/
_______________________________________________ Liste de diffusion du $real_name http://www.frsag.org/
_______________________________________________ Liste de diffusion du $realname https://www.frsag.org/
-- Sébastien Guilbaud
Bonjour, si, la trace du traffic incriminé est donnée : Attack detail : 9Kpps/6Mbps dateTime srcIp:srcPort dstIp:dstPort protocol flags packets bytes reason 2024.10.01 06:42:21 CEST 1xx.1xx.1xx.1xx:34734 141.94.111.221:22 TCP SYN 16384 1277952 ATTACK:TCP_SYN 2024.10.01 06:42:21 CEST 1xx.1xx.1xx.1xx:33292 141.94.111.221:22 TCP SYN 16384 1277952 ATTACK:TCP_SYN 2024.10.01 06:42:21 CEST 1xx.1xx.1xx.1xx:59660 141.94.111.221:22 TCP SYN 16384 1277952 ATTACK:TCP_SYN 2024.10.01 06:42:21 CEST 1xx.1xx.1xx.1xx:42332 141.94.111.221:22 TCP SYN 16384 1277952 ATTACK:TCP_SYN 2024.10.01 06:42:21 CEST 1xx.1xx.1xx.1xx:55438 141.94.111.221:22 TCP SYN 16384 1277952 ATTACK:TCP_SYN 2024.10.01 06:42:21 CEST 1xx.1xx.1xx.1xx:48408 141.94.111.221:22 TCP SYN 16384 1277952 ATTACK:TCP_SYN etc... donc visiblement un de mes containers essaye de forcer le ssh de 141.94.111.221 (dont le whois m'indique qu'il est chez OVH également...) Pas un faux positif donc... Le mercredi 2 octobre 2024, 08:25:21 CEST Sebastien Guilbaud a écrit :
tu as aussi la piste du faux positif du mode hack d'ovh.
Il y a longtemps, il suffisait de lancer un test de charge (gatling au hasard) depuis un serveur OVH pour qu'il passe en hack
Dans la notif que OVH envoie pour signaler le passage en mode hack, ils ne donnent plus de traces réseau de la cause ?
On Wed, Oct 2, 2024 at 5:51 AM Franck Routier via FRsAG <frsag@frsag.org> wrote:
Le mardi 1 octobre 2024, 15:27:30 CEST Kevin Labécot a écrit :
Je ne connais pas ce mode « hack » d’OVH ni si il y a des précisions mais qui dit que ce n’est pas le serveur hôte qui est hacké ?
l'intuition et l'espoir... En fait j'ai arrêté tous les containers et le problème ne réapparaît pas. Mon suspect principal est un site Spip, ou le reverse proxy nginx qui dispatch les requêtes...
Mais en effet, ça pourrait (aurait pu ...:-) ) être le serveur principal...
— Kevin
Le 1 oct. 2024 à 14:39, David Ponzone <david.ponzone@gmail.com> a
écrit :
Xav,
Je crois que Franck ne sait pas quel container est fautif…
J’ai envie de dire d’éteindre tous les containers, les allumer un par
un, et prendre une trace réseau à chaque fois à la sortie de chaque container pour tenter de détecter du traffic anormal.
Je suppose qu’ils sont en privée et que l’hôte les NAT ?
Dav
Le 1 oct. 2024 à 13:27, Xavier Beaudouin via FRsAG <frsag@frsag.org <mailto:frsag@frsag.org>> a écrit :
Simple : - Détruire le container - Installer un container propre.
De: "Franck Routier (perso) via FRsAG" <frsag@frsag.org <mailto: frsag@frsag.org>> À: "frsag" <frsag@frsag.org <mailto:frsag@frsag.org>> Envoyé: Mardi 1 Octobre 2024 13:16:03 Objet: [FRsAG] Container hacké, que faire Bonjour,
J'ai un serveur "bare metal" chez OVH, avec une Ubuntu, inclus (ex LXD) et une série de containers. Ce matin mes services étaient hors ligne : le serveur était passé en mode "hack" par OVH. J'ai redémarré le serveur et stoppé tous les containers. D'après vous, comment procéder pour isoler et nettoyer le container fautif ?
Merci
_______________________________________________ Liste de diffusion du %(real_name)s http://www.frsag.org/ _______________________________________________ Liste de diffusion du %(real_name)s http://www.frsag.org/
_______________________________________________ Liste de diffusion du $real_name http://www.frsag.org/
_______________________________________________ Liste de diffusion du $realname https://www.frsag.org/
-- Sébastien Guilbaud
Hello Tu as un script pour valider que SPIP est troué ou pas. Au passable fort probable s'il n'y a pas eu de mise à jour depuis les 12 derniers mois. Je t'invite à regarder du coté : https://git.spip.net/spip-contrib-outils/spip_cleaner Je te confirme que je suis partie prenante car j'ai codé ce script pour ces cas de figure. Ne pas hésiter à me faire tes retours. Km Le mercredi 02 octobre 2024 à 10:07 +0200, Franck Routier via FRsAG a écrit :
Bonjour,
si, la trace du traffic incriminé est donnée :
Attack detail : 9Kpps/6Mbps dateTime srcIp:srcPort dstIp:dstPort protocol flags packets bytes reason 2024.10.01 06:42:21 CEST 1xx.1xx.1xx.1xx:34734 141.94.111.221:22 TCP SYN 16384 1277952 ATTACK:TCP_SYN 2024.10.01 06:42:21 CEST 1xx.1xx.1xx.1xx:33292 141.94.111.221:22 TCP SYN 16384 1277952 ATTACK:TCP_SYN 2024.10.01 06:42:21 CEST 1xx.1xx.1xx.1xx:59660 141.94.111.221:22 TCP SYN 16384 1277952 ATTACK:TCP_SYN 2024.10.01 06:42:21 CEST 1xx.1xx.1xx.1xx:42332 141.94.111.221:22 TCP SYN 16384 1277952 ATTACK:TCP_SYN 2024.10.01 06:42:21 CEST 1xx.1xx.1xx.1xx:55438 141.94.111.221:22 TCP SYN 16384 1277952 ATTACK:TCP_SYN 2024.10.01 06:42:21 CEST 1xx.1xx.1xx.1xx:48408 141.94.111.221:22 TCP SYN 16384 1277952 ATTACK:TCP_SYN
etc...
donc visiblement un de mes containers essaye de forcer le ssh de 141.94.111.221 (dont le whois m'indique qu'il est chez OVH également...)
Pas un faux positif donc...
Le mercredi 2 octobre 2024, 08:25:21 CEST Sebastien Guilbaud a écrit :
tu as aussi la piste du faux positif du mode hack d'ovh.
Il y a longtemps, il suffisait de lancer un test de charge (gatling au hasard) depuis un serveur OVH pour qu'il passe en hack
Dans la notif que OVH envoie pour signaler le passage en mode hack, ils ne donnent plus de traces réseau de la cause ?
On Wed, Oct 2, 2024 at 5:51 AM Franck Routier via FRsAG <frsag@frsag.org> wrote:
Le mardi 1 octobre 2024, 15:27:30 CEST Kevin Labécot a écrit :
Je ne connais pas ce mode « hack » d’OVH ni si il y a des précisions mais qui dit que ce n’est pas le serveur hôte qui est hacké ?
l'intuition et l'espoir... En fait j'ai arrêté tous les containers et le problème ne réapparaît pas. Mon suspect principal est un site Spip, ou le reverse proxy nginx qui dispatch les requêtes...
Mais en effet, ça pourrait (aurait pu ...:-) ) être le serveur principal...
— Kevin
Le 1 oct. 2024 à 14:39, David Ponzone <david.ponzone@gmail.com> a
écrit :
Xav,
Je crois que Franck ne sait pas quel container est fautif…
J’ai envie de dire d’éteindre tous les containers, les allumer un par
un, et prendre une trace réseau à chaque fois à la sortie de chaque container pour tenter de détecter du traffic anormal.
Je suppose qu’ils sont en privée et que l’hôte les NAT ?
Dav
Le 1 oct. 2024 à 13:27, Xavier Beaudouin via FRsAG <frsag@frsag.org <mailto:frsag@frsag.org>> a écrit :
Simple : - Détruire le container - Installer un container propre.
De: "Franck Routier (perso) via FRsAG" <frsag@frsag.org <mailto: frsag@frsag.org>> À: "frsag" <frsag@frsag.org <mailto:frsag@frsag.org>> Envoyé: Mardi 1 Octobre 2024 13:16:03 Objet: [FRsAG] Container hacké, que faire Bonjour,
J'ai un serveur "bare metal" chez OVH, avec une Ubuntu, inclus (ex LXD) et une série de containers. Ce matin mes services étaient hors ligne : le serveur était passé en mode "hack" par OVH. J'ai redémarré le serveur et stoppé tous les containers. D'après vous, comment procéder pour isoler et nettoyer le container fautif ?
Merci
_______________________________________________ Liste de diffusion du %(real_name)s http://www.frsag.org/ _______________________________________________ Liste de diffusion du %(real_name)s http://www.frsag.org/
_______________________________________________ Liste de diffusion du $real_name http://www.frsag.org/
_______________________________________________ Liste de diffusion du $realname https://www.frsag.org/
-- Sébastien Guilbaud
_______________________________________________ Liste de diffusion du French Sysadmin Group https://www.frsag.org/
Je viens de passer le script, et on dirait bien qu'il trouve des trucs ! (merci pour ce travail !!!) ... DRYRUN: find /var/www/spip -regex /var/www/spip/pwn$ -delete -print Some files have ELF 32 pattern type file /var/www/spip/x86.1 Search WP in /var/www/ Search crontab execution www-data has a crontab to check SPIP to check manualy /var/www/spip Le mercredi 2 octobre 2024, 11:18:46 CEST Camille a écrit :
Hello
Tu as un script pour valider que SPIP est troué ou pas. Au passable fort probable s'il n'y a pas eu de mise à jour depuis les 12 derniers mois.
Je t'invite à regarder du coté : https://git.spip.net/spip-contrib-outils/spip_cleaner
Je te confirme que je suis partie prenante car j'ai codé ce script pour ces cas de figure. Ne pas hésiter à me faire tes retours.
Km
Le mercredi 02 octobre 2024 à 10:07 +0200, Franck Routier via FRsAG a écrit :
Bonjour,
si, la trace du traffic incriminé est donnée :
Attack detail : 9Kpps/6Mbps dateTime srcIp:srcPort dstIp:dstPort protocol flags packets bytes reason 2024.10.01 06:42:21 CEST 1xx.1xx.1xx.1xx:34734 141.94.111.221:22 TCP SYN 16384 1277952 ATTACK:TCP_SYN 2024.10.01 06:42:21 CEST 1xx.1xx.1xx.1xx:33292 141.94.111.221:22 TCP SYN 16384 1277952 ATTACK:TCP_SYN 2024.10.01 06:42:21 CEST 1xx.1xx.1xx.1xx:59660 141.94.111.221:22 TCP SYN 16384 1277952 ATTACK:TCP_SYN 2024.10.01 06:42:21 CEST 1xx.1xx.1xx.1xx:42332 141.94.111.221:22 TCP SYN 16384 1277952 ATTACK:TCP_SYN 2024.10.01 06:42:21 CEST 1xx.1xx.1xx.1xx:55438 141.94.111.221:22 TCP SYN 16384 1277952 ATTACK:TCP_SYN 2024.10.01 06:42:21 CEST 1xx.1xx.1xx.1xx:48408 141.94.111.221:22 TCP SYN 16384 1277952 ATTACK:TCP_SYN
etc...
donc visiblement un de mes containers essaye de forcer le ssh de 141.94.111.221 (dont le whois m'indique qu'il est chez OVH également...)
Pas un faux positif donc...
Le mercredi 2 octobre 2024, 08:25:21 CEST Sebastien Guilbaud a écrit :
tu as aussi la piste du faux positif du mode hack d'ovh.
Il y a longtemps, il suffisait de lancer un test de charge (gatling au hasard) depuis un serveur OVH pour qu'il passe en hack
Dans la notif que OVH envoie pour signaler le passage en mode hack, ils ne donnent plus de traces réseau de la cause ?
On Wed, Oct 2, 2024 at 5:51 AM Franck Routier via FRsAG <frsag@frsag.org> wrote:
Le mardi 1 octobre 2024, 15:27:30 CEST Kevin Labécot a écrit :
Je ne connais pas ce mode « hack » d’OVH ni si il y a des précisions mais qui dit que ce n’est pas le serveur hôte qui est hacké ?
l'intuition et l'espoir... En fait j'ai arrêté tous les containers et le problème ne réapparaît pas. Mon suspect principal est un site Spip, ou le reverse proxy nginx qui dispatch les requêtes...
Mais en effet, ça pourrait (aurait pu ...:-) ) être le serveur principal...
— Kevin
Le 1 oct. 2024 à 14:39, David Ponzone <david.ponzone@gmail.com> a
écrit :
Xav,
Je crois que Franck ne sait pas quel container est fautif…
J’ai envie de dire d’éteindre tous les containers, les allumer un par
un, et prendre une trace réseau à chaque fois à la sortie de chaque container pour tenter de détecter du traffic anormal.
Je suppose qu’ils sont en privée et que l’hôte les NAT ?
Dav
> Le 1 oct. 2024 à 13:27, Xavier Beaudouin via FRsAG > <frsag@frsag.org <mailto:frsag@frsag.org>> a écrit : > > Simple : > - Détruire le container > - Installer un container propre. > > De: "Franck Routier (perso) via FRsAG" > <frsag@frsag.org <mailto: frsag@frsag.org>> > À: "frsag" <frsag@frsag.org <mailto:frsag@frsag.org>> > Envoyé: Mardi 1 Octobre 2024 13:16:03 > Objet: [FRsAG] Container hacké, que faire > Bonjour, > > J'ai un serveur "bare metal" chez OVH, avec une Ubuntu, > inclus (ex LXD) et une série de containers. > Ce matin mes services étaient hors ligne : le serveur était > passé en mode "hack" par OVH. > J'ai redémarré le serveur et stoppé tous les containers. > D'après vous, comment procéder pour isoler et nettoyer le > container fautif ? > > Merci > > _______________________________________________ > Liste de diffusion du %(real_name)s > http://www.frsag.org/ > _______________________________________________ > Liste de diffusion du %(real_name)s > http://www.frsag.org/
_______________________________________________ Liste de diffusion du $real_name http://www.frsag.org/
_______________________________________________ Liste de diffusion du $realname https://www.frsag.org/
-- Sébastien Guilbaud
_______________________________________________ Liste de diffusion du French Sysadmin Group https://www.frsag.org/
Hello Content que ça serve à d'autres personnes que moi :) Note c'est sensé aussi trouver les WP mais c'est pas tout sec à ce propos. La commande -l est pratique pour bien lister les fichiers à contrôler, plus concis que le mode verbeux de -v Ne pas hésiter à me faire des retours au besoin que ce soit sur la (non) documentation , pattern ou autre. Camille Le mercredi 02 octobre 2024 à 13:01 +0200, Franck Routier a écrit :
Je viens de passer le script, et on dirait bien qu'il trouve des trucs ! (merci pour ce travail !!!)
... DRYRUN: find /var/www/spip -regex /var/www/spip/pwn$ -delete -print Some files have ELF 32 pattern type file /var/www/spip/x86.1 Search WP in /var/www/ Search crontab execution www-data has a crontab to check SPIP to check manualy /var/www/spip
Le mercredi 2 octobre 2024, 11:18:46 CEST Camille a écrit :
Hello
Tu as un script pour valider que SPIP est troué ou pas. Au passable fort probable s'il n'y a pas eu de mise à jour depuis les 12 derniers mois.
Je t'invite à regarder du coté : https://git.spip.net/spip-contrib-outils/spip_cleaner
Je te confirme que je suis partie prenante car j'ai codé ce script pour ces cas de figure. Ne pas hésiter à me faire tes retours.
Km
Le mercredi 02 octobre 2024 à 10:07 +0200, Franck Routier via FRsAG a écrit :
Bonjour,
si, la trace du traffic incriminé est donnée :
Attack detail : 9Kpps/6Mbps dateTime srcIp:srcPort dstIp:dstPort protocol flags packets bytes reason 2024.10.01 06:42:21 CEST 1xx.1xx.1xx.1xx:34734 141.94.111.221:22 TCP SYN 16384 1277952 ATTACK:TCP_SYN 2024.10.01 06:42:21 CEST 1xx.1xx.1xx.1xx:33292 141.94.111.221:22 TCP SYN 16384 1277952 ATTACK:TCP_SYN 2024.10.01 06:42:21 CEST 1xx.1xx.1xx.1xx:59660 141.94.111.221:22 TCP SYN 16384 1277952 ATTACK:TCP_SYN 2024.10.01 06:42:21 CEST 1xx.1xx.1xx.1xx:42332 141.94.111.221:22 TCP SYN 16384 1277952 ATTACK:TCP_SYN 2024.10.01 06:42:21 CEST 1xx.1xx.1xx.1xx:55438 141.94.111.221:22 TCP SYN 16384 1277952 ATTACK:TCP_SYN 2024.10.01 06:42:21 CEST 1xx.1xx.1xx.1xx:48408 141.94.111.221:22 TCP SYN 16384 1277952 ATTACK:TCP_SYN
etc...
donc visiblement un de mes containers essaye de forcer le ssh de 141.94.111.221 (dont le whois m'indique qu'il est chez OVH également...)
Pas un faux positif donc...
Le mercredi 2 octobre 2024, 08:25:21 CEST Sebastien Guilbaud a écrit :
tu as aussi la piste du faux positif du mode hack d'ovh.
Il y a longtemps, il suffisait de lancer un test de charge (gatling au hasard) depuis un serveur OVH pour qu'il passe en hack
Dans la notif que OVH envoie pour signaler le passage en mode hack, ils ne donnent plus de traces réseau de la cause ?
On Wed, Oct 2, 2024 at 5:51 AM Franck Routier via FRsAG <frsag@frsag.org> wrote:
Le mardi 1 octobre 2024, 15:27:30 CEST Kevin Labécot a écrit :
Je ne connais pas ce mode « hack » d’OVH ni si il y a des précisions mais qui dit que ce n’est pas le serveur hôte qui est hacké ?
l'intuition et l'espoir... En fait j'ai arrêté tous les containers et le problème ne réapparaît pas. Mon suspect principal est un site Spip, ou le reverse proxy nginx qui dispatch les requêtes...
Mais en effet, ça pourrait (aurait pu ...:-) ) être le serveur principal...
— Kevin
> Le 1 oct. 2024 à 14:39, David Ponzone > <david.ponzone@gmail.com> a
écrit :
> > Xav, > > Je crois que Franck ne sait pas quel container est > fautif… > > J’ai envie de dire d’éteindre tous les containers, les > allumer un par un, et prendre une trace réseau à chaque fois à la sortie de chaque container pour tenter de détecter du traffic anormal. > Je suppose qu’ils sont en privée et que l’hôte les NAT ? > > Dav > > > Le 1 oct. 2024 à 13:27, Xavier Beaudouin via FRsAG > > <frsag@frsag.org <mailto:frsag@frsag.org>> a écrit : > > > > Simple : > > - Détruire le container > > - Installer un container propre. > > > > De: "Franck Routier (perso) via FRsAG" > > <frsag@frsag.org <mailto: frsag@frsag.org>> > > À: "frsag" <frsag@frsag.org <mailto:frsag@frsag.org>> > > Envoyé: Mardi 1 Octobre 2024 13:16:03 > > Objet: [FRsAG] Container hacké, que faire > > Bonjour, > > > > J'ai un serveur "bare metal" chez OVH, avec une Ubuntu, > > inclus (ex LXD) et une série de containers. > > Ce matin mes services étaient hors ligne : le serveur > > était > > passé en mode "hack" par OVH. > > J'ai redémarré le serveur et stoppé tous les > > containers. > > D'après vous, comment procéder pour isoler et nettoyer > > le > > container fautif ? > > > > Merci > > > > _______________________________________________ > > Liste de diffusion du %(real_name)s > > http://www.frsag.org/ > > _______________________________________________ > > Liste de diffusion du %(real_name)s > > http://www.frsag.org/ > > _______________________________________________ > Liste de diffusion du $real_name > http://www.frsag.org/
_______________________________________________ Liste de diffusion du $realname https://www.frsag.org/
-- Sébastien Guilbaud
_______________________________________________ Liste de diffusion du French Sysadmin Group https://www.frsag.org/
Salut, Pour analyser l'intégrité d'un Wordpress, on peut aussi utiliser wp-cli : curl https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar -o wp-cli.phar php8.2 wp-cli.phar --path=/var/www/html/example.com core verify-checksums --version=(version du Wordpress que l'on récupère dans wp-includes/version.php) Amicalement, Élodie Le 02/10/2024 à 14:27, Camille a écrit :
Note c'est sensé aussi trouver les WP mais c'est pas tout sec à ce propos.
Bonjour, Il y a probablement un webshell/phpshell installé par l'attaquant dans ton arbo spip. il faut le trouver et c'est pas toujours simple. Je ne suis plus à la page sur les scripts de détection mais il y en a comme https://github.com/idrisawad/Webshell-Detect Si tu as des volumes Docker sur ton container Spip ("docker volumes ls"), l'upgrade d'image n'y changera rien, le webshell va rester là. HTH Le 02/10/2024 à 10:07, Franck Routier via FRsAG a écrit :
Bonjour,
si, la trace du traffic incriminé est donnée :
Attack detail : 9Kpps/6Mbps dateTime srcIp:srcPort dstIp:dstPort protocol flags packets bytes reason 2024.10.01 06:42:21 CEST 1xx.1xx.1xx.1xx:34734 141.94.111.221:22 TCP SYN 16384 1277952 ATTACK:TCP_SYN 2024.10.01 06:42:21 CEST 1xx.1xx.1xx.1xx:33292 141.94.111.221:22 TCP SYN 16384 1277952 ATTACK:TCP_SYN 2024.10.01 06:42:21 CEST 1xx.1xx.1xx.1xx:59660 141.94.111.221:22 TCP SYN 16384 1277952 ATTACK:TCP_SYN 2024.10.01 06:42:21 CEST 1xx.1xx.1xx.1xx:42332 141.94.111.221:22 TCP SYN 16384 1277952 ATTACK:TCP_SYN 2024.10.01 06:42:21 CEST 1xx.1xx.1xx.1xx:55438 141.94.111.221:22 TCP SYN 16384 1277952 ATTACK:TCP_SYN 2024.10.01 06:42:21 CEST 1xx.1xx.1xx.1xx:48408 141.94.111.221:22 TCP SYN 16384 1277952 ATTACK:TCP_SYN
etc...
donc visiblement un de mes containers essaye de forcer le ssh de 141.94.111.221 (dont le whois m'indique qu'il est chez OVH également...)
Pas un faux positif donc...
Le 01/10/2024 à 16:29, Franck Routier via FRsAG a écrit :
Le mardi 1 octobre 2024, 15:27:30 CEST Kevin Labécot a écrit :
Je ne connais pas ce mode « hack » d’OVH ni si il y a des précisions mais qui dit que ce n’est pas le serveur hôte qui est hacké ?
l'intuition et l'espoir... En fait j'ai arrêté tous les containers et le problème ne réapparaît pas. Mon suspect principal est un site Spip, ou le reverse proxy nginx qui dispatch les requêtes...
Mais en effet, ça pourrait (aurait pu ...:-) ) être le serveur principal... [...]
Il y a eu plusieurs failles sur Spip récemment : https://blog.spip.net/
participants (16)
-
ANSART David -
Camille -
Christophe Moille -
David Ponzone -
Fabien Schwebel -
Franck Routier -
Franck Routier (perso)
-
Grégoire G -
jean-marc Pouchoulon Université -
Kevin Labécot -
Laurent Barme -
Maxime DERCHE -
neo futur -
Sebastien Guilbaud -
Xavier Beaudouin -
Élodie BOSSIER