Traceeによるランタイムセキュリティ監視:LinuxシステムのためのeBPF「監視の目」

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

なぜ従来のシステムログでは不十分なのか?

午前2時、サーバーがSSHブルートフォース攻撃を受けたと想像してみてください。IPをブロックした後、ログを確認してもログイン/ログアウトの情報しか残っていません。もしハッカーがすでにRAM上で直接動作する「ファイルレスマルウェア」を仕掛けていたり、コンテナの深部からリバースシェルを作成していたりした場合、従来の監視ツールでは検知を逃してしまうことがよくあります。

私も以前このような状況に直面し、サーバーに負荷をかけずにシステムの隅々まで見通せるソリューションが必要だと痛感しました。その答えが、Aqua Securityが提供するTraceeです。このツールはeBPF (extended Berkeley Packet Filter)を活用し、Linuxカーネル内で小さなプログラムを直接実行します。これにより、すべてのシステムコール(syscall)ネットワークの挙動を極めて低い遅延で監視できます。

Kubernetesを運用しているなら、Traceeは「赤外線カメラ」のような存在です。ハッカーが意図的に隠そうとする極めて不審な挙動も暴き出してくれます。

クイックスタート:5分でTraceeを体験する

最も手軽に始めるにはDockerを使用します。唯一の要件は、DockerエンジンがインストールされたLinuxサーバー(Ubuntu 20.04以降、Kernel 5.4以上を推奨)です。

docker run --name tracee --rm -it \
  --privileged \
  --pid=host \
  -v /lib/modules:/lib/modules:ro \
  -v /usr/src:/usr/src:ro \
  -v /tmp/tracee:/tmp/tracee \
  aquasec/tracee:latest

重要なパラメータの解説:

  • --privileged: TraceeがeBPFコードをカーネルに直接ロードするための権限を付与します。
  • --pid=host: ホストOS上で実行されているすべてのプロセスをTraceeが「見える」ようにします。
  • -v /lib/modules...: カーネルディレクトリをマウントし、Traceeが現在のシステム構造を理解できるようにします。

コマンドを実行すると、イベントのストリームが即座に表示されます。別のターミナルを開いて whoami と入力してみてください。Traceeがそのコマンドの execve システムコールを瞬時にキャプチャするのが確認できるはずです。

なぜeBPFが「究極の武器」なのか?

以前は auditdptrace が一般的でしたが、これらはリソースを大量に消費したり、アプリケーションの速度を大幅に低下させたりする(オーバーヘッド)という課題がありました。eBPFは以下の3つの要素により、そのルールを完全に変えました。

  1. 絶対的な安全性: eBPFコードは実行前に検証器(verifier)を通過する必要があり、カーネルをクラッシュさせることはありません。
  2. 圧倒的なパフォーマンス: 最も低いレイヤーでデータを処理するため、ほとんどのシナリオでオーバーヘッドを5%以下に抑えられます。
  3. 深い介入能力: ファイルのオープン、ネットワーク接続から、不審なモジュールのロードまで追跡可能です。

Traceeは単なる生ログのリストアップにとどまりません。インテリジェントなSignatures(シグネチャ)機能を備えています。このフィルタリング機能により、システムファイルの書き換えやコンテナエスケープ(container escape)の試みなど、攻撃の兆候を検知した際に自動的にアラートを発します。

実践的な設定:重要なターゲットに集中する

デフォルト設定でTraceeを実行すると、大量のデータに埋もれてしまいます。効率的に運用するには、セキュリティ上の価値があるイベントに絞り込む(フィルタリング)必要があります。

1. 特定のコンテナを監視する

特定のWebアプリケーションが攻撃を受けている疑いがある場合は、--scope フラグを使用して範囲を絞り込みます:

# 'my_web_app' コンテナから発生するイベントのみを監視
docker run --rm --privileged -v /lib/modules:/lib/modules:ro -v /usr/src:/usr/src:ro aquasec/tracee:latest \
  --scope container=my_web_app

2. 攻撃検知モード(セキュリティポリシー)を有効にする

これはTraceeの最も価値のある機能です。例えば、誰かがカーネルに不審なモジュールをロードしようとして insmod コマンドを実行した際に警告を出すように設定できます。

docker run --rm --privileged -v /lib/modules:/lib/modules:ro -v /usr/src:/usr/src:ro aquasec/tracee:latest \
  --policy /tracee/policies/default.yaml

3. SIEMシステム用にJSONデータを出力する

ELK、Splunk、またはWazuhと統合するには、ログをJSON形式に変換します。これにより、データの自動パースが容易になります。

docker run --rm --privileged -v /lib/modules:/lib/modules:ro -v /usr/src:/usr/src:ro aquasec/tracee:latest \
  --output json

実運用から学んだ教訓

大規模なシステムでTraceeを運用してきた経験から、いくつか重要な注意点をお伝えします:

「フルロギング」の罠に注意

eBPFは非常に高速ですが、生成されるデータによってディスク容量が急速に圧迫される可能性があります。負荷の高いサーバーで --event any を有効にすると、1時間で数GBのログが生成されることもあります。execvemem_prot_alertsecurity_file_open といった機密性の高いイベントにのみ集中しましょう。

誤検知(False Positives)の管理

導入当初、Traceeは誤報を出すことがあります。例えば、tar を使用した定期的なバックアップスクリプトが、不審な大量ファイル読み取りと見なされる場合があります。最初の1週間は観察期間とし、正当なプロセスをホワイトリストに登録しましょう。

Kubernetesへの展開

K8s上で各コンテナを手動で実行しないでください。tracee-operator を使用しましょう。これはDaemonSetとしてデプロイされ、ログにPod名やNamespaceを自動的に付与するため、インシデントの追跡が10倍速くなります。

アラートシステムとの連携

ログはタイムリーに確認できてこそ価値があります。私は通常、シンプルなPythonスクリプトを使用してTraceeのJSONログをフィルタリングしています。High(高)またはCritical(緊急)レベルのイベントを検知すると、即座にTelegramやSlackに通知を飛ばすようにしています。

おわりに

現代のサーバーセキュリティは、ファイアウォールを設置したりアンチウイルスソフトを入れたりするだけでは不十分です。今日の攻撃者は非常に巧妙であり、より深い階層での監視ツールが必要です。TraceeとeBPFは、Linuxシステムの「内部」で何が起きているかを完全に把握するための最強のコンビです。

ぜひ今日からTraceeをインストールして、その威力を体験してみてください。堅牢なシステムを構築できることを願っています!

Share: