ntopng、nProbe、PF_RING FT などの多くの ntop 製品は、ネットワーク ストリームに基づいています。ただし、すべてのユーザーがネットワーク ストリーミングとは何か、実際にどのように機能するかを詳しく知っているわけではありません。このブログ投稿では、それらが何であるか、そして実際にどのように機能するかについて説明します。
ネットワークトラフィックとは何ですか
ネットワーク ストリームは、共通のプロパティを持つパケットのセットです。これらは通常、5 タプル キーによって識別されます。これは、特定のフローのすべてのパケットが同じ送信元と宛先 IP、送信元と宛先ポート、およびアプリケーション プロトコル (TCP など) を持つことを意味します。実際には、ストリーム キーには少なくとも VLAN ID が含まれ、最終的にはカプセル化されたトラフィックのトンネル ID などの他の属性も含まれます。フローは、パケットをクラスタリングし、公開キーを使用してトラフィックを分類する方法です。これは、netstat -na などのコマンドを実行したときにコンピュータ上で表示されるものと同様です。各フローには、フロー パケット/バイト、およびフロー タイマー (最初と最後のフロー パケットの時間)、統計情報 (再送信、パケットの乱れなど)、セキュリティ プロパティ (フロー リスクなど) などの他のさまざまな属性を追跡するためのさまざまなカウンターがあります。
トラフィックはどのようにメモリに保存されるのでしょうか?
ネットワーク フローは、フロー キャッシュ (通常はハッシュ テーブルを使用して実装される) と呼ばれるデータ構造に保持され、受信パケットが継続的に供給されます。フロー キャッシュは、アクティブなフロー (つまり、フローに属するパケットが受信されたときにまだアクティブだったフロー) をメモリに保存します。以下は、ntopng がライブ ストリーム キャッシュとその 5 タプル キーを表示する方法を示しています。
ネットワーク ストリームはいつ開始されますか?
ネットワーク フローは、最初のフロー パケットが観察されるとすぐに開始されます。起動時にはストリーム バッファは空で、パケットが受信されるといっぱいになります。受信パケットはそれぞれデコードされ、ストリーム キーが計算されます。フロー キャッシュでそのようなキーが検索されます。見つからない場合は、新しいエントリがフロー キャッシュに追加されます。見つからない場合は、そのようなキーを持つ既存のエントリが更新されます。つまり、フロー パケット/バイトのカウンタとタイマーが更新されます。したがって、基本的に、最初のストリーム パケットが観察されたときにストリームが開始されます。
ネットワーク ストリームはいつ終了しますか?
各フローには 2 つのエージング タイマーがあります。アイドル タイマー (最後のフロー パケットが受信されてからの経過時間を追跡します) と持続時間タイマー (フローの継続時間を追跡します)。フローは、これら 2 つのエージング タイマーのいずれかが期限切れになると終了します。つまり、フローが長時間アイドル状態だった場合（たとえば、一定期間パケットが受信されなかった場合）、またはフローがフロー キャッシュに長期間保存されていた場合です。 。nProbe および PF_RING FT では、フローの有効期限が切れると、フローはフロー キャッシュから削除され、コレクターに送信されます。対照的に、ntopng では、永続的なストリームはキャッシュから削除されないため、ストリームはアイドル状態の場合にのみストリーム キャッシュから削除されます。その理由は、nProbe のようなトラフィック プローブは、監視対象のトラフィックに関する情報をコレクター (ntopng など) に定期的に報告する必要があるため、トラフィックは「クリップ」されてコレクターに送信されます。対照的に、ntopng ではコレクターに通知する必要がないため、環境設定で必要な設定が行われている限り、ストリームはメモリ内に留まります。
フローキーと方向
最初のストリーム パケットを受信したときにストリームが作成された場合、ストリーム クライアントを実際のネットワーク クライアントとして扱うことができます。たとえば、ホスト 1.2.3.4 上のクライアントからホスト 5.6.7.8 への SSH の場合、この通信のフローは 1.2.3.4:X<->5.6.7.8:22 になります (SSH がポート 22 で実行されていると仮定します)。そうでしょう？ただし、そのようなストリームがストリーム キャッシュ内で 5.6.7.8:22<->1.2.3.4:X として報告されることがあります。なぜ？これにはさまざまな理由が考えられます。
- アプリケーション (例: ntopng) はストリームの開始後に開始され、ntopng によって観察される最初のパケットは 1.2.3.4:X -> 5.6.7.8:22 ではなく、5.6.7.8:22 -> 1.2.3.4:X です。
- フローは正しいキーとともにキャッシュに保存されていますが、しばらくの間（たとえば 2 分間）パケットが交換されなかったため、アプリケーションはフローが期限切れであると宣言し、フロー キャッシュから削除しました。その後、新しいパケットが突然観測された場合、これはサーバーの保存パケットである可能性があるため、そのパケットは間違った方向に送信される可能性があります (例: 5.6.7.8:22 -> 1.2.3.4:X)。この場合、ストリームはキャッシュに逆方向に配置されます (9、つまり間違っています)。
ntopng (設定経由) および nProbe (-t および -d を指定したコマンド ラインを使用) ストリーム タイムアウトを構成できるため、これらの問題は (完全に解決されたわけではありませんが) 軽減されます。ただし、特に UDP ストリームの場合、タイムアウトを調整するだけでは十分ではありません。TCP とは異なり、実際のフロー方向を推測するために使用できる TCP フラグがないからです。したがって、ntopng はフローの方向を交換するためにいくつかのヒューリスティックを実装しますが、無効な情報が報告される可能性があるため、このヒューリスティックはあまり積極的であってはなりません。
この投稿によって、フローベースのネットワーク トラフィック分析がどのように機能するのか、また、脆弱性のためではなく、これらの測定の性質により、「予期しない」動作が時々観察される理由が明らかになることを願っています。