1

Snort によってキャプチャされた TCP ストリームを再構築するプログラムを作成しています。セッションの再構築に関して私が読んだ例のほとんどは、次のいずれかです。

  • まず、pcap ファイル全体をメモリにロードします (ハードウェアの制約と、一部のキャプチャ ファイルのサイズが 10 GB であるため、解決策ではありません)。
  • キャプチャを読み取って各パケットをメモリにキャッシュし、関係のないパケットを破棄します。これは基本的に、ファイル全体をメモリに読み込むのと同じ問題を引き起こします

私の現在の解決策は、フォーマットが単純なので、独自の pcap ファイル パーサーを作成することでした。各パケットのオフセットをベクトルに保存し、渡した後にそれぞれをリロードできます。これは、libpcap と同様に、一度に 1 つのパケットのみをメモリにストリーミングします。パケット データではなく、順序付けにシーケンス番号とフラグのみを使用しています。libpcap とは異なり、著しく遅くなります。libpcap で 570 MB のキャプチャを処理するのに約 0.9 秒かかりますが、私のコードでは 3.2 秒かかります。ただし、キャプチャ全体をリロードせずに逆方向にシークできるという利点があります。

速度の問題で libpcap に固執する場合currentOffset、初期値 24 (pcap ファイルのグローバル ヘッダーのサイズ) を持つ変数を作成し、新しいパケットをロードするたびにそれをベクターにプッシュするだけでよいと考えていました。呼び出すたびpcap_next_exに、パケットのサイズ + 16 (pcap レコード ヘッダーのサイズ) だけインクリメントします。次に、個々のパケットを読みたいときはいつでも、従来の手段を使用してそれをロードし、packetOffsets[packetNumber].

libpcap を使用してこれを行うより良い方法はありますか?

4

1 に答える 1

1

自分で問題を解決しました。

を呼び出す前にpcap_next_ex、 に押し込みftell(pcap_file(myPcap))ますvector<unsigned long>。その後、必要に応じて手動でパケットを解析します。

EZPZ。24時間以上の頭の混乱がありました...

于 2012-07-28T05:37:38.377 に答える