eBPFによるランタイムセキュリティ（Falco・Tetragon）

侵入検知の伝統的な発想は「境界を固める」でした。しかしコンテナが侵害された後、実行中のプロセスが今まさに何をしているかを見なければ、脱出やインジェクションは素通りします。Falco と Tetragon は eBPF でカーネルイベントをストリーム監視し、この「実行時の不審な挙動」を検知します。同じ eBPF でもゼロインストルメンテーション可観測性がメトリクス再構成を目的とするのに対し、本稿が扱うのは攻撃を検知するための評価パイプラインです。

シスコール監視の仕組み：イベントストリームとルールエンジン

Falco はカーネルモジュールまたは eBPF プログラムを使い、execve / openat / connect / ptrace などのシスコールをフックして、発生ごとにイベントをユーザー空間へ送ります。Tetragon はこれを eBPF プログラム内でさらに一歩進め、カーネル内でイベントをフィルタし、条件に合致したものだけを ring buffer 経由でユーザー空間へ渡す構成を取ります。ユーザー空間まで全イベントを送るとオーバーヘッドが無視できないため、カーネル内フィルタリングは本番導入の生命線です。

[カーネル] execve/openat/connect/ptrace 発火
      │ eBPFプログラムがフック
      ▼
   プロセスコンテキストを付与（PID, コンテナID, 実行ファイルパス, 呼び出し元系譜）
      │ カーネル内で条件フィルタ（Tetragon）/ 全イベント送出（Falco既定）
      ▼
[ユーザー空間] ルールエンジンが条件マッチング
      │ シグネチャ一致 → アラート/ブロック
      ▼
   SIEMへ送出 or シグナル送信でプロセスをkill

ルールは「特定シスコール × 特定引数 × 特定コンテキスト」の組み合わせで書きます。例えば Falco のルールは次のような形を取ります。

- rule: コンテナ内でシェルが起動された
  desc: 通常ワークロードでは対話シェルは起動しないはず
  condition: >
    spawned_process and container and
    proc.name in (bash, sh, zsh) and
    not proc.pname in (allowed_parent_list)
  output: "シェル起動を検知 (user=%user.name container=%container.name cmd=%proc.cmdline)"
  priority: WARNING

コンテナ脱出の検知：namespace境界の越境をイベント系列として見る

コンテナはnamespaceとcgroupでホストから隔離された実行環境ですが、隔離は「見えなくする」だけで、カーネルは単一です。脱出攻撃の多くは、コンテナ内プロセスがホスト側の資源に到達するシスコール系列として観測できます。

代表的なパターンは次の通りです。

• 特権コンテナからのホストマウント操作。 mount() でホストのファイルシステム（例: /proc/self/root や cgroup 疑似ファイルシステム）を再マウントし、ホストの / へ書き込み可能なパスを得る。シスコール監視では「コンテナ内プロセスが mount を呼び、かつ対象がコンテナに割り当てられたoverlay層の外」という条件でマッチングできる。
• nsenter 相当の namespace 越境。 setns() でホストのnamespaceに参加する呼び出しは、通常ワークロードでは発生しない。この呼び出し自体を異常シグナルとして扱える。
• /proc 経由のホストプロセスへのアクセス。 ホストの /proc がコンテナにマウントされている設定ミスがあると、ホストPIDのプロセスへ ptrace や kill が届く。プロセスの実行namespaceとアクセス先PIDのnamespaceが不一致、という関係性そのものが検知条件になる。

Tetragon はプロセス系譜をカーネル内で追跡するため、「コンテナのentrypointから何段派生したプロセスか」「実行ファイルがイメージレイヤーに存在しない（=実行時に書き込まれた）か」といった系譜ベースの条件を高精度に評価できます。これはOCIランタイムがプロセスをどう起動するかを理解して初めて意味を持つ検知軸です。

プロセスインジェクションの検知：異常な親子関係とAPI呼び出し

プロセスインジェクション（他プロセスのメモリ空間にコードを注入し実行させる手法）は、Linuxでは主に ptrace(PTRACE_ATTACH/PTRACE_POKETEXT) や /proc/[pid]/mem への書き込み、あるいは LD_PRELOAD の悪用で行われます。これらは正規のデバッガ以外ではまれな操作なので、シスコール監視は次の観点で異常を捉えます。

• 呼び出し元プロセスの正当性。 ptrace を呼ぶプロセスが gdb や strace など既知のデバッグツール以外であれば、優先度を上げて警告する。
• メモリ書き込みを伴う /proc/[pid]/mem アクセス。 読み取り専用の監視ツールとは異なり、書き込みは実行コード変更の強いシグナル。
• 子プロセスの実行ファイルが親のイメージに含まれない。 コンテナイメージのレイヤーに存在しないバイナリが execve されるのは、攻撃者が持ち込んだペイロードである可能性が高い。

Falco と Tetragon の設計差：ユーザー空間評価 vs カーネル内評価

この違いは、eBPFのverifierが保証する安全性の範囲内で「判定ロジックをどこまでカーネルに寄せられるか」という設計思想の差です。カーネル内評価を増やすほどユーザー空間への転送量は減りますが、複雑な相関ルール（複数イベントの時系列パターンなど）はカーネル内では書きにくく、結局ユーザー空間側の状態保持が必要になります。

まとめ

• Falco・Tetragon は eBPF でシスコール発行点にフックし、プロセス系譜やファイル・ネットワークアクセスをストリームでルール評価するランタイムセキュリティであり、可観測性用途のeBPFとは目的が異なる（メトリクス再構成ではなく攻撃検知）。
• コンテナ脱出は「namespaceで隔離されたはずのプロセスがホスト資源に到達する」シスコール系列として、プロセスインジェクションは ptrace や /proc/[pid]/mem 書き込みといった異常な操作系列として検知できる。
• Tetragon はカーネル内フィルタリングでオーバーヘッドを抑えつつプロセス系譜ベースの精密な条件評価を行い、Falco はユーザー空間での柔軟なルール記述に強みがある。
• 実務の核心は検知ロジックの実装よりも、誤検知と見逃しのバランスをワークロードごとに調整し続けることにある。