DPIの代わりの機械学習。 トラフィック分類子の構築

DPI（ディープパケットインスペクション）のない最新のネットワークテクノロジーの世界を想像することはできません。 ネットワーク攻撃検出システム、企業ネットワークセキュリティポリシーの大部分、通信事業者によるユーザートラフィックのシェーピングとブロックをサポートします-はい、Roskomnadzorの要件を満たすためには、すべてのプロバイダーがDPIツールを持っている必要があります。

それでも、DPIにはすべての関連性があるため、いくつかの欠点があります。 主なものは、DPIツールが分析されたパケットのペイロードを確認する必要があることです。 また、クライアントが暗号化を使用する場合はどうすればよいですか？ または、たとえば、ここにDPIがない場合でも、将来、ネットワーク上の現在のトラフィックの分析を行う必要がある場合、その後の分析のためにすべてのペイロードを保存するだけでよく、非常に不便です。

この記事では、よく知られているポートのリストを確認したり、パケットペイロードを確認したりすることなく、ごく少量の情報に基づいて、DPIの主要なタスクの1つであるアプリケーション層プロトコルを決定する別の方法を解決したいと思います。 一般的に。

ソリューションアプローチ

最初に、分類の対象を決定します-アプリケーション層のプロトコルを決定するのはどのエンティティですか？

DPIツールでは、原則として、分類オブジェクトはトランスポート層のトラフィックフローです。これは、トランスポートプロトコルとエンドポイントの順序付けられていないペアを持つIPパケットのセットです：<（source ip、source port）、（destination ip、port宛先）>。 また、このようなフローで作業します。

提案された方法の根底にある考え方は、異なるプロトコルを使用する異なるアプリケーションも、異なる統計特性を持つトランスポート層ストリームを生成するということです。 一連の統計フローメトリックが正確かつ簡潔に決定されると、これらのメトリックの値を使用して、どのアプリケーションがこのストリームを生成したか、したがって、このストリームによって転送されるアプリケーションレベルのプロトコルを高精度で予測することが可能になります。

これらのメトリックを定義する前に、いくつかの定義を紹介します。

• クライアントは、トランスポート層のプロトコルに応じて、TCP接続のイニシエーターまたはストリームの最初のUDPデータグラムの送信者です。
• サーバー-トランスポート層のプロトコルに応じて、TCP接続の受信側またはストリームの最初のUDPデータグラムの宛先。
• データの一部は、一方から他方（クライアントからサーバー、またはその逆）に送信されたアプリケーションレベルのペイロードのセットであり、同時にペイロードによって中断されませんでした。

最後の定義には何らかの説明が必要なので、私の内側のミケランジェロは急いで助けようとしています：


この例では、TCPハンドシェイクの後、クライアントはペイロードの転送を開始します。したがって、データの一部はクライアント側で始まります。 サーバーが応答でペイロードを送信せず、ACKのみを送信する限り、クライアントからのデータの一部が継続します。 サーバーが何らかのアプリケーションレベルの負荷を転送する必要性を感じると、クライアントデータの一部が終了し、サーバーデータの一部が開始します。 ペイロード転送全体が一方または他方からのデータの断片の交互であることを理解するのは簡単です。 両側で非常に集中的なデータ交換を行うと、データの一部が個別のIPパケットに縮退する可能性があります。

統計的フローメトリック

統計的なフロー特性はすべて、4行の数字を中心に踊ります。

• クライアントから送信されたトランスポート層セグメント（TCPまたはUDP）のサイズのシーケンス。
• サーバー側から送信されるトランスポート層セグメントのサイズのシーケンス。
• クライアントから送信されたデータの部分サイズのシーケンス。
• サーバー側から送信されるデータの部分サイズのシーケンス。

上の図に示されている短い例では、これらのシリーズには次の意味があります。

• クライアント側のセグメントサイズ：[220、520]
• サーバー側のセグメントサイズ：[720、420]
• クライアント側のデータの一部：[700]
• サーバー側のデータチャンクサイズ：[1100]

これらの4行の数値（後で説明します）は、データフローを非常によく特徴付けており、それらに基づいて、アプリケーションレベルのプロトコルを正確に推測できます。

イマジネーションを含めて、データストリームの統計的特性を、次の4行の数字から始めて定式化します。

1. クライアント側の平均パケットサイズ
2. パッケージサイズのクライアント側の偏差
3. サーバー側の平均パケットサイズ
4. パケットサイズのサーバー側標準偏差
5. クライアント側のデータの平均部分
6. クライアント側の逸脱
7. サーバー側の平均データチャンクサイズ
8. チャンクサイズのサーバー側の標準偏差
9. クライアントからのデータの一部あたりの平均パケット数
10. サーバー側でのサービングごとの平均パケット数
11. クライアント効率-アプリケーション層の転送された負荷の量を、アプリケーション層およびトランスポート層の転送された負荷の合計量で割ったもの
12. サーバー効率
13. バイト比-クライアントがサーバーよりも多くのバイトを送信した回数
14. ペイロード率-クライアントがサーバーよりも多くのバイトを送信した回数
15. パケット率-クライアントがサーバーよりも多くのパケットを送信した回数
16. クライアント側から送信された総バイト数
17. クライアント側で送信されたアプリケーションレベルの負荷の合計量
18. クライアント側で送信されたトランスポート層セグメントの総数
19. クライアントから送信されたデータの総数
20. サーバー側から送信された合計バイト数
21. サーバー側から転送されたアプリケーションレベルの負荷の合計量
22. サーバー側で送信されたトランスポート層セグメントの総数
23. サーバー側から転送されたデータの部分の総数
24. クライアント側のトランスポート層の最初のセグメントのサイズ
25. クライアント側のトランスポート層の2番目のセグメントのサイズ
26. サーバー側のトランスポート層の最初のセグメントのサイズ
27. サーバー側のトランスポート層の2番目のセグメントのサイズ
28. クライアントからのデータの最初の部分のサイズ
29. クライアントからの2番目のデータのサイズ
30. サーバー側のデータの最初の部分のサイズ
31. サーバー側からの2番目のデータのサイズ
32. トランスポート層プロトコルタイプ（0-UDP、1-TCP）

次に、いくつかのポイントを明確にする必要があります。

まず、「合計X」という形式の兆候はそれ自体が不安定です。これは、その値がストリームを観察する時間に依存するためです。 観察すればするほど、より多くのバイト、アプリケーションの負荷、セグメント、データが転送されます。 これらのインジケータに確実性を追加するために、将来、観測の開始から終了までのストリーム全体ではなく、トランスポートレベルの最初のNセグメントに沿った各ストリームの一部を考慮します。 リストされたすべてのメトリックを計算する場合、最初のN個のセグメントのみを使用します。

第二に、第1セグメントと第2セグメントのサイズ、および各側のデータの部分に関して、理由が明らかでない場合があります。 このトピックに関する科学論文の1つ（ソース内のリンク）に示されているように、最初のいくつかのIPパケットのサイズは、使用されているプロトコルに関する多くの情報を運ぶことができます。 したがって、これらのインジケータは冗長ではありません。

ここで、特定のストリームのアプリケーションレベルのプロトコルを推測する方法を決定し、手元に統計メトリックを計算します。 ここでは機械学習が役立ちます。 検討中の問題は、その古典的な定式化では、オブジェクトをいくつかのクラスに分類するタスクです。

各オブジェクトには最大32個の特性があり、研究のこの段階でのオブジェクトのクラスラベルに対するそれらのそれぞれの関連性は問題のままです。 したがって、一般的なランダムフォレスト機械学習アルゴリズムを選択することをお勧めします。これは、ノイズと特徴の相関に弱いためです（統計メトリックの一部は高度に相関している可能性が高い）。

このアルゴリズムは、「教師による指導」に基づいて機能します。 これは、クラスラベルが既知のオブジェクトの選択が必要であることを意味します。 このサンプルを1対2の比率でトレーニングと検証に分けます。 トレーニングサンプルでは、​​モデルトレーニングを実施し（この場合、トレーニングは決定木のセットを構築することから成ります）、テストサンプルでは、​​モデルがタスクにどれだけうまく対処できるかを評価します。

収穫時間

実験の方法論では、すべてが明確になったため、トラフィック自体を見つけることは残っています。トラフィックの特性は、計算の対象となります。

もちろん、ネットワークにトラフィックを収集できるプロバイダーはありません。そこで収集するデータを誰が知っていますか？ 職人的条件で管理します。 数日間、私は自分のコンピューターのトラフィックのキャプチャに費やし、途中でいつものことをしていました-私はVKにいて、Youtubeでビデオを見、Skypeで電話をかけ、いくつかのトレントをダウンロードしました。 その結果、3 GBを超えるトラフィックがキャプチャされます。

ここで、トラフィック自体に加えて、キャプチャされたストリームごとに、それによって運ばれるアプリケーションレベルのプロトコルを確実に決定する必要があることを思い出してください。 そして、ここでDPIツールは、特にnDPIライブラリに役立ちます。 このライブラリには、ndpiReaderと呼ばれるトラフィックアナライザーの例が含まれています。これは便利です。 すばらしいボーナスは、このアプリケーションがすべての生のトラフィックダンプをトラフィックレベルのストリームに分割するため、これを行う必要さえないことです。

しかし、それでも、pcapファイルの腸を掘る必要があります。 これを行うには、dpktライブラリを使用します。 残念ながら、Pythonの第3バージョンに移植されていないため、言語の第2バージョンでpcapファイルを処理するためのスクリプトを作成します。

上記のすべてをまとめて、PCAPファイルを属性のテーブルに変換し、CSV形式にエクスポートするスクリプトを作成します。 記事の最後にあるこのスクリプトを使用して、リポジトリにリンクします。

今何時？ 分類時間！

はい、はい、ついにすべてがうまくいくようになりました！

ただし、属性テーブル全体を船からボールまで、最初のランダムフォレストにプッシュする前に、データをもう少し注意深く調べます。 サンプルにあるアプリケーションプロトコルと各プロトコルのスレッド数のリストは次のとおりです。



最初に行うことは、すべてのSSL_No_CertトラフィックをSSLにマージすることです。これは本質的に同じことだからです。

2つ目は、Apple、NTP、Unencrypted_Jabber、およびUnknownトラフィックを破棄することです。 最初の3つのプロトコルには分類するスレッドが少なすぎるため、Unknownは何でも隠すことができます。

次に、データをトレーニングサンプルとテストサンプルに分割します。 次のレイアウトを取得します。



いくつかの実験の後、次の値がランダムフォレストアルゴリズムのパラメーターとして選択されました。

• 木の本数：27
• 基準：エントロピー
• 最大ツリー深度：9

統計的特性のいくつかは、各ストリームで考慮中のトラフィック量を修正する必要があることを思い出してください。 開始するには、より大きなトラフィックカット（各ストリームの最初の1000セグメント）を使用します。 統計指標により、アプリケーション層のプロトコルを予測できるかどうかを確認します。 ドラムロール！



上記は、各クラスの予測の精度と完全性の表です。 クラスKの精度は、「オブジェクトXはクラスKに属している」という形式の予測のうち、真であることが判明した部分です。 クラスKの完全性は、クラスKに属するものとして分類器によって認識されるオブジェクトXの数を、クラスKに属するオブジェクトの総数で割ったものです。 Fメジャー-完全性と精度の調和平均。

さて、少しシンプルなテーブル：



ここでは、各セルに番号が示されています。これは、行ヘッダーで指定されたクラスに属するトラフィックフローが列ヘッダーで指定されたクラスに属すると分類されたケースの数を意味します。 つまり、主対角線上の数字は正しい分類であり、それ以外の数字はあらゆる種類のエラーです。

一般に、分類器はうまく機能しているようです。 まれなエラーを除き、すべての予測は正しいです。

ランダムフォレスト機械学習アルゴリズムは、どの機能が他の機能よりも有用であるかに関する情報を提供できるため、優れています。 好奇心から、最も重要な兆候を見てみましょう。



クライアント側の統計的特性に結び付けられた記号で安定して占有されているトップ。 このことから、異なるアプリケーションのクライアントが最も大きく、サーバーが最も小さいと結論付けることができます。

サーバーから、2番目のパケットのサイズだけが削除されました。 これは、証明書が2番目のサーバーパケットで送信されるため、2番目のパケットのサイズによってSSLを他のすべてのトラフィックと区別することが非常に簡単であるという事実によって簡単に説明できます。

トランスポート層プロトコルのタイプが最も重要な標識のトップ10にのみ含まれていることは驚くべきことです。ただし、この標識には多くの情報が含まれているように見えます。 これは、統計メトリックにさらに多くの情報があることを意味します。

また、疑似乱数ジェネレータのシードが変更されると、最も重要な記号の上部がわずかに変更されることに注意してください。 顧客固有のメトリックは最上部で安定していることが一般的ですが、その順序は変化しています。 また、トランスポートレイヤープロトコルは、1位から10位にジャンプします。

今から楽しい部分です。 その前に、各ストリームの最初の1000セグメントのスライスを取得し、このスライスに基づいて統計メトリックを計算しました。 論理的な疑問が生じます。このセクションをどれだけ減らしても、適切な分類指標を取得できますか？

答えは落胆です。 各スレッドのセグメント数を... 3に減らすことができます。 もちろん、TCPハンドシェイクは含まれていません。これは、情報を一切伝送しないためです。

以下は、各クラスの完全性と正確性の値、実際のクラスと予測されたクラスの表、およびトランスポートレイヤーの最初の3つのセグメントのみでモデルを構築およびテストする際の最上の特性です（TCPの場合、これは実際には6セグメントで、最初の3つは破棄されます）。







注意深い読者は、サンプルのレコードの総数が前のケースと比較して少なくなっていることに気付くかもしれません。 実際には、ほとんどの特性を計算するために、クライアントから少なくとも1つのデータと、サーバーから少なくとも1つのデータが必要です。 最初の3つのセグメントで、クライアントのみまたは送信されたサーバーのみが送信されたことが判明した場合、そのようなストリームは、符号の表をコンパイルする段階でも破棄されます。

各ストリームのセグメント数が急激に減少したため、分類の品質は低下せず、わずかに改善されただけであったため、結果は予想外でした。 これは、アプリケーションのタイプに関する最大の情報を伝送する最初の送信セグメントであるという事実に関連しています。 したがって、セグメントの数が減少すると、統計メトリックはすべてではなく最初のセグメントに関する情報のみを伝達し始め、分類の質がわずかに向上します。

おわりに

この記事では、DPIツールなしでアプリケーション層プロトコルを決定するために、十分に高品質のトラフィック分析を実行する方法を明確に示しました。 特徴的なことは、トランスポート層の最初の数個の送信セグメントによってアプリケーションプロトコルを正確に決定することです。

開発されたコードはすべてgithubリポジトリに投稿されます 。 リポジトリのreadmeには、記事で得られた結果を繰り返す方法についての説明があります。 csvフォルダーには、収集されたPCAPファイルの処理後に取得された属性テーブルが含まれています。 しかし、PCAPファイル自体は見つかりません。すみませんが、私のデータの機密性は何よりも重要です。

分類器の動作をリアルタイムで視覚的に示すために、 PyQt4で簡単なアプリケーションを開発しました。 そして彼の仕事を示すビデオさえ記録しました。

なぜこのアプローチを使用できるのですか？ たとえば、ペイロードが暗号化されている場合（こんにちは、パラノイア）、これらの条件で使用されているアプリケーションレイヤープロトコルを特定します。 または、この分析が必要な場合の分析のための統計の事前収集のために-結局、アプリケーション層プロトコルを決定するには、ストリームごとに256バイトの情報（32の浮動小数点数）だけで十分です。

謝辞

Daniil ProkhorovとNadezhda Troflyaninaに感謝します。このアイデアを開発し、トラフィックを収集し、VII MTUCI Youth Scientific Forumで講演しました。

ソース

私たちがインスピレーションといくつかの良いアイデアを引き出した科学的作品を示さないことは間違っているでしょう：

1. 分かりにくいインターネットトラフィック分類：識別力の源について
2. 相関情報を使用したSVMベースのネットワークトラフィック分類
3. ベイジアン解析手法を使用したインターネットトラフィックの分類