PCAP タイムスタンプの問題: キャプチャ時間を検査、正規化、または書き換えるタイミング

タイムスタンプはパケット キャプチャの証拠の一部です。順序、遅延、再送信のタイミング、要​​求と応答のギャップ、問題がアプリケーション ログと一致するかどうかについて説明します。タイムスタンプが間違っていると、調査全体がずれてしまう可能性があります。

ただし、タイムスタンプの修復はデリケートです。キャプチャ時間を変更すると、分析が容易になる一方で、ファイルが元のイベントに忠実ではなくなります。

一般的なタイムスタンプの問題

PCAP タイムスタンプの問題には次のようなものがあります。

• パケットの順序が狂っているように見える
• タイムスタンプが後方にジャンプします
• タイムスタンプはすべてゼロです
• 解像度が予想より低い
• 不可能な時間範囲にわたるキャプチャ
• キャプチャ中に VM またはホストのクロックが変更される
• マージされたキャプチャは異なるクロックを使用します
• タイムゾーンの仮定により人間のレポートが混乱する

これらの一部は表示の問題です。一部はキャプチャの問題です。一部はマージの問題です。修復戦略は、どちらであるかによって異なります。

壁掛け時計とは別注文の意味

パケット順序と実時間は関連していますが、同一ではありません。キャプチャでは、無駄なウォール クロック値を保持しながら、パケットの順序を維持できます。別のキャプチャには妥当なウォール クロック値が含まれている可能性がありますが、異なるキャプチャ ポイントからのマージされたストリームが含まれているため、タイミング比較が安全でなくなります。

タイムスタンプを書き換える前に、次のことを確認してください。

• パケット注文は信頼できるのか？
• 相対的なタイミングは信頼できるのでしょうか?
• 絶対的な実時間は必要ですか?
• キャプチャは複数のソースからマージされていますか?
• アプリケーション ログは外部アンカーを提供しますか?
• 下流のツールは現在のタイムスタンプを誤って解釈するのでしょうか?

これらの質問によって、検査、注釈、正規化、または書き換えが適切かどうかが決まります。

正規化が役立つ場合

タイムスタンプの正規化は、元の絶対時刻は重要ではないが、相対的な順序と間隔は重要である場合に役立ちます。たとえば、間違ったシステム クロックを使用したラボ キャプチャでも、有効な要求と応答のタイミングが表示される可能性があります。開始時間を正規化すると、相対的な動作を変更せずにレポートを読みやすくできます。

出力には以下が記録されます。

• 元の最初のタイムスタンプ
• 正規化された最初のタイムスタンプ
• デルタが保存されたかどうか
• 影響を受けるパケット
• 正規化の理由

その記録がなければ、将来のエンジニアは時間証拠がオリジナルなのか編集されたものなのかを判断できません。

書き換えが危険な場合

キャプチャを次のものと関連付ける必要がある場合、タイムスタンプの書き換えは危険です。

• サーバーログ
• カメラログ
• USB またはシリアル トレース
• 事件のタイムライン
• 法的またはコンプライアンスの証拠
• マルチポイントネットワークキャプチャ

このような場合、タイムスタンプを変更すると、ファイルの検査は容易になりますが、信頼するのは難しくなります。より良い最初のステップは、注釈を付けることです。時計の問題を文書化し、生のキャプチャをそのまま残しておきます。

PCAP 手術が適している場所

PCAP 手術は、偶然の突然変異ではなく、制御された編集を中心に構築されています。タイムスタンプの作業は、チェックサムやパケットのトリミングと同じルールに従う必要があります。つまり、最初に検査し、次に決定し、証拠がそれをサポートする場合にのみ書き換えます。

優れた PCAP 手術ワークフローは、次の答えに役立ちます。

• どのようなタイムスタンプ異常が存在しますか?
• 影響を受けるパケット数はどれくらいですか?
• 注文はまだ信頼できるのでしょうか？
• 相対的なタイミングはまだ役に立ちますか?
• どのような書き換えまたは正規化が適用されましたか?
• 変化は再現できるのか？

プロトコル エンジニアにとって、その価値は単にファイルを変更することではありません。この値により、別のエンジニアが検証できるキャプチャと推論の証跡が生成されます。