bonjour
plusieurs pistes :
- un truc qui se lance au démarrage de la machine et reste bien
planqué qui lance la saleté de temps en temps) ?
Je pense par exemple, s'il a exploité une faille de Apache à la
base, a pu modifié la config pour se lancer? Ou au boot de la
machine (systemctl) si les privilèges acquis permettaient d'avoir
les droits "root"
-SPIP est basé sur PHP ; je ne pense pas que le système SPIP
lui-même serait touché (pas assez populaire) , mais les lancement
de PHP?
-Même remarque avec Perl, puisqu'il tourne avec.
- Tu as fait un script /bin/sh, c'est très bien... à condition
qu'il passe bien par sh et pas directement par un autre shell.
dans ce cas, renommer tous les shelles présents en .sav, les
remplacer par des liens vers ton /bin/sh, et enfin lancer le
script légitime avec le shell d'origine.sav.
bon courage, on l'aura
Sébastien Dinot a écrit :BERTRAND Joël a écrit :Porte d'entrée trouvée :Merci pour ce retour, toujours intéressant à avoir.Porte d'entrée trouvée, mais il reste des scories. Je suis en train de logguer ce que fait sh pour savoir quel est le processus qui me réinstalle le vers régulièrement. Le truc est bien planqué et est revenu à la charge plusieurs fois ce matin. Bon, il ne peut rien faire puisque les ports sur lesquels il veut se connecter sont fermés sur le firewall, mais c'est pénible. Ce n'est visiblement pas lancé par un cron (pas de régularité). J'utilise un /bin/sh qui fait cela : #!/bin/bash if [ $1 == "/usr/bin/rlog" ]; then exit 0; fi if [ $1 == "/usr/bin/rcsdiff" ]; then exit 0; fi logger -i "shell $*" for i in $(pstree -p); do logger -i $i; done exec $* Est-ce que vous voyez plus efficace ? Le vers en question lance d'abord un script sh qui daemonise un exécutable perl. Je cherche à savoir qui lance cette saleté (sans doute www-data) mais surtout quel est l'exécutable. Je subodore qu'il est au chaud quelque part dans le fond d'une arborescence de www-data, mais rien ne me saute aux yeux. JB