Douleur supprimant un rootkit Perl

8

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)

linux security perl process rootkit paul.ago
la source
2
À moins que vous ne mettiez à jour le noyau, qu'est-ce qui empêche le pirate de répéter le hack dès que vous supprimez le rootkit? Il peut bien y avoir un module de noyau de cheval de Troie qui cache les processus.
pjc50
cela ressemble beaucoup au robot irc ddos ​​que je viens de nettoyer mes vps: serverfault.com/questions/639699/…
Hayden Thring

Réponses:

37

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.

Arenstar
la source
11
J'appuie fortement ce conseil. Vous avez trouvé un rootkit, mais vous n'avez absolument aucune idée de ce que l'attaquant a falsifié. Une fois enraciné, toujours enraciné. Démarrez à partir d'un support de confiance, mettez le lecteur à zéro. Fdisk, formater, réinstaller, doo dah, doo dah.
dfranke
Yah ... De bons kits racine fonctionnent sous votre noyau .. Aucune chance de les supprimer, sans beaucoup d'efforts
Arenstar
4
+1 Pour tout système de production (vraiment, tout système), il n'y a aucune raison de nettoyer. Tuez-le avec le feu et reconstruisez.
phoebus
1
+1 pour réinstaller. Le rootkit a probablement foiré vos binaires ou votre noyau et tout ce que vous voyez (faux chemins, etc ...) est probablement de la courtoisie du rootkit pour se cacher.
coredump
1
Obligatoire. citation : "Je dis que nous décollons et neutralisons le site entier de l'orbite. C'est le seul moyen d'être sûr."
Charles Stewart
1

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.

DerfK
la source
Vraiment une excellente réponse.
paul.ago
malheureusement ls -l / proc / [pid] / exe retourne le chemin bin perl5.8.8, et ps / pstree dit que le père du processus est init, cette chose semble vraiment bien cachée. Je recommencerais certainement avec une nouvelle installation, mais le développeur d'origine de l'application qui s'exécute est hors du pays pendant un certain temps, donc je cherchais une solution temporaire. En passant, vraiment une excellente réponse
paul.ago
0

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.

mfarver
la source
ça me donne la même chose que ps aux "/ usr / sbin / apache / logs" ce qui est faux. Ni le répertoire / usr / sbin / apache n'existe
paul.ago
0

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.

pécher
la source
non, le chemin semble "réel". Malheureusement, iptables semble installé mais le module du noyau est manquant, je dois donc recompiler le noyau. J'irais probablement de cette façon pour résoudre le problème pendant quelques jours jusqu'à ce que je contacte le gars qui a le code source de l'application, afin que je puisse réinstaller le serveur
paul.ago
0

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 :)

nul
la source