それらが実際にOpenSSH sshdである場合、スクリプトがどこかで壊れたループでそれらを実行しており、その子プロセスの1つがそのすべてのCPUを占有していると思います。
Marki555が提案したように、strace
あなたを助けるでしょうが、strace -f
straceが子プロセスに従うように使用すべきです。からman strace
:
-f Trace child processes as they are created by cur-
rently traced processes as a result of the fork(2)
system call.
straceは大量のデータを生成するため、-e引数も使用することをお勧めします(たとえば、open()呼び出しのみを表示する場合)。
-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]...
あなたが試すことができます別のコマンドがあるps xaf
か、pstree -a
あなたがそれらのsshdのを開始したどのようなプロセスを決定することができるようにプロセスとその子プロセスの理解しやすいツリービューを取得します。lsof
また、あなたを助けるかもしれない、それはプロセスが開いているファイルを教えてくれます。
そしてもちろん、最新のOpenSSHを使用していることを確認してください。私は古代のOpenSSH 3.4p1でのrsync +大きなファイル+ sshに問題があると考えています。
それらが実際にsshdプロセスではない場合、バイナリファイルのMD5チェックサムは正しく表示される場合がありますが、実際に実行されているsshdプログラムではない場合があります。また、md5sum
コマンド自体は、特定のファイル(sshdなど)の正しいチェックサムを報告するように変更されたバックドアバージョンである可能性があります。
/ proc / [sshd pid] / exeを確認し、/ usr / sbin / sshd(またはsshdが存在する場所)へのシンボリックリンクであること、および/ proc / [sshd pid] / environを確認してください。使用している環境変数、および/ proc / [sshd pid] / cmdlineを使用して、実際に開始したコマンドを確認します。
攻撃者は悪意のあるプログラムの名前を「sshd」に変更してから実行し、sshdのように見せることもできます。/ usr / sbin / sshdを/ tmp / sshdに移動した後、悪意のあるsshdを/ usr / sbin / sshdに移動して、そのタイプの/ proc分析から隠そうとしましたが、/ tmp / sshdに戻りました/ usr / sbin / sshd / proc / [sshd pid] / exeシンボリックリンクは次のように表示さls
れます:
lrwxrwxrwx 1 root root 0 May 19 06:47 /proc/[sshd pid]/exe -> (deleted)/usr/sbin/sshd
また、これらのsshdが通常のプロセス分析を積極的に妨げるために何かをしている場合、プロセスを「一時停止」するkill -STOP
代わりに試みることができkill -9
ます(kill -CONT
再開するために使用します。http://en.wikipedia.org/wiki/Job_control_%28Unix%29を参照)#実装)。
ただし、攻撃者がルート権限を持っている場合、/ proc、netstat、lsなどに隠れているルートキットをインストールできます。その後、システムはフォレンジックを実行します(またはフォレンジック用に作成されたライブLinux CDのいずれかを使用します)。