カーネルレベルの死角を排除する
以前、1時間に15,000回ものSSHブルートフォース攻撃に耐えるサーバーを見たことがあります。ファイアウォールでそれらのIPをブロックすることはできますが、それは境界線での対処に過ぎません。もし攻撃者がWebアプリのゼロデイ脆弱性を突いたり、設定ミスのコンテナからエスケープしたりした場合、従来のログは被害が不可逆的になるまで沈黙を守ることが多いのです。それは単に「干し草の山から針を探す」ようなものではありません。現在進行形で干し草の山を焼き払っている針を探しているようなものです。
auditdやsyslogのようなレガシーなツールは、根本的に「リアクティブ（反応的）」です。これらは攻撃を防ぐのではなく、攻撃の「検死報告」を記録するに過ぎません。Kubernetesのような高密度な環境では、カーネルが何を行っているかをリアルタイムで把握する必要があります。最初のシステムコールが完了する前に、悪意のあるプロセスを強制終了させる能力が必要です。これが、eBPFとTetragonがランタイムセキュリティの新しい標準になりつつある理由です。
課題：検出とアクションの間のタイムラグ
多くのセキュリティスタックはユーザースペースの監視に依存しています。プロセスが悪意のあるスクリプトを実行すると、OSがログを生成します。SIEMがそのエントリを解析し、エンジニアに通知する頃には、攻撃者はすでに.envファイルを外部に送信したり、データベースを暗号化したりしています。自動化されたエクスプロイトの世界では、5分間の遅延は永遠にも等しい時間です。
パフォーマンスオーバーヘッドの現実
従来の監視では、セキュリティと速度のトレードオフを強いられることがよくあります。
- CPU負荷:
auditdのようなツールは、カーネルとユーザースペース間の頻繁なコンテキストスイッチにより、高トラフィックなシステムでCPU使用率を20%から30%も急増させることがあります。 - 受動的な防御: ほとんどの監視ツールは、介入ではなく監視を目的として設計されています。プロセスが
/etc/shadowにアクセスしようとするそのマイクロ秒の瞬間に, プロセスを止めることはできません。
選択肢の比較：従来型 vs eBPF型セキュリティ
Tetragonはロジックをユーザースペースからカーネルへ直接移行させます。以下は、従来のメソドロジーとの比較です。
| 機能 | Auditd / Syslog | Falco (標準) | Tetragon (eBPF) |
|---|---|---|---|
| メカニズム | システムコールの監査 | カーネルモジュール / eBPF | 純粋なeBPF |
| パフォーマンス | 低（重いコンテキストスイッチ） | 中 | 高（カーネルネイティブ） |
| リアルタイムブロック | 不可 | 限定的（サイドカー経由） | 可能（カーネル内での強制実行） |
| 粒度 | プロセスレベル | システムコールレベル | 関数レベル（ディープカーネル） |
なぜTetragonなのか？（そして弱点はどこか）
メリット
- ゼロレイテンシの強制実行: セキュリティロジックがカーネル内に存在するため、Tetragonはアクションが完了する前にそれを停止させることができます。
- 豊富なコンテキスト: 単にプロセスIDを表示するだけでなく、イベントをKubernetesのPod、ネームスペース、バイナリのメタデータに関連付けます。
- 即時の緩和策: ポリシーに違反した瞬間にプロセスを終了させる「SIGKILL」を送信するように設定できます。
トレードオフ
- モダンなカーネルが必要: Linuxカーネル5.4以降が必要です。関数レベルの強制実行などの高度な機能には、5.10以降が必須となります。
- 学習曲線:
TracingPoliciesを構築するには、Linuxがシステムコールやカーネル関数をどのように処理するかを理解する必要があります。
推奨セットアップ
本番環境では、TetragonをKubernetesのDaemonSetとして実行することをお勧めします。スタンドアロンサーバーの場合は、systemdサービスが最適です。このガイドではコンテナ化されたアプローチを使用します。これは、ホストOSを汚さずにツールの動作を確認する最速の方法です。
前提条件
- Linuxマシン（Ubuntu 22.04など）。
- Dockerがインストールされていること。
- BTF (BPF Type Format) のサポート（モダンなカーネルでは標準です。
ls /sys/kernel/btfで確認してください）。
ステップバイステップの導入手順
1. Tetragonの起動
まず、Tetragonコンテナを実行します。ホストカーネルにフックするため、特権アクセス（privileged）が必要です。
docker run --name tetragon --rm \
--privileged -v /sys/kernel/debug:/sys/kernel/debug \
-v /proc:/proc -v /etc/os-release:/etc/os-release \
quay.io/cilium/tetragon:v1.0.02つ目のターミナルを開き、発生するイベントをリアルタイムで監視します。
docker exec tetragon tetra logs2. ファイル整合性ポリシーの作成
/etc/shadowを読み取ろうとする試みをキャッチしましょう。このファイルにはパスワードハッシュが含まれており、攻撃者の主要な標的となります。TracingPolicyを使用して、sys_openatシステムコールを監視します。
これをmonitor-shadow.yamlとして保存します：
apiVersion: cilium.io/v1alpha1
kind: TracingPolicy
metadata:
name: "monitor-etc-shadow"
spec:
kprobes:
- call: "sys_openat"
syscall: true
args:
- index: 1
type: "string"
selectors:
- matchArgs:
- index: 1
operator: "Equal"
values:
- "/etc/shadow"
actions:
- action: Postこれを適用した後、sudo cat /etc/shadowを実行してみてください。Tetragonは即座にイベントをログに記録し、ユーザーや実行された正確なコマンドを表示します。
3. 「キルスイッチ」を有効にする
ここからが面白くなるところです。単にイベントをログに記録するのではなく、攻撃者がnmapのような許可されていないツールを実行するのを阻止しましょう。プロセスが開始される前にSIGKILLを送信するようにカーネルに指示できます。
block-nmap.yamlを作成します：
apiVersion: cilium.io/v1alpha1
kind: TracingPolicy
metadata:
name: "block-nmap-execution"
spec:
kprobes:
- call: "sys_execve"
syscall: true
args:
- index: 0
type: "string"
selectors:
- matchArgs:
- index: 0
operator: "Equal"
values:
- "/usr/bin/nmap"
actions:
- action: Sigkill攻撃者がnmapをダウンロードして実行しようとしても、プロセスは即座に終了します。ターミナルにはぶっきらぼうな「Killed（強制終了）」というメッセージが表示され、ネットワークスキャンは阻止されます。
データの確認
進行中のインシデントの際、生のJSONログを読むのは困難です。tetra CLIツールを使用して、クリーンで人間が読みやすいプロセスツリーを取得しましょう。
docker exec tetragon tetra getevents -o compactこれにより、PROCESS START（プロセス開始）、FILE OPEN（ファイルオープン）、SIGKILLといったイベントの明確なタイムラインが得られます。これにより、攻撃のライフサイクル全体を数秒で再構築できます。
最後に
現代のセキュリティは、単に高い壁を築くことだけではありません。その壁の内側を完全に可視化することが重要です。eBPFを使用して防御をカーネルに移行することで、攻撃者が依存しているレイテンシ（遅延）を排除できます。深夜のSSH攻撃を経験した後、私はリアクティブなログ記録だけでは不十分だと悟りました。悪意のあるプロセスをリアルタイムで強制終了できるパワーを持つことは、夜に安心して眠れるセキュリティを提供してくれます。
まずは最も機密性の高いディレクトリの監視から始めてみてください。構文に慣れたら、リスクの高いバイナリに対するアクティブなブロックへと進みましょう。これは、システムの障害をただ見守るだけの状態から、積極的にシステムを守る状態への大きな転換となります。
