Wenn es sich tatsächlich um OpenSSH-SSHDs handelt, würde ich vermuten, dass ein Skript sie irgendwo in einer unterbrochenen Schleife ausführt und einer ihrer untergeordneten Prozesse die gesamte CPU auslastet.
Wie Marki555 vorgeschlagen hat, stracewürde Ihnen helfen, aber Sie sollten verwenden, strace -fdamit Strace den untergeordneten Prozessen folgt. Von man strace:
-f Trace child processes as they are created by cur-
rently traced processes as a result of the fork(2)
system call.
Da strace so viele Daten generiert, ist es möglicherweise auch eine gute Idee, das Argument -e zu verwenden (um beispielsweise nur open () -Aufrufe anzuzeigen):
-e expr A qualifying expression which modifies which events
to trace or how to trace them. The format of the
expression is:
[qualifier=][!]value1[,value2]...
Ein weiterer Befehl, den Sie versuchen können, ist ps xafoder pstree -aeine leicht verständliche Strukturansicht der Prozesse und ihrer untergeordneten Prozesse zu erhalten, damit Sie bestimmen können, welcher Prozess diese sshds gestartet hat. lsofVielleicht hilft Ihnen auch, es wird Ihnen sagen, welche Dateien ein Prozess geöffnet hat.
Und stellen Sie sicher, dass Sie das neueste OpenSSH verwenden. Ich denke, Rsync + große Dateien + ssh auf einem alten OpenSSH 3.4p1 wäre problematisch.
Wenn dies NICHT wirklich sshd-Prozesse sind, wird möglicherweise eine MD5-Prüfsumme der Binärdatei korrekt angezeigt, es wird jedoch möglicherweise nicht das eigentliche sshd-Programm ausgeführt. Der md5sumBefehl selbst kann auch eine Backdoor-Version sein, die geändert wurde, um die korrekte Prüfsumme für bestimmte Dateien (wie z. B. sshd) zu melden.
Sie sollten sich / proc / [sshd pid] / exe ansehen und sicherstellen, dass es sich um einen Symlink zu / usr / sbin / sshd (oder wo immer sich Ihr sshd befindet) handelt, sowie / proc / [sshd pid] / environ, um dies zu sehen Welche Umgebungsvariablen es verwendet, und / proc / [sshd pid] / cmdline, um zu sehen, mit welchem Befehl es tatsächlich gestartet wurde.
Ein Angreifer hätte das Schadprogramm in "sshd" umbenennen und es dann ausführen können, damit es sshd zu sein scheint. Hätte sogar / usr / sbin / sshd nach / tmp / sshd verschieben können und dann das böswillige sshd nach / usr / sbin / sshd verschoben, um zu versuchen, es vor dieser Art von / proc-Analyse zu verbergen, aber wenn / tmp / sshd zurück verschoben wird / usr / sbin / sshd Der Symlink / proc / [sshd pid] / exe wird angezeigt lsals:
lrwxrwxrwx 1 root root 0 May 19 06:47 /proc/[sshd pid]/exe -> (deleted)/usr/sbin/sshd
Auch wenn diese sshd die etwas tun , aktiv in den normalen Prozessanalyse verhindern, könnten Sie versuchen , kill -STOPstatt kill -9auf „Pause“ wird der Prozess (Anwendung , kill -CONTum es wieder auf . Siehe http://en.wikipedia.org/wiki/Job_control_%28Unix%29 #Implementierung ).
Wenn ein Angreifer jedoch über Root-Rechte verfügt, kann ein Rootkit installiert werden, das sich vor / proc, netstat, ls usw. versteckt. Wenn Sie wirklich gefährdet sind, sollten Sie das System offline schalten und seine Partitionen auf einer anderen Partition bereitstellen ( Reinigen Sie das System und führen Sie dann die Forensik durch (oder verwenden Sie eine dieser Live-Linux-CDs für die Forensik).
