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.ponz...@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/
> > 
> > 
> 
> 
> 

_______________________________________________
Liste de diffusion du French Sysadmin Group
https://www.frsag.org/

Répondre à