Linuxファイル改ざん検知:AIDEで密かな変更を特定する

Security tutorial - IT technology blog
Security tutorial - IT technology blog

未知の脅威からファイルシステムを保護する

以前、本番環境のノードの1つに対して午前2時にSSHブルートフォース攻撃が行われているのを見てパニックになったことを覚えています。IPをブロックした後も、「何かに触れられたのではないか?」という疑問が拭えませんでした。攻撃者は一度足がかりを得ると、バックドアを残したり、自身の存在を隠すためにシステムバイナリを書き換えたりすることがよくあります。ファイルのタイムスタンプだけに頼ることはできません。巧妙な攻撃者は touch コマンドを使用してアクセス時間をリセットし、一見しただけではファイルが手つかずであるかのように見せかけます。

だからこそ、私はファイル改ざん検知(FIM: File Integrity Monitoring)を信頼しています。私はAIDE(Advanced Intrusion Detection Environment)を使用して、システムのすべての重要なファイルのデジタル指紋を作成しています。バイナリ内のたった1ビットでも変更されれば、AIDEは即座にそれをフラグ立てします。Linuxファイルシステムのためのハイテクな「仕掛け線(トリップワイヤー)」だと考えてください。

FIM vs. 標準システムログ:AIDEの役割

セキュリティ監視は「一律」ではありません。強固な防御を構築するには、異なるツールがどのように互いを補完し合うかを理解する必要があります。

標準ログ (Syslog/Journald)

ログはイベントの経緯を伝えます。ユーザーがいつログインしたか、サービスがいつ失敗したかを記録します。しかし、ルート権限を持つ攻撃者は、これらのログを簡単に消去したり、ログサービス自体を停止させたりできます。ログは、/usr/bin/ls バイナリが悪意のあるバージョンに差し替えられたかどうかを教えてくれることは滅多にありません。

リアルタイム監視 (Auditd/Inotify)

auditd のようなツールは、システムコールが発生した瞬間に追跡します。午後10時15分に誰がファイルを変更したかを特定するのに非常に優れています。欠点はパフォーマンスです。負荷の高いWebサーバーでは、auditd は1時間ごとに数ギガバイトのデータを生成する可能性があり、分析がすぐに悪夢のような作業になります。

スナップショットベースのFIM (AIDE)

AIDEは異なるアプローチを取ります。権限、サイズ、SHA-512などの暗号化ハッシュを含む、ファイル属性のベースラインデータベースを作成します。チェックを実行すると、AIDEは現在のディスクの状態を、この既知の正常なスナップショットと比較します。ログが削除されていても、何が変更されたかを正確に特定できるため、フォレンジック分析のゴールドスタンダード(標準指標)とされています。

AIDE運用の現実

AIDEをインフラ全体にデプロイする前に、運用コストとセキュリティ上のメリットを天秤にかける必要があります。

メリット

  • バックグラウンドのノイズがゼロ: AIDEはバックグラウンドデーモンではありません。チェックを実行するまでCPUやRAMを一切消費しないため、リソースの少ないVPSインスタンスに最適です。
  • 暗号学的な確実性: 複数のハッシュアルゴリズムを使用することで、攻撃者がアラートを発生させずにファイルを変更することは統計的に不可能です。
  • きめ細かな制御: /etc/shadow を厳重に監視しつつ、/var/log のような変動の激しいディレクトリを除外できます。

課題

  • メンテナンスのオーバーヘッド: apt upgrade を実行するたびに、AIDEデータベースを更新する必要があります。これを忘れると、次回のレポートには正当なソフトウェアアップデートによる何百もの「誤検知」が表示されることになります。
  • 事後検出: AIDEは予防ツールではなく、検知ツールです。ファイルが変更されるのを防ぐわけではなく、被害が発生した後に通知するだけです。
  • データベースのセキュリティ: 攻撃者がファイルを変更した後に aide --update を実行すると、ベースラインが侵害されます。真に安全を期すには、データベースをリモートの読み取り専用システムに保存する必要があります。

本番環境へのデプロイ戦略

本番環境にデプロイする場合は、一度にすべてを監視しようとしないでください。アラート疲れを避けるために、焦点を絞ったポリシーから始めましょう。

  1. バイナリと設定ファイルに集中する: /etc/bin/sbin/usr/bin を監視します。特別な理由がない限り、/var/tmp/home は避けてください。
  2. オフサイトストレージ: 初期化後、すぐにデータベースをリモートの安全なサーバーまたは読み取り専用ボリュームに移動してください。
  3. レポートの自動化: セキュリティチームにサマリーをメール送信する日次のcronジョブをスケジュールし、手動でチェックする手間を省きましょう。

ステップバイステップ導入ガイド

このウォークスルーではUbuntu 22.04を使用しますが、コマンドは他のDebianベースのディストリビューションとほぼ同じであり、RHELでも非常によく似ています。

ステップ1:AIDEのインストール

まず、ローカルのパッケージインデックスを更新してユーティリティをインストールします。

sudo apt update
sudo apt install aide -y

プロセスの途中で、メール設定に関するプロンプトが表示される場合があります。ほとんどの管理者は、サーバーがSMTPリレー経由でレポートを送信できるように「Internet Site」を選択します。

ステップ2:ベースラインの初期化

次に、システムの現在の状態をキャプチャする必要があります。これが「既知の正常な」ベースラインとなります。

sudo aideinit

使用率約20%の標準的な50GB SSDでは、通常3〜5分かかります。このコマンドにより、/var/lib/aide/aide.db.new.gz に新しいデータベースファイルが作成されます。

ステップ3:データベースの有効化

AIDEはチェックを実行するために aide.db.gz を探します。初期化では .new ファイルが作成されるため、アクティブにするには名前を変更する必要があります。

sudo cp /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gz

今すぐこのファイルを別の安全なマシンにコピーすることを強くお勧めします。サーバーが侵害された場合、このファイルだけが何が変更されたかを証明する唯一の手段となります。

ステップ4:侵入のシミュレーション

実際に動作を確認するために、攻撃者の一般的な手口である、バックドアユーザーの追加をシミュレートしてみましょう。

echo "tempadmin:x:0:0:tempadmin:/root:/bin/bash" | sudo tee -a /etc/passwd
sudo aide --check

AIDEは詳細なレポートを生成します。/etc/passwd が変更されたことが示され、ファイルサイズやSHA-512ハッシュ値の具体的な変更内容がリストアップされます。

ステップ5:ルールのカスタマイズ

AIDEの通知が多すぎる場合は、監視対象を絞り込むことができます。Ubuntuでは、設定は /etc/aide/aide.conf または /etc/aide/aide.conf.d/ 内のファイルで管理されます。

セキュリティ設定を高くしたWebルートなどの特定のディレクトリを監視するには、カスタムルールを追加します:

# ルールを定義: p (権限), i (iノード), n (リンク数), u (ユーザー), g (グループ), s (サイズ), m (修正時刻), c (変更時刻), sha512 (ハッシュ値)
WebRule = p+i+n+u+g+s+m+c+sha512

/var/www/html WebRule

ステップ6:ソフトウェア変更後の更新

apt upgrade の実行などの正当なメンテナンスを行うと、AIDEはこれらも変更として正しく識別します。新しいベースラインを設定するには、データベースを更新します:

sudo aide --update
sudo cp /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gz

ステップ7:日次チェックの自動化

手動チェックは忘れがちです。通常、私は /etc/cron.daily/aide-check にスクリプトを配置して、プロセスを自動化しています:

#!/bin/bash
# $(hostname) の AIDE レポートを送信する
/usr/bin/aide --check | mail -s "$(hostname) の AIDE レポート" [email protected]

スクリプトに実行権限があることを確認します:

sudo chmod +x /etc/cron.daily/aide-check

データベースの整合性に関する最終的な考察

AIDEにおける最大のリスクは、データベースそのものです。もし私がルート権限を持つ攻撃者なら、真っ先に aide --update を実行して証拠を隠滅します.これを防ぐために、データベースを読み取り専用のUSBメモリに保存するシステム管理者もいます。また、中央サーバーを使用してノードにデータベースをプッシュし、チェックを実行した直後にローカルコピーを削除する方法もあります。セキュリティは決して「一度設定すれば終わり」というものではありませんが、AIDEは自身のファイルシステムを再び信頼するために必要な可視性を提供してくれます。

Share: