PCAP ネットワーク・フロー・モニター

Posted by fmadio | 100G Ethernet

インフラストラクチャーを動き回るトラフィック・フローの良好な可視性と理解は、全てのネットワーク・オパレーション・センター(NOC)及びセキュリティ・オパレーション・センター(SOC)にとって非常に重要であり、色々な取り組み方があります。簡単な方法、難しい方法、高価な方法、無料の方法などがあります。


  • bpf counter title graphic


オープンソース・ソフトウェアと組み合わされたFMADIO 10G 40G 100G パケット捕捉システムは、自社のフルパケット捕捉システムを用いて新しい可視性及びモニター機能を可能にします。我社のパケット捕捉システムは、多目的であり、トラブルシューティングに使われたり、Wireshark と共に深い分析をしますが、非常に優れたモニター性能も持っています!

FMADIO はPCAP をElasticSearch バルクアップロードJSON に転換するpcap2json ユーティリティを開発しました。LogStash無しで、フルに圧縮されたJSON をElasticSearch に直接アップロードすることも出来ます。無料であり、GitHub のオープンソースであり、如何なるPCAP ファイルでも使えます。

ネットフロー・モニター "NETFLOW"

トラフィック・モニターの基本的方法の1つはネットワーク・フロー/ IPFIX を通して行われ、各及び全てのネットワーク・フローのために統計を計算するデバイスをネットワークに備え付けます。この場合のネットワーク・フローは、ユニークな7-タプル IP Src/Dst, プロトコル, Port Src/Dst, イングレス/エグレス・ ポートです。通常、TORスイッチがフローを発生しますが、それにはいくつかの問題があります。

最大の問題はパフォーマンスです。スイッチ及びルーターはパケットを動き回すように設計されていて、大量のCPU及びRAMを使用するソフトウェアーの実行には適していません。Ciscoルーター上でIPFIXデータを発生する場合など、かなり重大なパフォーマンス・ペナルティが生じます。例えばパケットをルーティングせずに全てのフローを計算するために、CPUが停滞します。

CPUコストに加えて、RAMコストがかかります。もし発生したフローが膨大なユニーク・フローを持つリンク上であれば、全てのコネクションを監視するRAMの不足が直ちに生じます。

netflow generator

サンプル・ネットフロー"SFLOW"

上記CPU及びRAMパフォーマンス問題の解決策は、「サンプルする」別名サンプル・ネットフロー又はsFlowです。アイデアは、50パケット毎に1個サンプルし、その他の49個を捨てることです。ネットワーク上では多数のパケットが飛び回っていて、その中で問題の最大当事者は求めているならば、統計的サンプリングはそのような大きなフローを示します。

しかし、もし厳密な詳細を求めている、例えば、なぜホストX は朝の午前3時にTOR ノードに繋がっているのかと言った分析です。サンプル・ネットフローは、トラフィックの微細な詳細を失うため、非常に不満足なオプションになります。

例えば、サンプル・ネットフローは、全貌が得られないため、監査ログ/属性/セキュリティなどの目的には全く利用できません。全てのTCP 対話が捕捉かつログされることを100% 保証することは不可能であり、もしもX又はYが。。。の質問が、常に頭の片隅をよぎります。

一言でいうと、サンプル・ネットフローは良い結果を与えるので、無いよりましですが、NOC及びSOCチームが要求する詳細を全く欠きます。
sflow generator

スナップショット・ネットフロー"SNAPFLOW"

ネットフロー情報の最大問題の1つは、正確なバンド幅および回路利用情報を示すことが出来ないことです。これはネットフローが時間基準でなく接続基準のためです。例えば、一分間のFTP 接続の単一ネットフローは2つのホスト間のTCP 上での10MB のデータ転送を示します。このことはデータが転送されたことについて可視性を得るためには素晴らしいことです。しかし、どのようにして転送されたかについての情報はありません。最初の5秒間で9MB 完了し、残りの55秒間はダラダラ転送されたのか。又は60秒間一定のバンド幅であったのか、又は。。。、データ転送レートの詳細については情報が得られません。

FMADIO 100G パケット捕捉システム上で推奨される取り組み方であるスナップショット・ネットフローを紹介します。それはフルネットフロー・ジェネレーション(ロス無し)ですが、フロー(パケットでない)は一定インターバルで出力します。このことはフルフロー情報を得ることを意味し、時間の経過に沿った各フローのバンド幅のプロフィールも示します。例えば、100msec インターバルでのスナップショットを使い、100msec インターバル内で見つかる全てのフローを出力し、次にフロー・ログをクリヤーし、それから次のパケットについてフローの計算を始めます。

netflow snapshots

スナップショット可視化

事態の後にバックエンド上でフィルターできるから、ネットフロー・スナップショットは素晴らしいです。例えば、特別なフロー/回路のモニター、又は特別なホストの調査、又は要求によりバンド幅問題の交換など。バンド幅および100msec インターバルでのMAC/IP/プロトコル/ポート情報により、特別な回路又はホストのバンド幅をモニターすることは容易です。可視化のサンプルを以下に示します。

bpf counter title graphic

上記の場合、大きなスパイクの前にいくつかの小さな転移があることは明確です。さらに深く探り、もっと正確な可視化とスパイクのプロフィールを得るドリルダウンをすることが可能です。

bpf counter title graphic

バンド幅プロフィールがなぜこのようになるかについては明らかでありませんが、そのためにフルパケット捕捉もあります!異常事態が起きた時間及びMAC/IP アドレス範囲を知ることが出来るし、FMADIO 40Gパケット捕捉システムを使って、特定の時間範囲、IP、ポートでのPCAP のダウンロードが出来るし、WireShark を使って深く分析することが出来ます。

スケーラブル・モニター・アーキテクチャー

従来のネットフローの別問題はコレクター側です。通常、ネットフロー/IPFIX はUDP 上での出力であり、ネットフロー・コレクターは全てをすくい上げます。しかしフロー・コントロールがなく、ネットフロー・コレクターは圧倒され、パケット及びネットフローを見落とし、全般にわたる問題が常に生じます。全てのネットフローをコレクトしたいときに、トラフィックの中の異常なスパイクによりネットコレクターがデータを見落とすため問題になります。このことは常に起こります。

bpf counter title graphic

上記のダイアグラムはネットフローデータのコレクトと分析の一般的取り組み方です。ジェネレーターおよびコレクター両方でのFIFOに気付くでしょうが、これらは1MB と比べて普通非常に小さく、数KB の場合があり、簡単にオバーフローし、データを見落とします。

ELASTICSTACK上のネットワーク・フロー

我社は異なった取り組み方を採用し、可視化/モニターに ElasticStack及びGrafanaを使います。これらは非常に優れた製品であり、無料です。我社の取り組み方は、FMADIO SSD パケット・ストレージをFIFO の一種として使い、ネットフロー・ジェネレーター(pcap2json)のイングレス及びエグレスはフルフロー・コントロールを持ちます。結果はフル及び完全カバレッジで、ロス無しです。ロジック・フローは以下のようになります。
bpf counter title graphic

主要な違いは、膨大な1TB~100TB (そうです、TeraBytes) 「SSD パケット・キャッシュ」, 通常の名前はパケット捕捉ストレージです。しかしながら、FMADIO 10G 40G 100G パケット捕捉 システムは、典型的なパケット捕捉システムより優れています。この場合、パケット捕捉システムは、膨大なSSD パケット・キャッシュFIFO をネットフロー・スナップショットに変換するために我社のオープンソースpcap2json ユーティリティを実行します。

キーポイントは、捕捉後にネットフロー・ジェネレーションが実行することであり、全ての捕捉された単一のパケットはハード・リアルタイム・デッドライン 無しでネットフロー・ジェネレーターにより処理されることを意味します。従って、膨大なTBサイズのFIFO において、パケットをバッファすることにより、好きなだけ時間を使って処理できます。

ネットフロー・エグレス側では多くのパフォーマンス問題が起きます。通常、ネットフロー・コレクター又はこの場合ElasticStack がボトルネックになる可能性が高いです。ネットフロー・コレクターとElasticStackの主な違いは、ElasticStack 挿入 がTCP HTTP JSON requests (損失UDPではありません)上であり、フルフロー・コントロール及びネットフロー・ドロップ無しの結果を生じます。

1TB~100TB のバッファのため、ElasticStackがストールして、ジェネレーターを減速して、スローダウンの結果になっても、問題になりません。この取り組み方は、全ての単一スナップショットの処理、全ての単一スナップショット・フローの生成、フル及び完全カバレージなどの結果を生じます。

最後の見解

パケット捕捉を単純な磁気ストレージのPCAP と考えないでください。以前は真実でしたが、現在は高速SSD ドライブにより、多くのことが達成されます。ネットフロー・スナップショット・ジェネレーションは、バッファする、処理する、処理したデータを更なる処理のために下流に送るためにFMADIO 100G パケット捕捉システムを使用する好例です。

さらに、深く掘り進む調査で見つけることが難しい分析のために頼りに出来るフルパケット捕捉があります!