トラブルシューティングのコンテキストを失わずに大規模な PCAP を分割し、1 つの会話を抽出する

大きな PCAP ファイルは、開くのも共有するのもレビューするのも困難です。負荷の高いサーバー、カメラ ゲートウェイ、USB-over-IP ラボ、または実稼働インシデントからのキャプチャは、すぐにギガバイトに増加する可能性があります。明らかな解決策は、ファイルを分割するか、1 つの会話を抽出することです。リスクは、失敗を説明するコンテキストが切り取られることです。

正しい質問は、「PCAP をどのように小さくするか?」だけではありません。それは、「より小さなキャプチャが依然として有用であるためには、どのようなコンテキストが存続する必要があるか?」ということです。

大規模なキャプチャが使いにくくなる理由

大規模なキャプチャでは実際的な問題が発生します。

• パケットアナライザーのメモリプレッシャー
• インデックス作成が遅い
• サポートポータルへのアップロードが難しい
• 機密性の高い無関係なトラフィック
• 会話が多すぎる
• 長い期間
• 実際の事件の周囲に重複したノイズが存在する

サイズごとに分割すると、ファイルを管理しやすくなります。会話を抽出すると、証拠に焦点を当てることができます。ただし、どちらの操作でも、重要なセットアップ、DNS、ARP、TLS、または再送信コンテキストが隠蔽される可能性があります。

会話を抽出するには 5 つ以上のタプルが必要です

TCP または UDP 会話は、多くの場合、送信元 IP、宛先 IP、ポート、およびプロトコルによって識別されます。それは良いスタートです。ただし、トラブルシューティングには次のことも必要になる場合があります。

• 接続前のDNSルックアップ
• ARP または近隣探索
• TCPハンドシェイク
• TLSハンドシェイク
• ICMPエラー
• 目に見える障害が発生する前の再送信
• 関連する制御チャネル
• クライアントの再試行後のサーバーの応答

アプリケーションエラー後のパケットのみを抽出すると、受信者が本当の原因を見逃してしまう可能性があります。

サイズによる分割と時間による分割

ファイル サイズによる分割は、ツールの互換性とアップロード制限に役立ちます。時間による分割は、インシデント ウィンドウに役立ちます。会話による分割は、集中的なデバッグに役立ちます。それぞれにトレードオフがあります。

聞く：

• 受信ツールにファイルサイズ制限はありますか?
• インシデントの時間枠は重要ですか?
• 1 つのフローがケース全体を表すのでしょうか?
• 複数の関連するフローが必要ですか?
• タイムスタンプはオリジナルのままにする必要がありますか?
• パケット番号は保存すべきか、それとも再マッピングすべきか?

出力には、どの分割戦略が使用されたかを文書化する必要があります。

元のパケットの証拠を保存する

より小さいファイルを生成する場合は、元のキャプチャをそのままにしておきます。派生キャプチャは再現可能である必要があります。後でサポート チームが抽出されたウィンドウより前のパケットを要求した場合、元のパケットがまだ存在している必要があります。

有用なメタデータ:

• 元のファイル名とハッシュ
• 分割または抽出フィルター
• タイムウィンドウ
• 前後のパケット数
• 会話も含まれる
• 設計によりドロップされるパケット
• 出力ファイルのハッシュ

これにより、「ファイルを切り取った」という行為が防御可能な操作に変わります。

PCAP 手術が適している場所

PCAP 手術は、証拠のレビューと管理された編集のために設計されています。大規模なキャプチャの処理もその一部です。最初に検査し、次に最小限の出力を選択し、三番目に操作を文書化します。

大規模な PCAP ワークフローの場合、PCAP Surgery は次の答えに役立ちます。

• どのような会話が存在しますか？
• どのフローに障害が含まれているか?
• それを取り巻くコンテキストはどれだけあるでしょうか？
• 何が抽出されたのですか？
• 意図的に除外されたものは何ですか？
• 派生キャプチャは再生成できますか?

検索クエリが「大きな pcap を分割」または「pcap から tcp 会話を抽出」である場合は、ファイル サイズのみを最適化しないでください。失敗を説明できる小さなキャプチャを最適化します。