現場の「勘」を科学する：ネットワークフォレンジックで紐解く異常通信の正体
深夜3時、データセンターの監視画面が真っ赤に染まる瞬間がある。スパイクするトラフィック、謎のレイテンシ、そして何の前触れもなく途絶えるAPIレスポンス。そんな時、教科書通りのマニュアルを読み返している暇はない。
「パケットは嘘をつかない」。これは私がNOCの最前線で学んだ唯一の真実だ。今日は、泥臭いトラブルシューティングの現場において、pingやtracerouteの先にある「パケット解析」と「フォレンジック」の世界を少しだけ深掘りしよう。
1. なぜ「生」のパケットを見る必要があるのか
curl -vで得られるHTTPレスポンスや、ss -ntで確認するコネクション状態は、いわば「結果」に過ぎない。インシデント調査において重要なのは、その裏で何が起きていたか、つまり「なぜその挙動になったのか」という文脈だ。
我々が現場で愛用するのは、tcpdumpで取得した.pcapファイルを起点にした「ホスト・セッション抽出」のアプローチだ。特に、パケットキャプチャからOSの推定やファイル復元を行う NetworkMiner のようなツールは、まさに現代のネットワークエンジニアにおける「鑑識官」の虫眼鏡といえる。
2. 現場で使えるCLIアプローチ：tcpdumpから解析まで
障害調査では、まず該当するインターフェースのトラフィックを確実にキャプチャし、それをローカル環境へ持ち帰るのが定石だ。
# 特定のAPIエンドポイント（例: 192.168.10.50）への通信のみを抽出して保存
# snaplen 0 はパケット全体を切り取るための重要設定
sudo tcpdump -i eth0 host 192.168.10.50 -w incident_log.pcap -s 0ここで取得した incident_log.pcap を解析する際、GUIのWiresharkも強力だが、自動化や大規模ログの調査には、CLIベースでセッション情報を整理する習慣をつけておこう。
3. NetworkMinerとCLI補助ツールの活用術
NetworkMiner は本来GUIツールだが、最近ではバックエンドの解析エンジンをCLIから呼び出し、特定のセッションからファイルや証明書を自動抽出するワークフローが主流だ。
例えば、攻撃者がAPI経由で何かをアップロードしている疑いがある場合、以下のようなPythonスクリプトで、特定のフロー（5-tuple）を抽出する前処理を行うことが多い。
# pysharkを用いたセッション抽出の自動化例
import pyshark
# キャプチャファイルを読み込み
cap = pyshark.FileCapture('incident_log.pcap', display_filter='http.request.method == "POST"')
for packet in cap:
# APIのペイロードやヘッダーを詳細に確認
# ここで不審なUser-AgentやContent-Typeを特定する
print(f"Timestamp: {packet.sniff_time}")
print(f"Source: {packet.ip.src} -> Dest: {packet.ip.dst}")
if hasattr(packet, 'http'):
print(f"User-Agent: {packet.http.user_agent}")4. フォレンジック的アプローチ：OS推定の仕組み
なぜ、パケットを見るだけで「OS」がわかるのか？ それは TCP/IP スタックの実装がOSごとに微妙に異なるからだ。
- TCP Window Size: OSのバージョンによってデフォルト値が異なる。
- TTL (Time to Live): Linuxの
64や Windowsの128といった定数の違い。 - TCP Options:
SACKやWindow Scalingの並び順や有無。
これらを NetworkMiner や解析エンジンは統計的に処理し、「このパケットはUbuntu 22.04から出ている可能性が高い」といった推論を行う。APIの異常なリクエストが「正規のブラウザ」なのか「攻撃用のスクリプト」なのか、この推論が分かれば対策は一瞬だ。
5. 現場のシニアからのアドバイス
トラブルシューティングで最も陥りやすい罠は、「自分の仮説に都合の良いパケットだけを探してしまうこと」だ。
1. まずはベースラインを知る: 正常時のパケット構成（ヘッダーのサイズ、シーケンス番号の進み方）を日頃から見ておくこと。
2. シーケンスを追う: SYN -> SYN/ACK -> ACK のハンドシェイクがどこで詰まっているのか（あるいは RST で切断されているのか）を ss コマンドで確認してからパケットに潜る。
3. ツールはあくまで道具: NetworkMiner や pyshark が出した結論を鵜呑みにせず、必ずその根拠となる TCP Flag や Payload を自分の目で確認する癖をつける。
ネットワーク運用とは、ある種の職人芸だ。しかし、その根底には厳格なRFCの仕様と、それを実装したOSの個性が流れている。CLIツールを使いこなし、パケットの「呼吸」を感じられるようになれば、どんなに複雑な障害も必ず解決の糸口は見つかるはずだ。
さあ、次は君たちの手で、そのパケットの正体を暴いてみてくれ。現場からは以上だ。
コメント