Douleur supprimant un rootkit Perl

Nous hébergeons donc un serveur Web géoservice au bureau.

Quelqu'un a apparemment fait irruption dans cette boîte (probablement via ftp ou ssh), et a mis une sorte de rootkit géré par irc.

Maintenant j'essaye de nettoyer le tout, j'ai trouvé le processus pid qui essaie de se connecter via irc, mais je ne peux pas comprendre qui est le processus d'appel (déjà regardé avec ps, pstree, lsof) Le processus est un perl script appartenant à l'utilisateur www, mais ps aux | grep affiche un faux chemin de fichier dans la dernière colonne.

Y a-t-il un autre moyen de retracer ce pid et d'attraper l'invocateur?

J'ai oublié de mentionner: le noyau est 2.6.23, qui est exploitable pour devenir root, mais je ne peux pas trop toucher à cette machine, donc je ne peux pas mettre à jour le noyau

EDIT: lsof pourrait aider:

lsof -p 9481
UTILISATEUR PID UTILISATEUR TYPE FD DISPOSITIF TAILLE NOM DE NŒUDss
perl 9481 www cwd DIR 8,2 608 2 / ss
perl 9481 www rtd DIR 8,2 608 2 / ss
perl 9481 www txt REG 8,2 1168928 38385 / usr / bin / perl5.8.8ss
perl 9481 www mem REG 8,2 135348 23286 /lib64/ld-2.5.soss
perl 9481 www mem REG 8,2 103711 23295 /lib64/libnsl-2.5.soss
perl 9481 www mem REG 8,2 19112 23292 /lib64/libdl-2.5.soss
perl 9481 www mem REG 8,2 586243 23293 /lib64/libm-2.5.soss
perl 9481 www mem REG 8,2 27041 23291 /lib64/libcrypt-2.5.soss
perl 9481 www mem REG 8,2 14262 23307 /lib64/libutil-2.5.soss
perl 9481 www mem REG 8,2 128642 23303 /lib64/libpthread-2.5.soss
perl 9481 www mem REG 8,2 1602809 23289 / lib64 / libc -2.5.soss
perl 9481 www mem REG 8,2 19256 38662 /usr/lib64/perl5/5.8.8/x86_64-linux-threa d-multi / auto / IO / IO.soss
perl 9481 www mem REG 8,2 21328 38877 /usr/lib64/perl5/5.8.8/x86_64-linux-threa d-multi / auto / Socket / Socket.soss
perl 9481 www mem REG 8,2 52512 23298 /lib64/libnss_files-2.5.soss
perl 9481 www 0r FIFO 0,5 1068892 pipess
perl 9481 www 1w FIFO 0,5 1071920 pipess
perl 9481 www 2w FIFO 0,5 1068894 pipess
perl 9481 www 3u IPv4 130646198 TCP 192.168.90.7:60321->www.****.net:ircd (SYN_SENT)

Si je peux vous donner des conseils, c'est pour arrêter de perdre votre temps à nettoyer. Faites une image du système d'exploitation pour des informations médico-légales pour plus tard, et réinstallez simplement le serveur.

Désolé, mais c'est le seul moyen sûr de vous empêcher d'être rootkitted.

Plus tard, vous pouvez vérifier l'image, pour certaines raisons, pourquoi cela s'est produit.

D'après ma propre expérience personnelle, je l'ai fait et j'ai trouvé plus tard un utilisateur interne qui avait une clé SSH contenant la faille d'OpenSL en 2008.

J'espère que ça clarifie les choses.

Remarque:
Si vous allez créer une image / sauvegarder le serveur avant de réinstaller, soyez très prudent, comment procéder. Comme l'a dit @dfranke, démarrez à partir d'un support de confiance pour sauvegarder.

Vous ne devez pas vous connecter à d'autres machines à partir d'un serveur enraciné, car les grands rootkits sont connus pour pouvoir se propager via des sessions de confiance telles que SSH.

La ligne de commande peut être modifiée si le processus modifie argv [0]. Essayerls -l /proc/[pid]/exe

De man 5 proc

ce fichier est un lien symbolique contenant le chemin d'accès réel de la commande exécutée. Ce lien symbolique peut être déréférencé normalement; tenter de l'ouvrir ouvrira l'exécutable. Vous pouvez même taper / proc / [numéro] / exe pour exécuter une autre copie du même exécutable que celui exécuté par le processus [numéro]. Dans un processus multithread, le contenu de ce lien symbolique n'est pas disponible si le thread principal est déjà terminé

ps auxwf | less vous donne la "vue de la forêt" des processus qui peut vous montrer quel processus a lancé ce processus (à moins que le rootkit ne le cache, ou que le parent de l'application soit sorti et qu'il ait été reparenté à init).

Ce serait principalement académique et probablement juste une perte de temps, mais cela strings -n 10 /proc/[pid]/mempourrait être amusant de regarder défiler. Vous pouvez également echo 0x7 > /proc/[pid]/coredump_filterutiliser gdb gcorepour forcer un coredump avec tout ce qui est possible, mais le processus meurt, ce qui pourrait bloquer une analyse plus approfondie.

Mais suivez certainement les conseils d'Arenstar. Sauvegardez uniquement les données, restaurez tout l'exécutable à partir des sauvegardes et recommencez. Vous devriez probablement également restaurer le site Web à partir de sauvegardes, il pourrait y avoir du javascript malveillant ajouté à chaque fichier html ou php. Si vous envisagez une action en justice, vous voudrez simplement mettre la machine de côté, la débrancher du réseau et arrêter tout ce que vous faites jusqu'à ce que les experts judiciaires aient fait leur travail.

Essayez "cat / proc / [process id] / cmdline" Bien que s'il s'agit d'un vrai rootkit, il peut modifier le noyau pour mieux se cacher.

Vous devez réinstaller, je suis d'accord. Avez-vous essayé d'échapper aux personnages du chemin? Peut-être qu'une de ces barres obliques fait en fait partie d'un nom de fichier et non d'un répertoire. À tout le moins, vous devez utiliser iptables pour bloquer le trafic sortant vers cet hôte ou général IRC jusqu'à ce qu'il soit corrigé. Vérifiez également netstat.

Je pense que maintenant vous avez réinstallé. Votre perte de temps à essayer de suivre les processus et de faire de la criminalistique, car les chances que quelque chose se développe légalement à partir de cela seraient très minuscules et les chances de trouver le pirate seraient de toute façon futiles. À moins que cela ne vous intéresse simplement de rechercher et d'inverser les rootkits, ce qui peut être amusant :)