基本的なログを超えて：なぜhistoryとauth.logだけでは不十分なのか
Linuxコマンドラインのhistoryコマンドだけでセキュリティインシデントの全容を解明しようとしたことがあるなら、それがいかに困難かを知っているはずです。標準のシェル履歴は脆弱です。熟練したユーザーならコマンド一つで消去できますし、実行したコマンドの実際の出力結果までは記録されません。システム認証を記録する/var/log/auth.logでさえ、「コマンドが実行されたこと」は分かっても、そのセッション内で「何が起きたか」までは教えてくれません。
多くのシステム管理者は、scriptコマンドを使ってアクティビティを記録しようとします。しかし、これにはユーザーが自発的に記録を開始する必要があります。Sudo I/Oロギングは、記録メカニズムをsudoユーティリティ自体に組み込むことで、この問題を解決します。これはターミナル用のDVR（デジタルビデオレコーダー）のように機能し、すべてのキーストローク、バックスペース、そして出力の全行を正確なタイミングでキャプチャします。
主要な3つの追跡方法を比較してみましょう：
- シェル履歴（Shell History）: 簡単に削除可能（
history -c）。出力は記録されず、セキュリティ上の価値はほぼありません。 - Auditd: ファイルアクセスやシステムコールの追跡には優れています。しかし、生の監査ログから視覚的なセッションを再現するのは、ビデオファイルの生メタデータだけを読んで映画を鑑賞しようとするようなものです。
- Sudo I/Oロギング: TTYインタラクションを完全に記録します。ルート権限を持たないユーザーが回避することはほぼ不可能であり、セッションの完璧な視覚的再現を提供します。
セッション記録のトレードオフ
セッション記録の実装は、一度設定すれば終わりというものではありません。私は5ノードのスタートアップから数千台のサーバーを抱えるデータセンターまで、さまざまな環境でこれを導入してきましたが、その影響はワークロードに大きく依存します。
メリット
- 絶対的な責任の明確化: ユーザーが
rm -rf /を実行したことだけでなく、その瞬間に至るまでの正確なコマンドシーケンスと、どのようなミスがその事態を招いたのかを詳細に確認できます。 - トラブルシューティングの迅速化: 設定変更によって本番サービスが停止した場合、セッションを再生して、管理者が気づかなかったエラーメッセージを含む正確な構文を確認できます。
- コンプライアンス対応: このセットアップは、PCI-DSS、SOC2、HIPAAなどのフレームワークにおける特権アクセスの監視に関する厳格な要件を満たします。
デメリット
- ストレージの増大: すべての出力を記録するため、ログが肥大化する可能性があります。たとえば500MBのログファイルに対して
catを実行すると、500MBのセッション記録が作成されます。 - 機密データの露出: すべてがキャプチャされます。入力をマスクしないプロンプトにユーザーがパスワードを入力した場合、そのパスワードは監査ログ内にプレーンテキストで保存されてしまいます。
- パフォーマンスのオーバーヘッド: I/Oのすべてのバイトをディスクに書き込むため、わずかな遅延が発生します。Ubuntu 22.04（RAM 4GB）でのテストでは、CPUオーバーヘッドは1%未満であり、eBPFを活用した監視手法と同様に、サードパーティ製のエージェントよりも大幅に軽量でした。
推奨されるセットアップ構成
これらのログを中央サーバーにストリーミングすることも可能ですが、まずは堅実なローカル構成から始めましょう。すべてのsudoコマンドが、保護されたディレクトリに自動的に記録されるようにします。整理しやすくするために、ユーザー名とセッションIDごとにログを分類します。
設定は主に3つのパラメータに依存します：
iolog_dir: 記録が保存されるベースパス。iolog_file: 各セッションの命名規則。LOG_OUTPUTとLOG_INPUT: キャプチャする内容を定義するストリーム。
実装ガイド：Sudo I/Oロギングの設定
このガイドでは、Ubuntu、Debian、またはRHELなどの最新のディストリビューションを使用していることを前提としています。Sudoバージョン1.8.7以降が必要ですが、これは10年近く標準となっています。
ステップ1：セキュアなログディレクトリの作成
記録用の専用スペースが必要です。ユーザーが自分のセッション履歴を改ざんするのを防ぐため、このディレクトリの所有権は、Linux ACLなどを考慮しつつ、厳格にrootである必要があります。
sudo mkdir -p /var/log/sudo-io
sudo chmod 0700 /var/log/sudo-ioステップ2：Sudoersの安全な設定
可能な限り、/etc/sudoersを直接編集しないでください。代わりに、/etc/sudoers.d/にモジュール化された設定ファイルを作成します。これにより、メインの設定をクリーンに保ち、パッケージのアップデートによる設定の破損を防ぐことができます。
sudo visudo -f /etc/sudoers.d/audit-logsファイルに以下の設定を貼り付けます：
# ユーザーとホストごとにログを整理する
Defaults iolog_dir="/var/log/sudo-io/%{user}/%H"
Defaults iolog_file="%D-%T"
# ユーザーの入力と表示内容の両方をキャプチャする
Defaults log_output
Defaults log_input
# 監視されていることをユーザーに通知する
Defaults mail_badpass
Defaults lecture="always"
Defaults lecture_file="/etc/sudo_lecture"これらの変数の役割：
%{user}: ユーザーごとに固有のサブフォルダを作成します。%H: ホスト名を含めます。これは、後に複数のサーバーからログを集約する場合に不可欠です。%D-%T: 検索しやすいようにセッションにタイムスタンプを付与します。log_output: 画面出力（「動画」部分）を記録します。log_input: バックスペースや隠し文字を含む、すべてのキーストロークを記録します。
ステップ3：法的警告の作成（任意）
多くの地域では、アクティビティが記録されていることをユーザーに通知することが法的に義務付けられています。設定ファイルで指定したレクチャーファイルを作成しましょう：
sudo nano /etc/sudo_lecture明確な通知文を追加します：
注意：セキュリティおよびコンプライアンス確保のため、sudoの下で実行されるすべてのアクティビティは記録されています。ステップ4：記録の確認
標準ユーザーアカウントに切り替えて、いくつかのコマンドを実行し、データを生成します。
sudo apt update
sudo tail /var/log/syslog
exit次に、rootとしてログディレクトリを確認します。ttyinやttyoutなどのバイナリファイルを含む新しいフォルダ構造が表示されます。これらをcatで読み取ろうとしないでください。再生には専用のツールが必要です。
セッションの再生
セッションを発生した通りに正確に視聴するには、sudoreplayツールを使用します。システム上のすべての記録済みセッションのリストを表示するには、以下を実行します：
sudo sudoreplay -l特定のセッションを再生するには、リストにあるパスを指定します：
sudo sudoreplay /var/log/sudo-io/myuser/myhost/2023-10-27-14:30:05プロのヒント： ユーザーが長時間操作していなかった場合、その沈黙をじっと待つ必要はありません。-sフラグを使用して速度を上げたり（例：5倍速なら-s 5）、再生中に>キーを押して早送りしたりできます。
メンテナンスとセキュリティ
管理せずに放置すると、最終的に/varがいっぱいになります。管理者が1時間journalctl -fを実行するだけで、数メガバイトのログが生成されることがあります。
1. ログクリーンアップの自動化
Sudo I/Oログは自動的にはローテートされません。90日より古い記録を削除するシンプルなcronジョブを設定することをお勧めします。5人のアクティブな管理者がいるチームの場合、90日分のログは通常1GBから5GB程度の容量を占めます。
# 毎日午前2時に実行して古いログを削除する
0 2 * * * find /var/log/sudo-io -type d -mtime +90 -exec rm -rf {} +2. ログの整合性の強化
ルート権限を持つ攻撃者は、形跡を消すために真っ先にこれらのログを消去しようとします。ローカルマシン上のルートユーザーを完全に止めることはできませんが、rsyslogを使用してこれらのログをリモートの書き込み専用サーバーにストリーミングすることを検討してください。これにより、たとえローカルサーバーが侵害されても、証拠は別のマシンで安全に保たれます。
3. 選択的ロギング
ストレージ容量が限られている場合は、すべてをグローバルに記録する必要はありません。sudoersファイル内の特定のコマンドエイリアスに対してのみlog_outputを適用することも可能です。しかし、ディスク容量に余裕があるなら、セキュリティの観点からはグローバルロギングの方がほぼ常に優れています。
Sudo I/Oロギングは、あらゆるLinuxセキュリティスタックにおいて、低コストで高い効果を発揮する追加機能です. 不正な変更が行われたことを証明する場合でも、徹夜のトラブルシューティングの後に自分の手順を振り返る場合でも、この詳細な記録はシステム管理者にとって非常に強力なツールとなります。
