完全性監視は、アンチウイルスもファイアウォールも答えない問いに答えます。先週からこのサーバーで何が変わったか、という問いです。シグネチャ型のスキャナは既知の悪しきものを探します。AIDE は悪しきものについて何も知らず、ただこのファイルが昨日は違っていたことを知っています。既存のファイルの末尾に足された裏口を見つけるには、これが唯一機能する考え方です。

AIDE は二つのコマンドで入ります。難しいのは、そのレポートが読まれるように設定することのほうです——そしてたいていそこで息絶えます。最初のレポートが一万行を連れてきて、二通目は誰も開かず、一か月後にはそのジョブが消されるのです。

インストールと最初のデータベース

sudo apt install aide aide-common
sudo aideinit

初期化には数分から三十分ほどかかります。すべてのファイルのハッシュが計算されるからです。結果は作業用データベースの隣に .new の接尾辞つきで置かれ、それを使用状態にする必要があります。

sudo mv /var/lib/aide/aide.db.new /var/lib/aide/aide.db

以後、確認はこう走らせます。

sudo aide --check

レポートを読める状態に保つために何を除外するか

設定は /etc/aide/aide.conf とディレクトリ /etc/aide/aide.conf.d/ にあります。Debian の標準設定は見すぎであり、まずやるべきは、ひとりでに変わり続けるものを外すことです。

  • /var/log——毎秒変わります；
  • /var/lib 全体——データベース、パッケージの状態、サービスの状態；
  • /var/cache、/tmp、/proc、/sys、/run；
  • サイトのアップロードとキャッシュのディレクトリ——その中身は訪問者が変えます。

最も厳しい設定で見る価値があるのは狭い一覧です。

  • /bin、/sbin、/usr/bin、/usr/sbin——システムの実行ファイル；
  • /lib、/usr/lib——ライブラリ；
  • /etc——設定；
  • /root/.ssh とあなたのユーザーの .ssh ディレクトリ；
  • サイトのコード。ただしアップロードとキャッシュのディレクトリは除く。

目安は、普通の日次レポートが一画面に収まることです。それより長ければ除外が足りておらず、やがて読まれなくなります。

データベースをどこに置くか

見落とされがちな大事な点です。他人が root を持っているなら、ファイルを差し替えてすぐ AIDE のデータベースを更新することなど造作もありません——そしてその後の確認はすべて順調だと報告します。同じマシンにあり書き込み可能なデータベースが守るのは、事故からだけです。

一台のサーバーにとって妥当な最低限は：

  • 更新のたびにデータベースを別のマシンへコピーし、その控えを戻したうえで確認を走らせる；
  • あるいは少なくともデータベースのチェックサムを別に保存し、確認の前に突き合わせる：
sha256sum /var/lib/aide/aide.db

これほど単純な手当てでも、静かなすり替えを気づける出来事に変えてくれます。

データベースの更新は意識的な行為

正当な変更の後——システムの更新、サイトの新しい版の配置——にはデータベースを組み直します。

sudo aide --update
sudo mv /var/lib/aide/aide.db.new /var/lib/aide/aide.db

それをいつ行うかが重要です。正しいやり方は、レポートを読み、すべての変更が説明できると納得してから更新することです。誤っていて、しかも非常によくあるやり方は、レポートがきれいに出るように aide --update をスケジュールに入れることです。後者では、システムは動き、レポートは届き、そして変更はまさにそれが起きた瞬間に正常として記録されます——つまり意味は完全に失われています。

スケジュールと負荷

aide-common パッケージは日次のジョブを自分で入れます。確認は数分のあいだディスクとプロセッサに負荷をかけるので、静かな時間帯に優先度を下げて走らせる価値があります。

0 4 * * * ionice -c3 nice -n19 /usr/bin/aide --check

レポートの読み方

三つの区分：追加されたファイル、消されたファイル、変わったファイル。変更ごとに、正確に何が違うかが示されます。中身、権限、所有者、時刻です。

まず反応すべきもの：

  • 更新の時間枠の外で /bin、/sbin、/usr/bin のファイルが変わったこと；
  • システムのディレクトリに現れた新しいファイル；
  • authorized_keys、/etc/passwd、/etc/sudoers、/etc/crontab、/etc/cron.d の変更；
  • 現れたファイル /etc/ld.so.preload——それはひとりでに現れることはありません。

apt upgrade の直後に百のファイルが変わっているのは普通のことで、レポートの時刻がそれを裏づけます。更新のない水曜日に /usr/bin のファイルが三つ変わっているなら、それは立ち止まって調べる理由です。

AIDE と debsums

二つのツールは隣り合った問題を解きますが、比較の基準が違います。AIDE は自分で取ったスナップショットと比べます——だからサイトのコードも含め、どんなファイルの変更も見えます。debsums はディストリビューションのパッケージにあるチェックサムと比べます——だから事前の準備が一切無くても差し替えられたシステムファイルが見えますが、パッケージの外で入れたものについては何も知りません。両方を持つのは理にかなっています。実務ではたいてい debsums のほうが先に入ります。設定もデータベースも要らないからです。

両者には共通の弱点もあります。レポートがメールで届き、そしてメールは失われるということです。ですから大事なのは確認が走ったことではなく、その最新の結果が見える場所があることです。それがどう見えるかは下のデモページで。