本記事では先日開催されたJANOG54にてプロトタイプデモとして展示していた内容をより詳しく解説いたします。
JANOG54での出展やデモの様子はこちらからご確認いただけます。
目次 非表示
サンプリングとは
統計学におけるサンプリングとは大量のデータセットから一部のデータを抽出し、抽出した一部のデータを用いて全体を推測する手法を指します。これは全体のデータを処理するのが困難または不可能な場合に特に有用な手法です。
味噌汁を作っていて味を把握するのに鍋の味噌汁を全て飲む必要性はなく、スプーン一杯すくって味見すればおおよそ十分だと思いますが、考え方はこれに似ています。
ネットワークトラフィックの分析においては、xFlow(NetFlowやsFlowといったフロー技術の総称)がサンプリングを前提とした実装が成されており、大規模なネットワークの分析においてトラフィックのサンプリングと組み合わせて利用されるケースが頻繁に見られます。
DPIとサンプリングの相性
xFlowは一般的にネットワーク機器(フローエクスポーター)がパケット単位にトラフィックをサンプリングし、5-tuple(プロトコル番号、発信IPアドレス、着信IPアドレス、発信ポート、着信ポート)と、パケット長といった分析に必要な情報のみを生成します。フローコレクタはこれを収集・分析することで可視化を行います。
ではDPIに対して同様のアプローチでパケット単位のサンプリングを行うとどのような状況になるでしょうか?
過去の記事(DPIの仕組み ~初級編~、基礎編)でご紹介した通り、DPIは高次レイヤのアプリケーションプロトコルのメッセージ構造や手続きを理解したうえで通信内容の分析を行います。
そのためパケット単位にサンプリングされたデータでは、パケットが分割されているような状況で一部のパケットのみ抽出してもペイロード部分を結合(リアセンブル)できない状況に陥ります。結果、サービスを識別できない状況が発生します。
以下の図はパケットが分割された状況下でのサンプリングの例となります。本来送信されたデータには目・鼻・口の情報がのっていますが、フラグメントによりそれぞれ別のパケットになり、口の情報をもつパケットだけがサンプリングされDPIへ到達しますが、DPIではこの情報だけでは何のアプリケーションか判断できません。
![](https://www.ranger-systems.co.jp/ranger-blog/wp-content/uploads/2024/07/traffic_sampling01-1020x1024.png)
またサンプリングとは異なりますが、ペイロード部分を除去してパケットキャプチャを行うことでキャプチャシステムのストレージを有効活用する目的で利用されるパケットスライシング、トランケートと呼ばれるような機能もDPIとは相性が悪いと言えます。
先ほどの目・鼻・口の情報を持つパケットで考えると、パケットスライシングにより目・鼻・口の情報をもつペイロード部分が除去されてしまい、DPIでは識別が困難な状況になります。
![](https://www.ranger-systems.co.jp/ranger-blog/wp-content/uploads/2024/07/traffic_sampling02-1024x730.png)
フロー単位のサンプリング
ただでさえ計算機リソースを大量に消費するDPIです。大規模なネットワークにサンプリングを行うことなしにDPI装置を導入するとなると膨大なコストがかかってしまうケースが少なくありません。トラフィック分析の精度を多少落としてでもDPI装置の導入コストを抑えたいというニーズはある、と弊社では考えています。
サンプリングで対象トラフィックを抑えたいがパケット単位のサンプリングではDPIでの識別精度が下がってしまう。。。
そこで、DPIの機能を損なわず分析対象とするトラフィックを低減するために、フロー単位のサンプリングが有効ではと考え、概念検証を行い、奈良で開催されたJANOG54でデモとしてその一部を展示させていただきました。
フロー単位のサンプリングは、パケットをランダムにサンプリングする/しないの判断をせず、5-tupleに基づいてフローを識別した上でフロー単位にサンプリングする/しないの判定を行います。これにより、特定フローのパケットは全てサンプリングする(あるいはしない)ことができるため、先述したようなDPIでのリアセンブルに支障を来すことなくトラフィックの分析を行いつつ、サンプリングのメリットを享受することが可能になります。
以下はSandvine社製のDPIであるActiveLogicにサンプリング前のトラフィックを分析させた場合、フロー単位にサンプリングしたトラフィックを分析させた場合、パケット単位にサンプリングしたトラフィックを分析させた場合の状況を比較したものです。
![](https://www.ranger-systems.co.jp/ranger-blog/wp-content/uploads/2024/07/traffic_sampling03.png)
![](https://www.ranger-systems.co.jp/ranger-blog/wp-content/uploads/2024/07/traffic_sampling04-1.png)
![](https://www.ranger-systems.co.jp/ranger-blog/wp-content/uploads/2024/07/traffic_sampling05-2-1024x926.png)
パケット単位にサンプリングされたトラフィックを分析した図3では、Not analyzed、Unknown、Being analyzedの比率が大きくなっていますが、これらはサービスの識別が不可能あるいは識別中であることを示す分類であり、分析精度に悪影響を及ぼしていると判断できます。
一方で、フロー単位にサンプリングされたトラフィックを分析した図2では、サンプリング前の状況に近いことがわかります。
今後の展望
今回の概念検証ではトラフィックのサンプリングを行うツールを内製しましたが、あくまで機能的な検証を目的としていたためパフォーマンスに難があります。今後は同等の機能を有するパケットブローカー等を用いて、より効果的により安価に大きなトラフィックを処理できる機器の選定、検証を行い弊社よりご提案するトラフィック分析システムの一構成に加える予定です。