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/