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/
