DDoS Protection では、 Gcoreは XDP と正規表現 (regex) のバンドルを使用します。この記事では、Gcore がこのソリューション (XDP の正規表現) を使用し始めた理由と、サードパーティ エンジンと API 開発を介してそれらをバインドする方法について説明します。

さらに、XDP で正規表現を処理し、結果をベンチマークするためのオープンソース ソリューションについても説明します。

XDP フレームワークを使用する理由

DDoS 保護サービスの初期の段階では、DPDK (高速パケット処理用の Linux フレームワーク) を実行する少数の専用サーバー (ノード) で運用し、正規表現でトラフィックをフィルタリングしていました。このテクノロジーを使用することで、このバンドルのおかげでクライアントのアプリを保護することに成功しました.しかし、DDoS 攻撃の容量が 2021 年の 300 Gbps から 2022 年の 700 Gbps に増加したため、基盤となるインフラストラクチャが最終的に不十分であることが判明しました。

DPDK が効果的に機能するには、排他的なネットワーク アダプター アクセスが必要です。このように、それを他の用途と統合することは非常に困難 (かつ不合理) であり、不可能なほどです。これにより、既存のインフラストラクチャを変更せずに拡張する場合、DPDK 用の新しい専用ノードを取得する必要があります。 Gcore は、これは費用対効果の高いオプションではないと結論付け、それを見つけることに着手しました。

Gcoreは、DDoS 保護サービスに加えて、1,000 を超える CDN ノードで構成されるコンテンツ配信ネットワーク (CDN) インフラストラクチャも提供しています。したがって、ノードが増えるほど、ますます強力な攻撃者に対するセキュリティが向上するため、コンテンツ配信とトラフィック スクリーニングにこれを採用し始めることは理にかなっています。

DPDK は CDN ノード (専用ノードが必要) では動作しないため、Gcore は代わりに XDP フレームワークを使用することを選択しました。彼らは、以前のバージョンからの主な改善点は、他のアプリケーションとのスタックへの統合がいかに優れているかであると主張しています。 DDoS Protection は、以前は DPDK を備えた専用サーバーでのみ利用可能でしたが (図 1)、CDN サーバーに統合できるようになり (図 2)、スケーラビリティが向上しました。

図 1 専用サーバー（DPDK）による DDoS 保護???????
図 1 専用サーバー (DPDK) による DDoS 保護
出典：Gコア

 

図 2 CDN サーバーに統合された DDoS 保護 (XDP)
図 2 CDN サーバーに統合された DDoS 保護 (XDP)
出典：Gコア

 

Gcore が XDP を有用だと考える理由:

  • コスト効率。このフレームワークは、Web サーバーや DNS サーバーなどのエッジ ネットワーク アプリケーションを備えたサーバーにインストールできるため、高価な専用機器は必要なく、開発者は他のアプリケーションを XDP と統合するために何時間も費やす必要がありません。
  • 攻撃検出速度。このフレームワークは、何百もの CDN サーバーにインストールできます。これは、DDoS Protection がクライアント アプリケーションや悪意のあるトラフィック ソースにより近いことを意味します。その結果、攻撃はより迅速に阻止され、インフラストラクチャに深く入り込むことはありません。

ただし、いくつかの欠点もあります。

  • パフォーマンスが低下します。 XDP で分離されたノードは、DPDK と比較してパフォーマンスが低くなりますが、より多くのノードが組み込まれているため、ソリューションの全体的な効率は最終的に高くなります。
  • 正規表現を処理できない。 XDP には正規表現を処理するエンジンが組み込まれていないため、正規表現処理を XDP に適応させるソリューションを考え出す必要がありました。

Gcore が正規表現を使用してトラフィックをフィルタリングし続けた理由

DDoS Protection で悪意のあるトラフィックを除外するには、パケット パーサーと正規表現 (regex) の処理の 2 つの方法があります。

パケット パーサーは、特定のプロトコルを使用するアプリケーションで疑わしいアクティビティを検出してブロックするようにプログラムされた、手動で作成されたフィルターです。このようなパケット パーサーを作成するには、特に DDoS 保護が新しいプロトコルを迅速に受け入れる必要がある場合、多くのプログラミング作業が必要です。

パケット ペイロードの分析に基づいて正規表現を処理すると、パケット パーサーのアプローチと比較して、フィルターの作成にかかる時間が短縮されます。さらに、これはより柔軟なアプローチであり、より低いカーネル負荷でパケットをより効率的に処理できます。

顧客のアプリケーションに送信されるパケットは、次の 2 つのモードでチェックされます。

  • 攻撃への反応 (手動モード)。特定のペイロード (パターン) によって生成された悪意のあるトラフィックを分析します。次に、このペイロードを指す正規表現を作成し、トラフィックに適用します。同様のペイロードを含むすべてのリクエストは、自動的にフィルタリングされます。
  • ゲーム接続保護モード。多くの Gcore クライアントは、UDP プロトコルを介したリクエストと小さいパケット サイズを特徴とするオンライン ゲーム サービス プロバイダーです。ゲーム サービスに追加されるパッケージは、正規表現を使用して記述できる厳密な構造を持っています。クライアントのゲーム サービスごとに正規表現を作成し、それを使用してパケットの許可リストを作成します。正規表現に一致するすべてのパケットが許可されます。パケットが異なる場合、それらはブロックされます。

正規表現を使用する場合のパケット処理は、次のように配置されます。
  1. 解剖者。各パケットを分析し、ヘッダーに分割します。
  2. フロールーター。パケットを適切な保護プロファイルにルーティングします。これは、トラフィック保護の一般的なルール セットです。
  3. ポリシー パイプライン。コンポーネントに分解されたパケットに特別なルール (対策) を適用します。対策の1つとして、正規表現の使用があります。
  4. 評決。対策チェックに基づいてパケットをスキップまたはブロックします。

Gcore が XDP コンテキストで正規表現処理を適応させる方法: 課題と解決策

正規表現の処理はリソースを大量に消費するプロセスであり、 Gcoreは何百万ものパケットをチェックし、さまざまな複雑さの正規表現を使用すると主張しています。これにより、パフォーマンスは正規表現エンジンの必須要件であると結論付けました。

利用可能な最高のエンジンは、Intel によって設計された Hyperscan です。 GPL と互換性のあるライセンスを備えたオープンソースであり、AVX2/AVX512 ベクトル命令セットを使用し、DPI アプリケーションの業界標準として使用されているため高速です。

XDP で正規表現処理を適応させるために、以下に説明するいくつかの課題に直面しました。

課題 1. eBPF の制限により、正規表現フィルターを XDP プログラムの一部として実装することはできません。

解決。 Gcore は、Hyperscan エンジンを、eBPF ヘルパーを提供するロード可能な Linux カーネル モジュールとして再構築しました。 Hyperscan は、DPI (ディープ パケット インスペクション) システムで正規表現を処理するように設計されたエンジンで、パケットのペイロードが定義済みの正規表現と一致するかどうかをチェックします。

課題 2.ロード可能なモジュールの eBPF ヘルパーを XDP に登録できません。

解決。ロード可能なモジュールの eBPF ヘルパーは Linux 5.16 で初めて導入されましたが、Linux 5.18 まで XDP に登録することはできませんでした。 Gcore は開発中に Linux 5.17 しか持っていなかったため、その可能性を提供する必要がありました。メインライン カーネル ビルドでは、そのようなパッチは必要ありません。

課題 3.ベクトル命令 (FPU) は、Linux カーネルでのパケット処理中に使用されることは想定されていませんでした。

解決。正規表現処理のためにモジュールに入るときに、FPU レジスタの状態を保存および復元します。正規表現処理が不要な他のパケットに影響を与えることなく、必要に応じてパケットごとにこれを実行します。

Gcore がコミュニティに提供するオープンソース ソリューション: XDP で正規表現を処理するための eBPF API

インフラストラクチャで XDP の正規表現を処理する必要がある場合は、ゼロから作成するのではなく、開発者が提供する既製のソリューションを使用できます。

彼らのカスタム eBPF ヘルパー ‘bpf_xdp_scan_bytes()’ は、他の eBPF ヘルパーと同じ方法で使用できるようになりました。

struct rex_scan_attr attr = { .database_id = regex_id, .handler_flags = REX_SINGLE_SHOT, .nr_events = 0, .last_event = {}, }; err = bpf_xdp_scan_bytes(xdp, payload_off, payload_len, &attr); if (err < 0) return XDP_ABORTED; return (attr.nr_events > 0) ? XDP_DROP : XDP_PASS

パケット バッファに対して正規表現を評価するには、最初に正規表現をローダブル モジュールに追加し、eBPF ヘルパーを呼び出すときにその識別子を参照します。

  1. /sys/kernel/config/rex の下に mkdir を使用してノードを作成します。
  2. パターン データベースをコンパイルします。 
     echo '101:/foobar/' > patterns.txt echo '201:/a{3.10}/' > patterns.txt build/bin/hscollider -e patterns.txt -ao out/ -nl
  3. コンパイルされた正規表現を /sys/kernel/config/rex/<node>/database にアップロードします。 
     dd if=$(echo out/".db) of=/sys/kernel/config/rex/hello/database
  4. /sys/kernel/config/rex/<node>/id で新しい正規表現識別子を読み取るか設定します
  5. 正規表現識別子を eBPF プログラムに転送し、ヘルパー引数として使用します。

完全なソース コードは、Gcore GitHub アカウントのリンクから入手できます: https://github.com/G-Core/linux-regex-module

Gcore は XDP での正規表現の使用に関してどのようなベンチマークを持っていますか

同社の DDoS フィルタリング ソリューションは、第 3 世代 Intel® Xeon® スケーラブル プロセッサと 100GbE Intel® Ethernet Network Adapter E810 に基づいています。 Intel® Hyperscan は、データ ストリーム全体で高性能なパターン マッチングを可能にしました。

インテル® は、パケット・フィルタリングに使用された XDP テクノロジーなど、専門家の洞察を提供しました。彼らによると、最新の第 3 世代 Intel® Xeon® Scalable プロセッサで新しいソフトウェアを使用すると、フィルタリング容量が 100 Gbps から最大 400 Gbps または 2 億パケット/秒に増加しました。

以下のチャートでは、独自のテストの結果を確認できます。

パケットサイズのチャート

  • ラインレート (青い線) は、4 × 100 Gbps インターフェイスの最大ネットワーク スループットです。
  • ベース (赤い線) は、XDP が正規表現を使用せずにそれをどのように処理したかの尺度です。
  • 下の 3 行は、正規表現を使用した場合のパケット処理です。

結論。 512 バイトを超えるパケット サイズでは、システムはライン レートの速度で動作し、トラフィックを効果的にフィルタリングできます。 512 バイトより小さいパケットでは、パケット レートとシステムの負荷が非常に高くなり、システムはラインレート パフォーマンスを維持できず、ライン レート速度の約 40 ～ 50% で動作します。

Gcoreはこれらの結果に本当に満足しています。小さなパケットを処理するパフォーマンスはそれほど高くありませんが、彼らのデータに基づいて、それらは私たちに適しています.実際の DDoS 攻撃は大きなパケットを使用する傾向があるため、効率と速度は十分許容範囲です。

テストによると、XDP での正規表現の使用は重いプロセスの処理に適していますが、大量のトラフィックを処理するのに十分な速度を備えています。

Gcoreによる後援および執筆