K8sノードが「沈黙」した時、君はメモリの中に何を見るか？
現場でインシデント対応をしていると、よくこんな相談を受ける。「Kubernetesのコンテナが勝手に外部通信を始めたみたいなんだけど、ログを見ても何も分からないんだ」。
攻撃者は賢い。彼らはディスクに痕跡を残さず、メモリ空間だけで完結するファイルレス攻撃を好む。特にK8sノードが侵害された場合、ホストOSレベルでのメモリダンプこそが、真実を語る最後の砦だ。今日は、教科書には載っていない、現場の泥臭いフォレンジックの勘所を伝授しよう。
—
1. コンテナの境界を越える「メモリダンプ」のリアリティ
K8sノードが乗っ取られた時、真っ先に確認すべきは kubelet の挙動と、ノード上で動いているプロセスのメモリ状態だ。攻撃者は往々にして、コンテナのランタイム（containerdなど）を悪用し、特権コンテナ経由でホストの /proc を覗き見ている。
なぜメモリダンプなのか
ログは改ざんできる。しかし、実行中のプロセスがメモリ上に展開している「悪意あるバイナリ」や「暗号化されたC2通信のセッションキー」は、メモリダンプを解析しない限り見えてこない。
ノードレベルで LiME や AVML を使ってダンプを取得する際、注意すべきは「証拠の汚染」だ。解析ツールを動かすこと自体がメモリ状態を変化させる。だからこそ、現場では「最小限のツール」で「最大の情報」を抜く技術が求められる。
—
2. 攻撃経路の特定：kubeletログとメモリの突き合わせ
攻撃者はよく kubelet の認証バイパスや、特権を持つサービスアカウントトークンを狙う。例えば、/var/lib/kubelet/pods/ 直下のシークレットがメモリ上にマッピングされている瞬間を狙い、そのトークンを盗み出す手法だ。
突き合わせの鉄則
1. kubeletログの精査: /var/log/kubelet.log で、心当たりのない exec コマンドや、意図しないコンテナへのアタッチが発生していないか確認する。
2. メモリ解析: Volatility を使用し、怪しいPIDの vaddrs をダンプして、そこに kubectl や curl の実行バイナリ、あるいは不審なシェルコードがロードされていないかを確認する。
—
3. 実践：攻撃を防ぐための「防御的コーディングと設定」
インシデント発生後に慌てないための、最も重要な防御策は「攻撃の足がかりを消すこと」だ。特にWebアプリケーション側で「OSコマンドインジェクション」を許すと、そこからノードの特権昇格へ直結する。
Pythonによる安全なコマンド実行の実装
os.system() や shell=True を使ったPythonコードは即刻廃止すべきだ。以下は、バリデーションを厳格化した実装例である。
import subprocess
import shlex
def secure_command_execution(user_input):
# ホワイトリストによる入力検証（これだけで防御の8割が決まる）
allowed_commands = ["status", "version"]
if user_input not in allowed_commands:
raise ValueError("不正な入力です。")
# shell=Trueは絶対に使わない。shlexで安全に引数を分割する
safe_cmd = ["/usr/bin/my-app-tool", shlex.quote(user_input)]
# 外部プロセスを呼び出す際はタイムアウトを設ける（DoS対策）
try:
result = subprocess.run(safe_cmd, capture_output=True, text=True, timeout=5)
return result.stdout
except subprocess.TimeoutExpired:
return "処理がタイムアウトしました。"NginxでのWAF的防御（Podへの侵入を阻む）
KubernetesのIngress Controller（Nginx等）で、不審なリクエストを事前に弾く設定を入れておくことが、メモリダンプを解析する手間を省く一番の近道だ。
# Nginx IngressのConfigMapに追加すべき防御設定
location / {
# 悪意のある文字列（../ や /proc/ など）を含むリクエストを拒否
if ($request_uri ~* "(\.\./|/proc/|/etc/passwd)") {
return 403;
}
# HTTPメソッドの制限
limit_except GET POST {
deny all;
}
}—
4. 最後に：現場のアナリストへ
メモリフォレンジックは、まるで迷宮の地図を書き写す作業だ。攻撃者は常に新しい「隠れ場所」を探している。君たちが日々書くコードの1行が、脆弱なシステムを作るか、あるいは鉄壁の要塞を作るかを決める。
特にK8s環境では、「Podは使い捨てである」という前提を忘れないこと。 侵害されたPodを無理に解析しようとせず、メモリダンプを素早く取得したら、即座にPodをKillし、新しいクリーンなコンテナでリプレースする。その上で、ダンプしたメモリをオフライン環境でじっくり解析する。これが、今の時代に求められる最も「泥臭く、かつプロフェッショナルな」インシデントハンドリングだ。
システムが沈黙した時、慌てず騒がず Volatility を叩けるエンジニアになってくれ。それが、次の被害を防ぐ唯一の道だからな。
コメント