Schmerzen beim Entfernen eines Perl-Rootkits

Also hosten wir eine Geoservice-Webserver-Sache im Büro.

Jemand ist anscheinend in diese Box eingebrochen (wahrscheinlich über FTP oder SSH) und hat eine Art IRK-verwaltetes Rootkit-Ding eingebaut.

Jetzt versuche ich, das Ganze aufzuräumen. Ich habe die Prozess-PID gefunden, die versucht, eine Verbindung über IRC herzustellen, aber ich kann nicht herausfinden, wer der aufrufende Prozess ist (bereits mit ps, pstree, lsof gesucht). Der Prozess ist ein Perl Skript im Besitz des WWW-Benutzers, aber ps aux | grep zeigt einen gefälschten Dateipfad in der letzten Spalte an.

Gibt es eine andere Möglichkeit, diese PID aufzuspüren und den Anrufer zu fangen?

Ich habe vergessen zu erwähnen: Der Kernel ist 2.6.23, was als Root ausgenutzt werden kann, aber ich kann diesen Computer nicht zu sehr berühren, sodass ich den Kernel nicht aktualisieren kann

EDIT: lsof könnte helfen:

lsof -p 9481
BEFEHL PID USER FD TYP GERÄT GRÖSSE NODENNAMEN
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)

Wenn ich Ihnen einen Rat geben kann, sollten Sie aufhören, Ihre Zeit mit dem Aufräumen zu verschwenden. Erstellen Sie ein Image des Betriebssystems für forensische Zwecke für später und installieren Sie den Server neu.

Tut mir leid, aber es ist der einzig sichere Weg, um sich vom Rootkitting zu lösen.

Später können Sie das Bild aus bestimmten Gründen überprüfen, warum es passiert ist.

Aus eigener Erfahrung habe ich dies getan und später einen internen Benutzer gefunden, der 2008 einen SSH-Schlüssel mit dem Fehler von openssl hatte.

Ich hoffe, es klärt die Dinge auf.

Hinweis:
Wenn Sie vor der Neuinstallation ein Image / Backup des Servers erstellen möchten, gehen Sie sehr vorsichtig vor. Booten Sie, wie @dfranke sagte, von einem vertrauenswürdigen Medium zum Backup.

Sie sollten von einem gerooteten Server aus keine Verbindung zu anderen Computern herstellen, da große Rootkits bekanntermaßen über vertrauenswürdige Sitzungen wie SSH verbreitet werden können.

Die Befehlszeile kann geändert werden, wenn der Prozess argv [0] ändert. Versuchenls -l /proc/[pid]/exe

Von man 5 proc

Diese Datei ist eine symbolische Verknüpfung, die den tatsächlichen Pfadnamen des ausgeführten Befehls enthält. Diese symbolische Verknüpfung kann normal dereferenziert werden. Beim Versuch, es zu öffnen, wird die ausführbare Datei geöffnet. Sie können sogar / proc / [number] / exe eingeben, um eine weitere Kopie derselben ausführbaren Datei auszuführen, die von process [number] ausgeführt wird. In einem Multithread-Prozess ist der Inhalt dieses symbolischen Links nicht verfügbar, wenn der Hauptthread bereits beendet wurde

ps auxwf | less gibt Ihnen die "Gesamtstrukturansicht" von Prozessen, die Ihnen zeigen kann, welcher Prozess diesen Prozess gestartet hat (es sei denn, das Rootkit versteckt ihn oder das übergeordnete Element der App wurde beendet und es wurde für init repariert).

Dies wäre größtenteils akademisch und wahrscheinlich nur eine Zeitverschwendung, strings -n 10 /proc/[pid]/memkönnte aber Spaß machen, wenn man vorbeirollt . Sie könnten auch echo 0x7 > /proc/[pid]/coredump_filterund gdb verwenden gcore, um einen Coredump mit allem Möglichen zu erzwingen, aber dann stirbt der Prozess ab, was die weitere Analyse blockieren könnte.

Aber nimm auf jeden Fall den Rat von Arenstar an. Sichern Sie nur Daten, stellen Sie alle ausführbaren Dateien aus Sicherungen wieder her und beginnen Sie von vorne. Sie sollten die Website wahrscheinlich auch aus Backups wiederherstellen. Möglicherweise wird jeder HTML- oder PHP-Datei schädliches Javascript hinzugefügt. Wenn Sie rechtliche Schritte in Betracht ziehen, sollten Sie das Gerät einfach beiseite legen, den Netzstecker aus der Steckdose ziehen und aufhören, was auch immer Sie tun, bis Forensiker ihre Arbeit erledigt haben.

Versuchen Sie "cat / proc / [process id] / cmdline". Wenn es sich jedoch um ein echtes Rootkit handelt, kann es den Kernel modifizieren, um sich besser zu verstecken.

Sie sollten neu installieren, ich stimme zu. Haben Sie versucht, den Zeichen im Pfad zu entkommen? Vielleicht ist einer dieser Schrägstriche tatsächlich Teil eines Dateinamens und kein Verzeichnis. Zumindest sollten Sie iptables verwenden, um ausgehenden Datenverkehr zu diesem Host oder IRC-General zu blockieren, bis er behoben ist. Überprüfen Sie auch netstat.

Ich würde denken, dass Sie jetzt neu installiert haben. Ihre gerechtfertigte Zeitverschwendung beim Versuch, die Prozesse zu verfolgen und Forensik zu betreiben, da die Wahrscheinlichkeit, dass sich daraus etwas legal entwickelt, sehr gering ist und die Wahrscheinlichkeit, den Hacker zu finden, ohnehin zwecklos wäre. Es sei denn, es interessiert dich nur, Rootkits zu recherchieren und umzukehren, was Spaß machen kann :)