このブログを提供しているWeb サーバはSecurity Center のEnterprise Edition で監視や防御をしています。 その機能の一環で毎日レポートメールを受け取っているのですが今朝のメールで以下のメッセージを受け取りました。
“Your assets are exposed to the risks of hacker intrusion and virus infection.” (あなたのサーバはウイルス感染もしくはハッカーによる侵入のリスクにさらされています）
メール本文のSafety Score のチャートの点数も前日までの100点から80点に下がっています。
本当にクラッキングされたとすると大変です。今回は心当たりはあったので特にサーバへの通信の制限やサービス停止は行わずに調査を進めます。
心当たりがなくクラッキングされた可能性が少しでもあるならばオフラインにして仮想ディスクをコピーして他のマシンにマウントしての調査をお勧めします。 すでにやられている状態ですとコマンドも置き換えられて痕跡も中途半端にしか探せないですし、クラウド上のサーバをオンラインのまま調査することは被害を広げる可能性もあります。 自分自身のサーバのデータが削除される位なら良いですが、このサーバから第三者に攻撃する可能性もあるわけです。
まずは、Alibaba Cloud のコンソールにログインし、Security Center から状況を確認していくことにします。
“Unhandled Alerts” の1件をクリックします。
1件のアラートがリストされています。タイトルは
“Modify System File Sensitive file tampering”
です。 こちらをクリックし、詳細を確認します。
詳細画面が表示されます。
冒頭にこのリスクの概要が以下の通り説明されています。
“The model detected that the system file on your system was abnormal. Hackers usually replace the system files to avoid detection and hide backdoors. Please confirm the file is a real system file in time.”
システムファイルが危険な状態であることを検知したよ、ハッカーは痕跡を隠すためにファイルを入れ替えるよ、そのファイルが正しいものか確認しよう、とのこと。
また、検知した理由として以下の説明があります。 /usr/bin/file が変更されたとのこと。
Reason： Cloud Security Center monitors the process write file event and finds that the following process has write event to the following system file
System File：/usr/bin/file
Command Line：/usr/bin/mandb -pq
時刻は2020/6/27 06:57:04です（私のサーバのTimeZoneはインスタンスの既定のままなのでJSTではなくCSTです。 +08:00です。 06:57は日本時間だと07:57です）。 この時点で私はこのシステムファイルの変更の原因が頭に浮かびます。 Ubutu サーバにパッチを適用していました。
“/var/log/dpkg.log” を確認します。 2020/6/27 06:56 ごろから更新を開始しています。
| root@bigriver3:/var/log# head -10 dpkg.log 2020-06-27 06:56:59 startup archives unpack 2020-06-27 06:56:59 upgrade libnss-systemd:amd64 237-3ubuntu10.39 237-3ubuntu10.41 2020-06-27 06:56:59 status triggers-pending libc-bin:amd64 2.27-3ubuntu1 2020-06-27 06:56:59 status half-configured libnss-systemd:amd64 237-3ubuntu10.39 2020-06-27 06:56:59 status unpacked libnss-systemd:amd64 237-3ubuntu10.39 2020-06-27 06:56:59 status half-installed libnss-systemd:amd64 237-3ubuntu10.39 2020-06-27 06:56:59 status triggers-pending man-db:amd64 2.8.3-2ubuntu0.1 2020-06-27 06:56:59 status half-installed libnss-systemd:amd64 237-3ubuntu10.39 2020-06-27 06:56:59 status unpacked libnss-systemd:amd64 237-3ubuntu10.41 2020-06-27 06:56:59 status unpacked libnss-systemd:amd64 237-3ubuntu10.41 |
あとはfileコマンドが含まれるPKGを検索します。
“file” というPKGですね。
| root@bigriver3:/var/log# dpkg –search /usr/bin/file file: /usr/bin/file |
もういちど”/var/log/dpkg.log”ファイルを確認します。 Security Center からのアラート時刻と同じ 06:57:04 に”file” PKG のupgrade を行っています。
| ～省略～ 2020-06-27 06:57:04 upgrade file:amd64 1:5.32-2ubuntu0.3 1:5.32-2ubuntu0.4 ～省略～ |
ということでシステムファイルの更新の原因が判明というか辻褄は合いました。結論、問題なしです。 まあ、疑えばリポジトリから入手した”file”PKG自体が不正な可能性は残りますが。 その疑いを晴らすには個別にファイルハッシュの確認などを行うべきでしょうがそこまではやりません。 PKG管理システムの中で実施しているでしょうし。
ここからは後処理です。 Security Center で今回のシステムファイルの変更は”問題なし”と処理します。
“Processing” をクリックします。
以下の3つの選択肢があります。 今回は”Ignore”とします。 次回のOSパッチ適用でまたアラートがあがると思いますが、それはその都度確認することにします。
- Whitelist
- Igonre
- Handled manually
“Confirm” をクリックします。
ちなみに中国語”篡改系统文件”は日本語”システムファイルの改ざん”です
最終的にはSafety Score も100点に戻りました。
インターネットに公開するサーバにおいてシステムファイルの改ざんチェックは当たり前に実施していることかと思います。 Open Source のAIDE でも商用のTripwire でも最近の商用マルウェア対策ソフトウェアでも似たようなことは出来ると思います。 それらのツールを使うことは全く否定しませんがSecurity Center では他の機能と統合的に防御が提供され、また簡単かつリーズナブルなコストで提供されていることが長所だなと再認識出来ました。 まあ所々中国語な点やそもそも日本語対応してくれればもっともっと推せるプロダクトになるのですが。
今日はここまで。
