# Realtime High-Speed Network Traffic Monitoring Using ntopng > [!abstract] 概要(abstract の日本語訳) > ネットワークトラフィックの監視は、ホスト数・プロトコルの増加・プローブ配置トポロジーの観点でますます困難になっている。 > 仮想化環境とクラウドサービスの普及により、専用ハードウェア型の監視装置から、仮想マシン上で動作するソフトウェア型のトラフィック監視アプリケーションへと焦点が移った。 > 本論文は、高速ネットワーク向けに設計されたオープンソースのトラフィック監視アプリケーションである ntopng の設計と実装を扱う。 > ntopng の主要な特徴は、大規模ネットワークにおけるリアルタイム分析と、アプリケーションプロトコルおよびユーザーのトラフィック挙動を特徴づける能力である。 > ntopng は、小規模ネットワークから .it ccTLD のトラフィック分析に至るまで、さまざまな監視環境で広範に検証された。 ## 論文情報 - タイトル: Realtime High-Speed Network Traffic Monitoring Using ntopng - 著者・所属: Luca Deri(IIT/CNR, ntop)、Maurizio Martinelli(IIT/CNR)、Alfredo Cardigliano(ntop) - 媒体: 28th Large Installation System Administration Conference(LISA14)、pp.69-79、2014-11-09、Seattle, WA(**Best Paper 受賞**。出典: https://www.usenix.org/conferences/best-papers) - ISBN: 978-1-931971-17-1 - URL: https://www.usenix.org/conference/lisa14/conference-program/presentation/deri-luca - PDF: https://www.usenix.org/system/files/conference/lisa14/lisa14-paper-deri.pdf - コード: https://svn.ntop.org/svn/ntop/trunk/ntopng/(GPLv3) ## 概要 ntopng は、1998 年に発表された ntop(network top)の後継として設計された、オープンソースの実時間ネットワークトラフィック監視アプリケーションである。C++ 製のコア監視エンジンに Lua JIT 製のスクリプティング層を重ね、HTML5 ベースの Web GUI を通じてトラフィック分析結果を提供する。設計はエンジンとフロントエンドの分離を徹底しており、ソフトウェアは 4 層(ingress data layer / monitoring engine / scripting engine / egress data layer)に分かれる(図1)。 **図1: ntopng アーキテクチャ** ![[_attachments/lisa14-paper-deri/fig01-architecture.png]] (Figure 1. ntopng は libpcap・PF_RING による生パケット取得と、nProbe が変換した NetFlow/IPFIX/sFlow の JSON フローを ØMQ 経由で受け取る 2 系統の ingress を持つ。取得したデータは nDPI によるプロトコル識別を経て monitoring engine に集約され、redis をキャッシュ層として使いながら、Lua ベースの scripting engine を介して Web ブラウザ・SQLite・Syslog・ログ管理ツール(Splunk 等)へ出力される。) ## 問題設定 sFlow(2001年)・NetFlow/IPFIX(2004年前後)といった既存のトラフィック監視標準は、10 年以上前にルータ・スイッチへの組み込みを前提に設計されており、次の 3 点で現代のネットワーク運用に適合しなくなっている。 1. **サンプリングによる精度低下**: sFlow はパケットサンプリングを前提とし、v5 NetFlow や基本情報のみの v9 も含め、大容量 1/10G ポートに対応した監視能力へアップグレードされていないルータでは、部分的なデータに基づく不正確な計測に陥る。 2. **仮想化環境の不可視性**: 物理デバイスは仮想マシン間トラフィックを観測できない。VMware vSphere Distributed Switch や Open vSwitch のような仮想スイッチは NetFlow/sFlow に対応し始めているが部分的な解決に留まる。 3. **実時間性の欠如**: フローベースの監視パラダイムは、パケットがフローキャッシュ → エクスポートキャッシュ → コレクタの順に伝搬する構造上、本質的に実時間情報を生成できない(フロー統計は 30〜120 秒程度のフロー期間が終わるまで確定しない)。加えてフローは平均値しか報告できず、トラフィックスパイクを隠してしまう。 さらに、アプリケーションプロトコルの増加(非 IP プロトコルの消滅と application protocol の急増)、TLS の普及による暗号化トラフィックの不可視化、HTTP が hypertext 以外の用途(音声/動画配信、ファイアウォール回避、P2P)にも使われる実態の変化が、単純な TCP/UDP ポートベースの識別を信頼できなくしている。クラウド基盤上のサービスも memcache・redis・Cassandra・MongoDB のような分散コンポーネントで構成され、どの TCP コネクションがボトルネックかだけでなく、どの URL・SQL クエリが原因かという**アプリケーションレベルの情報**が要求されるようになった。 ## 提案手法 ntopng は上記の課題に対し、次の設計目標を掲げて開発された(§2 design goals)。 - 10 Gbit のバックボーンで平均パケットサイズ 512 バイト以上のトラフィックをパケットロス無く処理し、コモディティ環境で 1 コアあたり最低 3 Mpps を処理できること。 - 全ての監視データを計測遅延・平均化無しに即時利用可能にすること(probe/collector アーキテクチャに典型的な平均カウンタを排すること)。 - 専用ハードウェアアクセラレーションに依存せず、純粋にソフトウェアで実装すること。 - sFlow/NetFlow/IPFIX フローの収集もサポートし、既存の監視プロトコルとの互換性を保つこと。 - Skype・BitTorrent・VoIP/ストリーミング・FaceBook/Twitter・Citrix/Webex 等の主要プロトコルを検知・特徴づけできること。 - HTML5 ベースの組み込み Web GUI と、スクリプト可能かつマルチスレッドの監視エンジンを持つこと。 - 低電力の組み込み機器から高性能マルチコアサーバまで幅広いハードウェアで動作すること。 - トラフィック条件に基づくアラート生成と、システム内プロセスとの相関付けができること。 これらを実現する具体的な仕組みは次の通りである。 **Ingress データ層**: libpcap・PF_RING(ntop 開発の Linux 向け高速パケットキャプチャフレームワーク)による生パケット取得に加え、ØMQ(ZeroMQ)メッセージングライブラリを使った JSON イベント受信をサポートする。オープンソースの nProbe がフロープローブ/プロキシとして動作し、NetFlow/IPFIX/sFlow フローを JSON に変換して ØMQ 経由で ntopng に配信する。この設計により、Linux の netfilter が生成するファイアウォールログのような非フロー系イベントも同じ経路で ntopng に取り込める。ØMQ を介した階層構成では、複数の ntopng インスタンスが親子関係を持つクラスタを形成できる(図3)。 **図3: ntopng と nProbe のクラスタ構成** ![[_attachments/lisa14-paper-deri/fig03-cluster.png]] (各 ntopng インスタンスはフローの消費者にも生産者にもなれるため、JSON over ZMQ による多段の集約階層を構築でき、分散監視環境の(準)集中管理ビューを third-party ツール無しに実現できる。) **Monitoring engine**: インタフェースごとに 1 インスタンスの C++ クラスとして実装され、ロック競合を避けている。ntopng における「フロー」は VLAN/プロトコル/送受信 IP・ポートの 6-tuple の集合であり、フロー期間などの追加属性を持つ従来型フローとは異なり、最初のパケット到着時に開始し一定時間トラフィックが無ければ終了する。データは redis にキャッシュされ、(1) メモリから追い出されたホストの JSON 表現、(2) 数値-記号アドレスの対応、(3) 設定情報、(4) 名前解決待ちキューを保持する。redis を選んだ理由は、永続/揮発の使い分けができること、複数インスタンス間で federate できること(マイクロクラウド構成)、pub/sub によるアラート配信ができることの 3 点である。 アプリケーションプロトコルの識別には nDPI(ntop 製の GPLv3 Deep Packet Inspection ライブラリ)を用い、170 種類超のプロトコルを識別する。ポートだけでなくペイロード自体を検査し、SSL の場合はサーバ証明書名からサービスを推定する(例: `*.amazon.com` → Amazon)。さらに http://block.si が提供するドメインカテゴリ分類サービスと連携し、トラフィックの性質(News and Media・Social 等)によるホストの特徴づけや、Project Honeypot への問い合わせによる既知の悪性ホスト検知も行う。分類結果とパイチャートによる可視化の例を図4に示す。 **図4: アプリケーションプロトコル分類とトラフィック特徴づけ** ![[_attachments/lisa14-paper-deri/fig04-protocol-classification.png]] (左は上位アプリケーションプロトコルの内訳(Google 54.0%・HTTP 25.2%・DNS 12.4%・Apple 5.3%・その他 3.2%)、右はホストのトラフィック性質による分類(Business 43.5%・Unrated 25.5%・Personal 16.7%・Security Risk 9.4%・Unethical 4.9%)を示す実運用データの例である。) **Scripting engine**: 監視データへのアクセスを担う薄い C++ 層が Lua JIT インタプリタを組み込み、`interface`(フロー/ホスト統計へのアクセス)と `ntop`(設定・redis キャッシュへのアクセス)の 2 つの Lua クラスを公開する。処理エンジン(C++、高速なパケット処理に専念)とアプリケーションロジック(Lua、ユーザー要求に応じて変更)を明確に分離することで、C++ エンジンを変更せずに GUI や集計ロジックをカスタマイズできる。Lua スクリプトは C++ オブジェクトを直接参照せず、常に Lua テーブルとして結果を受け取るためオブジェクトロックの問題を避けている。1 秒粒度の cron デーモンが周期的スクリプトを実行し、例えば毎晩 SQLite に直近 24 時間の全ホスト情報をダンプして永続的な履歴ビューを構築する。 **Egress データ層**: 組み込み Web サーバが Lua スクリプト実行をトリガーし、Twitter Bootstrap と D3.js を用いた HTML5 GUI で結果を JSON として返す(図6)。JSON ネイティブなオブジェクト表現により REST 互換の Web サービスも構築でき、Splunk や ElasticSearch/Logstash のようなログ処理基盤とも syslog 経由で連携できる。 **図6: ntopng の HTML5 Web インタフェース(Registro.it の実運用画面)** ![[_attachments/lisa14-paper-deri/fig06-html5-web-interface.png]] (.it ccTLD レジストリの実運用環境で、上位フロー talker のトラフィックを Sankey 図で可視化している例。) **システム統合(sProbe)**: Linux 限定で、sysdig ベースの nProbe プラグイン sprobe と統合し、`accept()`/`connect()` のようなシステムコールをフックしてネットワーク接続の生成/削除イベントを捕捉する。これにより通信フローとプロセス名を関連付けられる。sProbe はメモリ使用量・VM ページフォールト数・CPU 使用率など `/proc` 由来のプロセス情報も報告する(図7)。複数の sProbe インスタンスからの情報を突き合わせることで、システム横断のプロセス相互作用も追跡できる(図8)。 **図7: sProbe から受信したプロセス情報のレポート** ![[_attachments/lisa14-paper-deri/fig07-sprobe-process-report.png]] (単一フロー(localhost:40406 ⇄ localhost:6379、Redis プロトコル)について、`init` → `bash` → `ntopng`/`redis-server` というプロセス系譜を可視化している。) **図8: ntopng のプロセス相互作用レポート** ![[_attachments/lisa14-paper-deri/fig08-processes-interaction-report.png]] (複数ホストにまたがる chrome・dropbox・ntopng・redis-server 等のプロセスと接続先ドメイン/IP の関係をツリー状に集約したシステム横断ビュー。) ## 新規性 - **フローコレクタを介さない実時間性**: 従来の flow エクスポータ/コレクタ方式(フローキャッシュ→エクスポートキャッシュ→コレクタの遅延経路)を避け、生パケットまたは JSON 化されたフローイベントを直接消費してカウンタを即時更新する設計により、フロー期間(通常 30〜120 秒)を待たずに実時間性を確保している。 - **JSON over ØMQ によるプロトコル非依存の疎結合構成**: NetFlow/IPFIX の複雑な標準仕様を ntopng 自身に持ち込まず、nProbe のような外部プロキシが JSON へ変換してから配信する設計により、フロー標準・非フローイベント(ファイアウォールログ等)を同一の取り込み経路で扱える。 - **DPI とドメインカテゴリ分類・脅威情報の統合**: nDPI によるペイロードベースの識別に加え、外部クラウドサービス(block.si・Project Honeypot)と連携したトラフィック性質分類と悪性ホスト検知を、redis キャッシュを介して低コストに統合している。 - **エンジンとロジックの分離によるスクリプタビリティ**: C++ の高速処理エンジンと Lua ベースのアプリケーションロジックを分離し、C++ コードを変更せずにアラート条件や可視化ロジックをカスタマイズできる。 - **システムレベルとの相関**: sysdig ベースの sProbe 統合により、ネットワークフローとプロセス・システムリソース情報を関連付け、単なるトラフィック監視を超えたトラブルシューティングを可能にした。 - **低コストハードウェアへの移植性**: C++ による移植性の高い設計により、RaspberryPi・BeagleBoard・Ubiquity EdgeRouter Lite のような安価な ARM ベース機器上でも動作する。 ## 実験設定 評価は ntopng v.1.1.1(r7100)を、低価格帯の Intel Xeon E3-1230(3.30 GHz)上で実施した。10 Gbit の Intel ネットワークインタフェースを PF_RING DNA v.5.6.1 で監視し、トラフィック生成・再生には PF_RING ツールセットの `pfsend` を用いた。実トラフィックの試験では実ネットワークでキャプチャした pcap ファイルをライン速度でループ再生し、合成トラフィックの試験ではホスト数とパケットサイズを指定して人工的にパケットを生成した。ホスト数を増やすほど ntopng が扱うアクティブフロー数も増加する点に注意が必要である(実運用では通常数千ホスト程度だが、100〜1,000,000 ホストの範囲で網羅的に評価した)。 ## 実験結果 **実トラフィックでの 10 Gbit 監視(表9、原文 Fig. 9)**: | Hosts Number | PPS | Gbit | CPU Load | Packet Drops | Memory Usage | |---|---|---|---|---|---| | 350 | 1,735,000 | 10 | 80% | 0% | 27 MB | | 600 | 1,760,000 | 10 | 80% | 0% | 29 MB | (平均パケットサイズ 700 バイトの実トラフィックにおいて、低価格サーバ 1 台がフルロードの 10 Gbit リンクをパケットロス無しで、かつ限られたメモリ使用量で監視できることを示す。) **合成トラフィックでのパケットサイズ/ホスト数と処理性能(表10、原文 Fig. 10)**: | Hosts Number | 64 bytes | 128 bytes | 512 bytes | 1500 bytes | |---|---|---|---|---| | 100 | 8,100,000 | 8,130,000 | 2,332,090 | 2,332,090 | | 1,000 | 7,200,000 | 6,580,000 | 2,332,090 | 820,210 | | 10,000 | 5,091,000 | 4,000,000 | 2,332,090 | 819,000 | | 100,000 | 2,080,000 | 2,000,000 | 1,680,000 | 819,000 | | 1,000,000 | 17,800 | 17,000 | 17,000 | 17,000 | (単位は処理 PPS。PF_RING DNA によりパケットキャプチャ自体はボトルネックにならないが、アクティブホスト/フロー数の増加に比例して処理エンジン性能が低下する。100 万ホストでは性能が劇的に低下する一方、10 万ホスト規模の大規模 ISP 相当までは実用的な性能を維持する。) **図12(原文 Fig. 12): 合成トラフィック — ホスト数と処理パケット数(PPS)の関係** ![[_attachments/lisa14-paper-deri/fig12-hosts-vs-pps.png]] **図13: 合成トラフィック — ホスト数と処理パケット数(Gbit)の関係** ![[_attachments/lisa14-paper-deri/fig13-hosts-vs-gbit.png]] (実トラフィックでフル 10 Gbit リンク使用時、約 1.7 Mpps で 10 万台超のアクティブホストを 1 インタフェースあたりで処理でき、大規模 ISP 相当の要件を満たす。) **図14: ホスト数とメモリ使用量の関係** ![[_attachments/lisa14-paper-deri/fig14-hosts-vs-memory.png]] (メモリ使用量は 100 ホストの 20 MB から 100 万ホストの約 7 GB まで増加する。512 MB メモリの低価格 ARM 機器(RaspberryPi・BeagleBoard、$25 程度)でも約 4 万台の同時ホスト/フローを監視できる価格性能比を実現している。) **PF_RING のトラフィック分散**: `pfdnacluster_master`(PF_RING の libzero を利用)は、ゼロコピーでパケットを複数の仮想 egress インタフェースにファンアウトし、フロー 6-tuple 単位でバランシングできる(図11、GTP でカプセル化されたモバイルトラフィックにも対応)。これにより、CPU コアごとに ntopng の処理スレッドを割り当て、10 Gbit を超えるマルチリンクの実時間監視が可能になる。 **図11: pfdnacluster_master による PF_RING ゼロコピートラフィックバランシング** ![[_attachments/lisa14-paper-deri/fig11-pfdnacluster-master.png]] ## 考察 実験結果は、専用ハードウェアアクセラレーションに依存しない純粋ソフトウェアの実装でも、コモディティサーバ上で 10 Gbit のライン速度監視が実用的であることを示している。一方で、性能はホスト/フロー数に強く依存するため、非常に大規模なバックボーン(100 万ホスト規模)を単一インタフェースで監視する構成は現実的でなく、PF_RING による仮想インタフェース分割とマルチコアへの分散が前提となる。低価格 ARM 機器への移植性は、SOHO 環境や既存ネットワーク機器への組み込みを狙った設計目標の達成を裏付ける。 著者らは今後の課題として、(1) 分散した VM・小型機器の限られたストレージを集約するクラウドベースのストレージ層、(2) IP reputation サービスとの統合によるセキュリティスコアリングの拡張、(3) ØMQ 通信へのデータ暗号化・認証の導入を挙げている。これらはいずれも本論文の時点では未実装であり、実運用でのスケールアウト・セキュアな分散構成という観点では発展途上の設計であることを示す。 ## 強み / 弱点・課題 **強み**: - オープンソース(GPLv3)であり、ソースコード公開によって異種プラットフォーム(x86・MIPS・ARM)への移植・改変が可能。 - フローコレクタ方式の構造的遅延を回避した実時間性と、低価格コモディティハードウェアでの 10 Gbit ライン速度処理という高いコストパフォーマンス。 - DPI・ドメインカテゴリ分類・脅威情報・システムレベル相関付けを 1 つのツールに統合し、単一障害点の少ない疎結合な JSON ベースの連携方式を採用。 - C++ エンジンと Lua スクリプトの分離により、ユーザーが監視ロジックを柔軟にカスタマイズできる拡張性。 **弱点・課題**: - システム統合(sProbe)は Linux 限定であり、他 OS では対応していない。 - 分散ストレージの集約機構が未実装であり、大規模な分散監視環境ではデータの一元化に課題が残る。 - ØMQ 通信の暗号化・認証が未対応であり、セキュアな分散構成を要する環境では追加の対策が必要。 - 100 万ホスト規模では単一インタフェースの処理性能が急激に低下するため、超大規模環境ではマルチインタフェース分散が前提となり、単純な水平スケールではない。 - nDPI によるプロトコル識別精度は同種の商用製品と同等〜それ以上とされるが、暗号化トラフィックの識別は証明書名などのヒューリスティックに依存し、TLS の普及がさらに進んだ場合の識別限界は本論文では十分に論じられていない。