ネットワークフォレンジック入門｜インシデント後のパケット証跡解析と証拠保全を情シスが実践する手順ガイド

インシデントが疑われたとき、「サーバーが攻撃されたかもしれない」という第一報だけでは何も始まりません。攻撃者が侵入した経路、操作した内容、外部へ送り出したデータ——これらを後から証明するには、ネットワーク上に残された通信の痕跡が必要です。

しかし多くの中小企業では、パケットキャプチャすら設定されておらず、インシデントが起きてはじめて「ログが足りない」と気づきます。ネットワークフォレンジックの基本を理解し、日常から証拠を残せる環境を整えておくことが、インシデント対応の質を大きく左右します。

この記事では、ネットワークフォレンジックの概要から、情シスが実践できるパケット証跡の保全・収集・解析・タイムライン再構築の手順まで、現場で使えるレベルで解説します。

ネットワークフォレンジックとは？

ネットワークフォレンジックとは、セキュリティインシデント後にネットワーク上の通信データ（パケット、フローデータ、各種ログ）を収集・解析し、「何が起きたか」「どこまで被害が及んだか」を技術的に明らかにする手法です。

デジタルフォレンジックがPCやサーバーのディスク・メモリ上の証拠を対象とするのに対し、ネットワークフォレンジックは通信の流れそのものを対象とします。両者は相補的な関係にあり、本格的なインシデント調査では組み合わせて使われます。

ネットワークフォレンジックが重要な理由は3点あります。

・攻撃の侵入経路を特定できる: どのIPアドレスからいつ接続があったかを証明できます
・データ漏洩の有無を確認できる: 外部への異常な大量転送や暗号化通信を追跡できます
・法的証拠として使える: 正しく保全されたネットワークログは被害届や民事訴訟の証拠になります（詳細は法律の専門家にご確認ください）

ネットワーク上に残る攻撃の痕跡

攻撃者はネットワークを通じて侵入・操作・データ持ち出しを行います。その過程で必ず何らかの通信が発生し、以下のようなデータとして残ります。

1. パケットキャプチャデータ

ネットワーク上を流れるパケットをそのまま保存したものです。tcpdumpやWiresharkで収集でき、通信内容をバイト単位で再現できる最も詳細な証拠です。ただしデータ量が膨大になるため、常時全キャプチャは現実的でない場合もあります。重要セグメントのみに絞るか、リングバッファ（一定期間分だけ循環保持）での運用が一般的です。

2. フローデータ（NetFlow・sFlow）

パケットの中身は含まず、「いつ・どのIPから・どのポートへ・どのくらいのデータ量を送ったか」という通信の統計情報です。パケットキャプチャより遥かに軽量で長期保存に向いており、異常な通信量やC2（指令・制御）通信の検知に有効です。

3. ファイアウォール・プロキシのログ

境界機器のログは、外部からの接続試行や内部から外部へのアクセスの記録を含みます。ファイアウォールのDENYログには攻撃者のスキャン・ポートフォワーディング試行が残ります。プロキシログには、マルウェアのC2通信がHTTP/HTTPSとして記録されることがあります。

4. DNSクエリログ

悪意のあるドメインへの名前解決は、マルウェア感染の初期段階で必ず発生します。DNSクエリのログを保持していれば、感染端末と悪意ドメインの紐付けが可能になります。

5. DHCPログ・ARPテーブル

「MACアドレス・IPアドレス・タイムスタンプ」の対応を記録しており、「あのIPアドレスを使っていたのはどの端末か」を特定できます。インシデント後に侵害されたIPを端末に紐付ける際に欠かせないデータです。

調査に使う主なツール

1. tcpdump・Wireshark（パケット収集と解析）

tcpdumpはLinuxサーバーやネットワーク機器でパケットをファイルに保存するCLIツールです。調査対象の端末や境界サーバーに設定しておき、インシデント時に回収します。

# インターフェースのトラフィックをリングバッファで保存（100MB×5ファイル循環）
tcpdump -i eth0 -w /var/log/capture/traffic.pcap -C 100 -W 5

# ポート443の通信のみ保存
tcpdump -i eth0 port 443 -w /var/log/capture/https.pcap

保存した.pcapファイルはWiresharkでGUI解析できます。「フォローTCPストリーム」機能で特定のセッション全体を可視化でき、攻撃者の操作内容の追跡に有効です。

2. Zeekによる自動ログ生成

Zeek（ゼーク）はパケットを自動解析してconn.log（接続記録）・dns.log・http.log・ssl.logなどの構造化ログを生成します。フォレンジック調査では検索・集計・タイムライン整理に非常に便利で、パケットの生データより分析しやすく保存容量も抑えられます。

3. ファイアウォール・UTMのログエクスポート

境界機器のログは、定期的に外部のsyslogサーバーへ転送しておきます。インシデント後に機器自体が侵害されてもログが消えない構成にしておくことが重要です。共通して押さえるべきデータはDENYログ・NATセッションテーブル・接続タイムアウト記録です。

ネットワークフォレンジックの実践4ステップ

セキュリティインシデント発生後、ネットワークフォレンジックは次の4ステップで進めます。

1. 証拠保全（タイムスタンプ・ハッシュ値の記録）

最初に行うのは証拠の改ざん防止です。ログファイルをコピーしたら、必ずハッシュ値（SHA-256）を記録します。これにより「収集後に内容を変更していない」ことを証明できます。

# ファイルのハッシュ値を記録する
sha256sum /var/log/capture/traffic.pcap > traffic.pcap.sha256

# 後からハッシュ値を検証する
sha256sum -c traffic.pcap.sha256

また、システムクロックの正確さも重要です。ログのタイムスタンプがNTPで同期されているか確認しておきます。複数ノードのログを突き合わせる際に時刻がずれていると、誤った結論に至ることがあります。

2. ログ・パケットの収集と保護

調査に必要なデータを一か所に集め、書き込み禁止の媒体または権限で保護したディレクトリに保存します。収集対象は以下です。

・パケットキャプチャファイル（.pcap）: 事前に設定していた場合は即時回収
・ファイアウォール・UTMのログ: インシデント前後72時間分を優先
・DNSクエリログ・DHCPログ: 感染端末のIPとMACアドレスを特定するために必要
・ルーターのARP・MACアドレステーブル: 侵害時点のスナップショットをすぐ取得
・フローデータ（NetFlow/sFlow）: C2通信の特定に有効

3. 異常通信パターンの特定

収集したデータを解析し、通常とは異なるパターンを探します。着目点は以下です。

・深夜帯の大量アウトバウンド通信: データ漏洩（exfiltration）の典型的なパターン
・一定間隔のBeaconing通信: マルウェアが定期的にC2サーバーへ生存確認を送る動作
・内部から内部へのスキャン: ラテラルムーブメント（横移動）の兆候
・通常ポート以外のHTTPS通信: DNSトンネリングやポート偽装の可能性
・短時間での大量ログイン失敗: 同一IPからのブルートフォース試行

（想定例として）ファイアウォールログで「深夜2時に社内の1端末から海外IPの443ポートへ5分間隔で小さな通信が繰り返されている」というパターンが見つかった場合、Beaconingの疑いが高いと判断できます。この場合、該当端末のDHCPログからMACアドレスを割り出し、資産台帳と照合して端末を特定するという流れになります。

4. 攻撃タイムラインの再構築

各ログのタイムスタンプを時系列に並べ、「侵入→内部拡散→データ持ち出し→発覚」の流れを図示します。複数のログソースを突き合わせることで、攻撃者が辿ったルートを可視化できます。

※上記は説明のための想定例です。実際の調査では各証拠の整合性を複数ソースで確認します。

中小企業でも今日からできること

本格的なパケットキャプチャ基盤がなくても、以下の備えから始めることができます。

・FWのDENYログをsyslogサーバーへ転送する: 機器内だけでなく外部への転送設定は最低限やっておくべき対策です
・DNSクエリログを有効化する: WindowsのDNSサーバー役割やLinuxのunbound・bindでクエリロギングを有効にします
・DHCPログの保存期間を延ばす: デフォルト設定では数日分しか残らない場合があります。最低30日分は確保します
・NTP同期を全機器に設定する: ログのタイムスタンプがずれると複数機器のログを突き合わせられません
・ARPテーブルの定期スナップショットを取る: cronなどで週1回保存しておくだけで端末特定に使えます

Linuxサーバーのログ管理については、姉妹サイトLinuxMaster.JPでも詳しく解説しています。

よくある誤解と注意点

【誤解1】「暗号化されているから通信の中身は調べられない」

TLS暗号化されていても、「いつ・どのIPと・どのくらいの量の通信をしたか」というメタデータはフローデータやFWログで確認できます。また、SNI（Server Name Indication）拡張では接続先ドメイン名が暗号化前に送信されるため、C2通信の宛先特定に利用できます。

【誤解2】「インシデント後にログを集めればいい」

ルーターやL2スイッチのARPテーブルは揮発性が高く、再起動や時間経過で消えます。一般に、ログは保存期間を超えると上書きされます。事前にログ転送・長期保存設定をしておかない限り、後からデータを集めることはできません。

【誤解3】「専門業者に依頼すれば全部わかる」

外部のインシデントレスポンス会社に依頼しても、証拠が残っていなければ調査はできません。初動の証拠保全は情シスが行わなければならず、機器の電源断やログの上書きなどの初動ミスは取り返しがつきません。

本記事のまとめ

ネットワークフォレンジックは、高価な専用製品がなくても、無料ツールと日常的なログ管理の習慣で相当な調査能力を確保できます。「インシデントは起きるもの」という前提で、今できる範囲から証拠を残す環境を整えておきましょう。