こんにちは！インシデントレスポンスの現場を渡り歩いているSOCアナリストです。日々のセキュリティ調査では、目に見えないサイバー攻撃の痕跡を一つひとつ暴いていく作業を行っています。
さて、最近のインフラの主役といえば「コンテナ」ですよね。DockerやKubernetesを使ってアプリケーションを手軽に動かせるのは本当に便利です。でも、「コンテナの中でこっそり怪しいプログラムが動き出し、外の悪い奴ら（C2サーバー：Command and Controlサーバー）とこっそり通信していた！」なんて想像したことはありませんか？
今回は、そんな見えない脅威を暴くための技術「コンテナのメモリダンプからネットワーク接続情報を復元する方法」について、現場のリアルな視点を交えながら、一歩ずつ優しく紐解いていきたいと思います。
—
1. 家の鍵と防犯に例える「コンテナの通信」
セキュリティの難しい話に入る前に、私たちの身近な「おうちの防犯」に例えて考えてみましょう。
コンテナというのは、言わば「アパートの一室」のようなものです。その部屋の中ではあなたのお気に入りのアプリ（住人）が暮らしています。通常、外とやり取りするときは、玄関のドア（ネットワークポート）を通って宅配便を受け取ったりしますよね。
しかし、もし悪意ある泥棒（マルウェア）が部屋に侵入してしまったらどうなるでしょうか？
泥棒は、警察やあなたに見つからないように、裏口の窓からコソコソと外の仲間（C2サーバー）に連絡を取り、「この家にはこんなお宝があったよ！」と報告を始めます。
玄関の防犯カメラ（一般的なファイアウォールログ）だけを見ていると、「お、今日も普通に宅配便が来ているな」と見過ごしてしまうかもしれません。しかし、部屋の中の様子（メモリ）を直接覗き込むことができたらどうでしょう？
「あれ？ 住民が寝静まっている深夜に、裏口から見知らぬ番号へ電話をかけている痕跡があるぞ！」と気づくことができますよね。
メモリフォレンジックとは、まさにこの「部屋の中をくまなく調べて、泥棒がこっそり使っていた電話の履歴を見つけ出す作業」なのです。
—
2. なぜコンテナのネットワーク調査は難しいのか？
通常の物理サーバーや仮想マシンであれば、ネットワークの調査は比較的簡単です。OSが持っている netstat や ss といったコマンドを使えば、「今、どこボトムとつながっているか」が一目瞭然だからです。
しかし、コンテナの世界では話が変わってきます。
コンテナは非常に軽量に作られているため、トラブルが起きたときに調査用の便利なツール（例えば netstat など）が入っていないことがよくあります。さらに、攻撃者が侵入した後に、そうした足跡を消すためにツール自体をこっそり改ざんしてしまうことすらあります。
だからこそ、「コンテナが動いていた瞬間のメモリ（脳みそ）のコピー」をまるごと抜き取り、その中に残された「ソケット構造体」という通信の足跡を直接解析する技術が必要になるのです。
—
3. メモリから通信の足跡を探し出す仕組み
Linuxのカーネル内では、ネットワークの接続情報は「ソケット（Socket）」と呼ばれるデータ構造として管理されています。これは、人間でいう「通話履歴のメモ帳」のようなものです。
たとえ攻撃者がコンテナ内のコマンドを消して隠蔽したとしても、OSのメモリの奥底には、このメモ帳の切れ端や過去の通話記録がこっそり残されていることがよくあります。
私たちアナリストは、専用の解析ツールを使ってメモリの隅々をスキャンし、このソケット構造体を見つけ出します。そして、そこから以下の情報を復元します。
- どのIPアドレス（C2サーバー）と通信していたか
- どのポート番号を使っていたか
- 通信を行っていたプロセスの名前やID（PID）
—
4. 実践：メモリ解析のコードとアプローチ
ここからは、実際に私たちが現場でどのようにメモリからネットワーク情報を炙り出しているのか、そのアプローチをコード例を交えて見ていきましょう。
今回は、オープンソースのメモリフォレンジックフレームワークである Volatility 3 を使った解析をイメージしてみます。
ボラティリティを使ったプロセスとネットワーク情報の紐付け
コンテナのメモリダンプ（例えば container_mem.raw）が手元にあると仮定します。以下のPythonスクリプトやコマンドの概念図を参考にしてください。
# 模擬的な解析スクリプトの流れ（Volatility 3 のAPI概念）
import volatility3.framework.interfaces.plugins as plugins
class ContainerNetworkAnalysis:
def __init__(self, context, layer_name):
self.context = context
self.layer_name = layer_name
def find_suspicious_sockets(self):
"""
メモリ上のネットワークソケットを走査し、
外部の不審なIPアドレスへの接続がないかチェックするサンプルロジック
"""
print("[+] メモリダンプからネットワークソケットの走査を開始します...")
# 実際にはここでカーネルのnetstatプラグインや
# ソケット構造体のリスト（tcp_hashinfoなど）をトラバースします。
mock_sockets = [
{"pid": 1042, "process": "nginx", "local": "172.17.0.2:80", "remote": "192.168.1.50:443", "state": "ESTABLISHED"},
{"pid": 2401, "process": "unknown_bin", "local": "172.17.0.2:45122", "remote": "203.0.113.66:6666", "state": "ESTABLISHED"} # ⚠️怪しい通信！
]
for sock in mock_sockets:
# 外部の怪しいC2サーバー（例として既知の不審なIPレンジや高ポート）を検知
if "203.0.113." in sock["remote"]:
print(f"[!] 警告: 不審な外部接続を検出しました！")
print(f" - プロセス名: {sock['process']} (PID: {sock['pid']})")
print(f" - 接続先: {sock['remote']}")
print(f" - 状態: {sock['state']}")
# 実行シミュレーション
if __name__ == "__main__":
analyzer = ContainerNetworkAnalysis(None, "virtual_layer")
analyzer.find_suspicious_sockets()このように、メモリダンプを解析することで、通常は見えなくなっていたプロセス名と通信先のペアをきれいにあぶり出すことができます。上記のサンプルでは、unknown_bin という怪しいプロセスが 203.0.113.66 という外部の怪しいIPアドレスとつながっているのが一目瞭然ですね。
—
5. 現場からのアドバイス：一歩ずつ対策を学んでいきましょう！
「メモリダンプの解析」と聞くと、なんだか映画のハッカーのようで難しそうに感じるかもしれませんが、恐れる必要はありません。セキュリティの世界は、基本の積み重ねです。
普段の開発やインフラ構築の現場では、以下のポイントを意識するだけでも、こうしたインシデントのリスクをグッと減らすことができます。
1. 不要なツールをコンテナに入れない（ミニマムイメージの徹底）
- コンテナの中にシェルやデバッグツールを残さないことで、攻撃者が侵入したあとに暴れる足場を奪うことができます。
2. ネットワークの出口を絞る（Egressフィルタリング）
- コンテナが勝手に外部のよくわからないサーバーと通信できないよう、ファイアウォールで通信先を厳しく制限しておきましょう。これだけでC2サーバーへの連絡網を断つことができます。
3. 定期的なログ監視と異常検知
- 「いつもと違う動き」にいち早く気づけるよう、ホスト側のネットワークログやメトリクスを監視する習慣をつけましょう。
インシデントはいつ自分の身に降りかかるかわかりませんが、仕組みを正しく理解し、一つひとつの対策を丁寧に行っていけば、必ず脅威からシステムを守り抜くことができます。
それでは、また次回のセキュリティ解説でお会いしましょう！安全な開発ライフを！
コメント