PCAP ファイルの匿名化と無害化: 証拠を破壊せずに機密データを削除

パケット キャプチャは、多くの場合、生で共有するには機密性が高すぎるためです。これらには、IP アドレス、ホスト名、MAC アドレス、Cookie、HTTP ペイロード、ユーザー名、DNS 名、電子メール アドレス、SMB パス、独自のプロトコル、顧客データが含まれる場合があります。同時に、キャプチャはプロトコルの障害をデバッグするために必要な唯一の証拠である可能性があります。

PCAP サニタイズの目的は、ファイルを美しくすることではありません。目標は、技術的な質問に答えるのに十分な証拠を保存しながら、機密データを削除または変換することです。

受信者が何を必要としているかを決定する

PCAP を匿名化する前に、受信者が何を診断する必要があるかを尋ねてください。

• TCP ハンドシェイクと再送信の動作
• DNS解決
• TLS タイミング
• HTTPステータスコード
• アプリケーションのペイロードの内容
• IPルーティング
• エンドポイントのアイデンティティ
• パケットのサイズとタイミング
• プロトコルパーサーの失敗

受信者がトランスポート タイミングのみを必要とする場合は、ペイロード スライスで十分な場合があります。 HTTP ヘッダーが必要な場合、すべてのペイロード バイトを削除するとケースが破壊される可能性があります。エンドポイントの役割が必要な場合、安定したマッピングを行わずにすべてのアドレスを完全にランダム化すると、フロー分析が不可能になる可能性があります。

サニタイズはツールの問題だけではなく、要件の問題でもあります。

一般的な消毒戦略

実践的なアプローチには次のようなものがあります。

• 固定オフセット後のパケット ペイロードを削除します
• アプリケーションデータを切り詰めますが、ヘッダーは保持します
• 安定したマッピングで IP アドレスを匿名化する
• MACアドレスを匿名化する
• DNS名を削除する
• HTTPヘッダーを編集する
• TLS シークレットまたはキー ログ参照を削除する
• 関連する会話のみを分割する
• 編集後にチェックサムを再計算する

各戦略は証拠を異なる方法で変更します。多くの場合、パケット スライシングはプライバシーにとってより安全ですが、アプリケーション層の障害を診断するために必要な正確なバイトが削除される可能性があります。

タイミングとフロー構造の維持

高度にサニタイズされたキャプチャでも、以下が保存されていれば引き続き有用です。

• パケットの順序
• タイムスタンプまたは相対的なタイミング
• TCP シーケンスの動作
• 適切な場合のパケット長
• directionality
• 会話のグループ化
• 再送とACKパターン

多くのネットワークのケースでは、ペイロードの内容よりもタイミングとシーケンスの証拠が重要です。ただし、パケットの長さ自体が重要な場合は、それも考慮する必要があります。

何が変わったかを記録する

無害化されたキャプチャは、生の証拠であるかのように見せるべきではありません。レポートには次のように記載する必要があります。

• 元のファイルのハッシュ
• 消毒方法
• フィールドが変更されました
• ペイロードのスライス長さ
• チェックサムが再計算されたかどうか
• アドレスマッピングが安定しているかどうか
• 前後のパケット数
• 出力ファイルのハッシュ

これにより両面が保護されます。受信者はキャプチャの限界を理解しており、送信者はどの機密データが削除されたかを説明できます。

PCAP 手術が適している場所

PCAP Surgery は、制御されたパケット キャプチャ ワークフロー向けに構築されています。消毒は手術の一形態であるため、その世界に属します。製品は、キャプチャを黙って変更し、説明責任を消去するべきではありません。

匿名化と無害化の場合、有用な PCAP 手術の出力には次のものが含まれる必要があります。

• 何が削除されたのか
• 保存されていたもの
• どのパケットが影響を受けたか
• プロトコルのチェックサムが変更されたかどうか
• タイミング証拠が有効であり続けるかどうか
• 選択したサニタイズ モードがサポート ケースに適合する理由

検索クエリが「pcap を匿名化する」または「共有する前にパケット キャプチャをサニタイズする」である場合、最も重要な答えはワンクリック コマンドではありません。編集方法を、受信者が実際に必要とする証拠と一致させることです。