auditd は事の後に浮かぶ問いに答えます。このファイルを誰が変えたのか、このユーザーはいつ作られたのか、このプロセスはどこから起動されたのか。ほかのツールはそれに答えません——アプリケーションのログにその情報は無く、シェルの履歴はそれを残した本人が編集できます。

難しいのは、パッケージを入れるだけでは何も得られないことです。既定のルールは実質ありません。ジャーナルは書かれていますが中身は空で、そしてそれが判明するのは最悪の瞬間——データが必要なのに無いときです。

インストール

sudo apt install auditd audispd-plugins
sudo systemctl status auditd

一つ特徴があります。いくつかの版では auditd を systemctl restart で再起動できません——このサービスは自前のコマンドで管理されます。ルールはこう読み直します。

sudo augenrules --load
sudo auditctl -l

二つ目のコマンドが実際に読み込まれたものを示します。ファイルの中身ではなく、これを信じてください。

ルールの組

ルールは /etc/audit/rules.d/ に別ファイルとして置きます。以下は元が取れる最小限の組です。ディスクを埋め尽くさずに、事故の際に出てくる問いの大半に答えてくれます。

sudo tee /etc/audit/rules.d/50-baseline.rules <<'EOF'
## ユーザーと権限
-w /etc/passwd -p wa -k identity
-w /etc/shadow -p wa -k identity
-w /etc/group -p wa -k identity
-w /etc/sudoers -p wa -k privileges
-w /etc/sudoers.d/ -p wa -k privileges

## SSH のアクセス
-w /etc/ssh/sshd_config -p wa -k sshd_config
-w /root/.ssh/ -p wa -k ssh_keys

## スケジュールされたジョブ
-w /etc/crontab -p wa -k cron
-w /etc/cron.d/ -p wa -k cron
-w /var/spool/cron/ -p wa -k cron

## カーネルモジュール
-w /sbin/insmod -p x -k modules
-w /sbin/modprobe -p x -k modules
-a always,exit -F arch=b64 -S init_module -S delete_module -k modules

## sudo と su の使用
-w /usr/bin/sudo -p x -k privileged
-w /bin/su -p x -k privileged
EOF
sudo augenrules --load

構文は短いものです。-w は監視するパス、-p wa は書き込みと属性変更に反応する、-p x は実行に反応する、-k は後で検索するための鍵です。この鍵こそが主な便利さです。それが無ければジャーナルの検索は一ギガバイトのテキストのふるい分けになります。

その一覧に無いもの、そしてその理由

手引きはしばしば execve のすべての呼び出し——つまりあらゆるプログラムのあらゆる起動——を記録することを勧めます。誘惑は理解できます。何が行われたかの完全な絵です。実際には、稼働中のサーバーではそれは一日に数百メガバイトを生み、プロセッサの目に見える割合を食い、必要になる前にジャーナルが切り詰められる結果を招きます。その粒度が本当に要るなら、狭く有効にしてください——一人のユーザーについて、あるいは調査の期間だけ。

サイトのディレクトリを監視する場合も同じです。そこへの書き込みは絶え間なく、そのルールはジャーナルを無意味なイベントの流れに変えてしまいます。

読み方

鍵で検索し、数値の識別子は名前に直します。

sudo ausearch -k identity -i
sudo ausearch -k privileges -i -ts today

読めるようにするには -i フラグが欠かせません。これが無いとユーザー名やシステムコール名の代わりに数字が並びます。-ts は期間を絞ります（today、recent、あるいは具体的な日付）。

期間のまとめ：

sudo aureport --summary -i
sudo aureport --auth -i --failed

イベントの記録では三つの項目が興味深いものです。セッションを開いたユーザーの識別子 auid、その動作が実行された身元 uid、そしてそれを実行したプログラム exe。auid と uid の差こそが「正確に誰が root になったのか」への答えです。特定の人物の auid を伴う uid=0 は、そのセッションの中で本人が何を名乗っていようと、当事者を一義的に指し示します。

ディスク

大きさの設定は /etc/audit/auditd.conf にあります。

max_log_file = 50
num_logs = 5
max_log_file_action = ROTATE
space_left = 500
space_left_action = SYSLOG

disk_full_action は別途見てください。設定によっては、ディスクが埋まったときにシステムを停止するのが既定です——監査要件のあるマシンでは筋の通った振る舞いですが、Web サーバーではまったく場違いです。ディスクが尽きる前にその値を確認してください。

変更不可のルール

ルールファイルの末尾の -e 2 の行は、再起動までルールの変更を禁じます——root を得た者に対しても同じです。これはジャーナルの価値を目に見えて高めます。侵入者はマシンを再起動せずに監視を切れませんし、再起動それ自体が目立つからです。

裏面は明らかです。あなた自身も再起動なしには自分のルールを変えられません。ルールの組が落ち着き、それと一か月暮らしてから有効にしてください。

普通のサーバーになぜ必要なのか

auditd は何も防ぎません。その価値が現れるのはちょうど一度きり——出来事の順序を再構成しなければならないときであり、そのときデータは在るか無いかのどちらかです。それは遡って集めることができません。だからこそルールの組は前もって置き、そのあとは触らないのです。

設定が正しいことの実務的な印は、ルール一覧が空でないこと、ジャーナルが制御不能に膨らまないこと、そして identity と privileges の鍵を持つイベントがまれにしか現れず、そのどれもが説明できることです。それが一つのページでどう見えるかは下のデモで。