解決策 1:
Unix.Trojan.Mirai-5607459-1 の ClamAV シグネチャは明らかに範囲が広すぎるため、J Rock と cayleaf が指摘しているように、おそらく誤検知です。
たとえば、次のすべてのプロパティを持つファイルは署名と一致します:
- ELF ファイルです。
- 文字列「watchdog」が正確に 2 回含まれています。
- 文字列「/proc/self」が少なくとも 1 回含まれている;
- 文字列「busybox」が少なくとも 1 回含まれている
(署名全体はもう少し複雑ですが、一致するには上記の条件で十分です。)
たとえば、このようなファイルは次のように作成できます:
$ echo 'main() {printf("watchdog watchdog /proc/self busybox");}' > innocent.c
$ gcc -o innocent innocent.c
$ clamscan --no-summary innocent
innocent: Unix.Trojan.Mirai-5607459-1 FOUND
busybox ビルド (Linux 上) は通常、上記の 4 つのプロパティと一致します。これは明らかに ELF ファイルであり、文字列「busybox」が何度も含まれていることは間違いありません。 「/proc/self/exe」を実行して、特定のアプレットを実行します。最後に、「watchdog」が 2 回出現します。1 回はアプレット名として、もう 1 回は文字列「/var/run/watchdog.pid」内にあります。
解決策 2:
J ロックのように、これは誤検知だと思います。私も同じ経験をしました。
短時間で、地理的に離れた 6 つの異なるサーバーからアラームを受け取りました。これらのサーバーのうち 4 台は、プライベート ネットワーク上にのみ存在していました。共通点の 1 つは、最近の Daily.cld の更新です。
そこで、このトロイの木馬の典型的なヒューリスティックをチェックして成功しなかった後、既知のクリーンなベースラインで vagrant box を起動し、freshclam を実行しました。これはつかんだ
<ブロック引用>"daily.cld は最新です (バージョン:22950、署名:1465879、f レベル:63、ビルダー:neo)"
後続の clamav /bin/busybox 元のサーバーで同じ「/bin/busybox Unix.Trojan.Mirai-5607459-1 FOUND」アラートを返しました。
最後に、おまけとして、Ubuntu の公式ボックスから vagrant ボックスも作成し、同じ "/bin/busybox Unix.Trojan.Mirai-5607459-1 FOUND" を取得しました (注:この vagrant ボックスのメモリを増やす必要がありましたデフォルトの 512MB または clamscan が 'killed' で失敗)
新しい Ubuntu 14.04.5 vagrant ボックスからの完全な出力。
[email protected]:~# freshclam
ClamAV update process started at Fri Jan 27 03:28:30 2017
main.cvd is up to date (version: 57, sigs: 4218790, f-level: 60, builder: amishhammer)
daily.cvd is up to date (version: 22950, sigs: 1465879, f-level: 63, builder: neo)
bytecode.cvd is up to date (version: 290, sigs: 55, f-level: 63, builder: neo)
[email protected]:~# clamscan /bin/busybox
/bin/busybox: Unix.Trojan.Mirai-5607459-1 FOUND
----------- SCAN SUMMARY -----------
Known viruses: 5679215
Engine version: 0.99.2
Scanned directories: 0
Scanned files: 1
Infected files: 1
Data scanned: 1.84 MB
Data read: 1.83 MB (ratio 1.01:1)
Time: 7.556 sec (0 m 7 s)
[email protected]:~#
したがって、これは偽陽性である可能性が高いとも考えています。
つまり、rkhunter はしなかった 「/usr/bin/lwp-request Warning」リファレンスを教えてください。おそらく、PhysiOS Quantum に複数の問題がある可能性があります。
編集：これらのサーバーはすべてUbuntu 14.04であると明示的に言ったことがないことに気付きました。他のバージョンは異なる場合がありますか?
解決策 3:
これは今日、/bin/busybox の ClamAV スキャンでも表示されました。更新されたデータベースにエラーがあるのではないかと思っています。
解決策 4:
<ブロック引用>SSH 経由でログインしようとしましたが、パスワードが受け入れられませんでした。ルートログインが無効になっているので、レスキューに行ってルートログインをオンにすると、ルートとしてログインできました。 root として、以前にログインしようとしたのと同じパスワードで影響を受けるアカウントのパスワードを変更しようとしましたが、passwd は「パスワードは変更されていません」と応答しました。その後、パスワードを別のパスワードに変更してログインできました。その後、パスワードを元のパスワードに戻すと、再びログインできました。
これは期限切れのパスワードのように聞こえます。 root がパスワードを (正常に) 設定すると、パスワードの有効期限の時計がリセットされます。 できる /var/log/secure (または Ubuntu に相当するもの) をチェックして、パスワードが拒否された理由を見つけてください。