深夜2時の衝撃と、空のログを前にした無力感
想像してみてください。深夜2時、サーバーが毎分5,000リクエストのペースでSSHブルートフォース攻撃を受け、アラートが鳴り続けています。急いでログインして調査を始めますが、最悪な事態に気づきます。/var/log/auth.logやhistoryが攻撃者によって完全に消去されているのです。デフォルトのツールでは「誰が」侵入したかはわかっても、システムファイルに対して「何をしたのか」、あるいはどのようなバックドアを仕掛けたのかについては、まったくの「盲目」状態です。
Linuxのデフォルトログは、フォレンジック（鑑識）目的としてはあまりにも不十分です。/etc内の設定ファイルが改ざんされた際、カーネルレベルの監視システムがなければ、誰が実行したかを特定することは不可能です。これこそが、サーバーに真の「ブラックボックス」が必要な理由です。
なぜ通常のシステムログはしばしば「お手上げ」になるのか？
管理者の多くは、syslogやjournaldを盲信しがちです。しかし、これらのサービスはユーザー空間（user-space）で動作しています。ハッカーが一度ルート権限を奪取すれば、瞬時にサービスを停止させたり、ログファイルを改ざんしたりすることが容易にできてしまいます。
その理由は、これらのツールがシステムコール（syscalls）を無視しているからです。システムコールは、ソフトウェアとOSカーネルが直接やり取りする言語です。例えば、ファイルが削除されるときにはunlinkというシステムコールが実行されます。このシステムコールを捕捉できなければ、犯人の確実な証拠を見つけることはできません。また、タギング（タグ付け）機能がないため、数百万行のデータから必要なログをフィルタリングすることも悪夢のような作業になります。
監視の選択肢：表面的な確認から顕微鏡レベルの調査まで
効果的な追跡を行うために、私はこれまで様々な方法を試してきました：
lastやhistoryコマンドの使用： これは内部ユーザーの管理には役立ちますが、ハッカーがunset HISTFILEを実行するだけで、足跡は完全に途絶えてしまいます。- IDS（SuricataやLynisなど）の使用： 脆弱性スキャンには非常に優れていますが、ユーザーの行動をリアルタイムで詳細に記録することには長けていません。
- Auditdの設定： これはLinuxセキュリティにおける「ゴールドスタンダード」です。カーネルに直接介入し、要求したすべてのイベントを「スナップショット」として記録します。
Auditd – Linux上のあらゆる挙動を監視する最適なソリューション
Auditd（Linux Audit Daemon）は、サーバーのための勤勉な会計士のように機能します。ファイルの権限変更から機密コマンドの実行まで、あらゆることを記録します。以下に、実際のシステムでの導入方法を紹介します。
1. Auditdのクイックインストール
主要なディストリビューションへのインストールは非常に簡単で、30秒もかかりません：
# Ubuntu/Debian用
sudo apt update && sudo apt install auditd audispd-plugins -y
# CentOS/RHEL/Fedora用
sudo yum install audit -y
sudo systemctl enable auditd --now2. 「実践的」なルールセットの設定
デフォルトの状態では、Auditdが記録する内容はごくわずかです。/etc/audit/rules.d/audit.rulesファイルでルールを定義する必要があります。私は通常、「ファイル監視」「管理者コマンド」「データ削除のシステムコール」の3つのグループに重点を置いています。
設定ファイルを開きます：
sudo nano /etc/audit/rules.d/audit.rules最も重要な領域を保護するために、以下の行を追加します：
# ユーザー/パスワードの変更を監視
-w /etc/passwd -p wa -k user-modify
-w /etc/shadow -p wa -k user-modify
# ネットワーク設定ファイルを監視
-w /etc/network/ -p wa -k network-config
# sudoコマンドの使用履歴を記録
-w /usr/bin/sudo -p x -k privileged-access
# ファイルの削除または名前変更を捕捉
-a always,exit -S unlink -S unlinkat -S rename -S renameat -k delete-activityパラメータの簡単な解説：
-w: 監視するパス。-p wa: 書き込み（write）と属性変更（attribute）の権限を監視。-k: 後でログを瞬時に検索するためのラベル（キー）を割り当て。-S: 捕捉するシステムコール名。
保存後、サービスを再起動します：
sudo service auditd restart3. 有事の際の高速ログ検索
データの迷宮に迷い込んでしまうため、audit.logをcatで読むのは絶対にやめましょう。非常に強力なログフィルタリングツールであるausearchを使用します。
例えば、誰が/etc/passwdファイルに触れたかを確認するには：
sudo ausearch -k user-modifyその日の失敗した侵入試行の概要レポートを表示したい場合は：
sudo aureport -f -i --failed教訓：ログにディスク容量を「食いつぶさせない」
私の最大の失敗は、かつてあまりにも欲張った設定をしてしまったことです。負荷の高いデータベースサーバーですべてのreadシステムコールを監視したところ、わずか2時間で50GBのログが生成され、サーバーが即座にフリーズしてしまいました。
管理者の皆さんへのアドバイス：
- 本当に重要なものだけを監視する：設定ファイル、管理者コマンド、所有権など。
- ディスクフルを防ぐため、
/etc/audit/auditd.confでログローテーションを設定する：
max_log_file = 100 # ファイルが100MBに達したらローテーション
num_logs = 10 # 最大10個の古いファイルを保持
max_log_file_action = ROTATEAuditd의導入によりCPU使用率が1〜3%増加する可能性がありますが、手がかりなしにデータを完全に失うことに比べれば、その代償は非常に安価です。本番環境（Production）を運用している場合や、PCI-DSSへの準拠が必要な場合、Auditdは必須のツールです。ルールの書き方で困ったことがあれば、下のコメント欄で教えてください。サポートします！
