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/