DDOS 保護を強化するために XDP/EBPF を効果的に管理する方法

Extended Berkeley Packet Filter ( eBPF ) は迅速かつ継続的に更新できるため、頻繁なセキュリティ構成変更の処理に最適です。

著者 Ivan Koveshnikov のHow to Manage XDP/eBPF Effectsing for Better DDoS Protectionから翻訳されました。

Extended Berkeley Packet Filter ( eBPF ) マップは、共有メモリとして使用される共有メモリセグメントのアトミックな更新のための高レベルインターフェイスとして機能し、eBPF プログラムに強力な構成インターフェイスを提供します。読み取り、コピー、更新のメカニズムにより、ホットパスでのパフォーマンスのオーバーヘッドが最小限に抑えられます。さらに、eBPF マッピングにより、共有メモリセグメントへの排他的アクセスが可能になります。混合マップタイプ (配列、ハッシュテーブル、ブルームフィルター、キュー、リングバッファー) を処理できるため、セキュリティなどの複雑な構成に最適です。

構成が複雑になるにつれて、異なるマッピングエントリ間の接続の必要性も高まります。マップエントリ間の接続が多すぎると、アトミックな構成更新を行う機能が低下し始めます。 1 つのマップエントリのみを更新すると、他のエントリも同時に更新する必要がある可能性があり、更新中に不整合が発生する可能性があります。

XDP を適用して高度なトラフィック管理を実現

優先順位 5 タプルのルールセットに基づいてトラフィックを分類およびフィルタリングする単純なeXpress Data Path (XDP)プログラムを考えてみましょう。プログラムは、ルールの優先順位と、パケットの送信元 IP アドレス、宛先 IP アドレス、プロトコル、送信元ポートと宛先ポートの組み合わせに基づいて次のパケットを処理します。

分類から処理までのフローチャート。

以下はネットワーク構成ルールの例です。

サブネット A からのトラフィックは常に許可されます。
サブネット C のクライアントがサブネット B の Web サーバーにアクセスすることを制限します。
サブネット B の Web サーバーへのアクセスを制限します。
他のすべてのアクセスは拒否されます。

これらのルールでは、トラフィック分類ルールと制限を設定に保存する必要があります。これは、eBPF マッピングを使用することで実現できます。

eBPF プログラム構成をツリー構造として理解する

「構成ルート」をベースとした階層ツリーとして構成を視覚化できます。このルート (おそらく仮想) は、さまざまな構成エンティティを編成してアクティブな構成を形成します。エンティティは、即時グローバルアクセスのためにルートに直接接続されるか、構造化された組織のために他のエンティティ内にネストされます。

特定のエンティティへのアクセスはルートから開始され、目的のエンティティに到達するまで順番に (各レベルを「逆参照」して) 進行します。たとえば、コレクション内の「オプション」構造体からブール型フラグを取得するには、コレクションに移動し、構造体を見つけて、フラグを取得します。

eBPF の複雑さの課題に対処するための Gcore のアプローチ

このツリー構造は、サブツリーのアトミックスワップを含む構成管理の柔軟性を提供し、中断のないスムーズな移行を保証します。ただし、複雑さが増すと課題が生じます。構成が複雑になるにつれて、エントリはより相互接続されます。複数の親エントリが 1 つの子エントリを指すこと、または 1 つのエントリがエンティティのプロパティとコレクションの一部として二重の役割を果たすことが一般的です。

最新のプログラミング言語は、複雑な構成を管理するためのメカニズムを開発しました。開発者は、参照カウンター、変更可能および不変更の参照、ガベージコレクターを使用して、安全な更新を保証します。ただし、これらの構成のセキュリティを管理しても、構成バージョン間の切り替え時のアトミック性は保証されません。

オンライントラフィックの状況は常に変化しているため、セキュリティ運用チームはセキュリティポリシーを頻繁に変更する必要があります。したがって、Gcore はGcore DDoS 保護を迅速かつ頻繁に更新し、正規表現エンジンなどの重要な機能を組み込みました。セルフホスト型ソリューションの標準的な 1 日あたり 1 回または 2 回の更新を超えて、サービスプロバイダーが必要とするほぼ一定の更新に移行しました。 Linux アプリケーションでは見落とされがちなこの要件により、高速で中断のない更新を可能にする eBPF テクノロジーが採用されました。

eBPF ソリューションを検討するときは、eBPF 構成が可能な限り最良の方法で処理されることを保証するための戦略を徹底的に検討する必要があります。具体的には、eBPF マッピングの制限により、私たちのチームは構成ストレージ戦略を再考する必要がありました。

カーネルのセキュリティ検証により、eBPF マップエントリは任意のメモリセグメントへの直接ポインタを保存できないため、マップエントリにアクセスするために検索キーが必要となり、ルックアッププロセスが遅くなります。しかし、この欠点には利点があります。これにより、複雑な構成ツリーを、構成ルートに直接リンクされた、より小さく管理しやすいセグメントに分割できるようになります。結果は何ですか？非アトミック更新時でも一貫性。

私たちの調査結果と戦略は、効率を最適化するための eBPF プログラムの慎重な計画と実行の重要性を強調しています。それでは、eBPF 環境の具体的な構成更新戦略と、システム固有の要件と制限に対するその適用可能性について見ていきましょう。

セキュリティ構成更新ポリシー

高いパフォーマンスと柔軟性を確保しながらプログラムの更新を強化するには、3 つの更新戦略が特に効果的であることがわかりました。

アップデート戦略 1: 段階的な移行

段階的な更新戦略とは、複数のマッピングにわたって増分構成を更新することを意味します。これは、あるマップのデータを処理して別のマップの検索キーを提供するときに便利なオプションです。この場合、複数のマップエントリを更新する必要があり、アトミック変換は実行できません。ただし、正確かつ順次的な更新操作により、構成を系統的に更新できます。参照された構成サブツリーに対する一部の操作は、正しい順序で実行すると安全になります。

たとえば、分類と処理のコンテキストでは、分類レイヤーは、一致するセキュリティポリシーの検索キーを提供します。これは、更新操作が特定の順序に従う必要があることを意味します。

新しいセキュリティポリシーはまだ参照されていないため、安全に挿入できます。
また、既存のセキュリティポリシーを個別に更新しても通常は問題が発生しないため、安全に更新できます。アトミックな更新は望ましいものですが、大きな利点はありません。
新しいセキュリティポリシーを参照するように分類層マッピングを更新し、古いポリシーへの参照を削除しても安全です。
未使用のセキュリティポリシーが参照されなくなったら、構成から削除しても安全です。

アトミック更新を行わない場合でも、更新プロセスを適切に順序付けすることで安全な更新を実行できます。この方法は、他のマッピングと密接な関係がないスタンドアロンマッピングに最適です。

マップ全体を一度に更新するのではなく、増分更新を実行することをお勧めします。たとえば、ハッシュマップと配列の増分更新は完全に安全です。ただし、Longest Prefix Match (LPM) マップの増分更新の場合は、ルックアップがマップ内に既に存在する要素に依存するため、これは当てはまりません。別のテーブルのルックアップキーを作成するときに、複数のマップの要素を操作する必要がある場合にも、同じ問題が発生します。

分類レイヤーは多くの場合、複数の LPM とハッシュテーブルを使用して実装されます。この複雑さの例は次のとおりです。

ルックアップは、マッピング更新の問題の説明とともに、分類から LPM およびハッシュ化、分類から処理、ハッシュ化へとフローします。

更新戦略 2: マッピングの置換

不整合を生じずに増分更新できないマッピング (LPM マッピングなど) の場合、マッピング全体を置き換えるのが最善の解決策です。 eBPF プログラムのマッピングを置き換えるには、マッピングのマッピングが必要です。ユーザー空間アプリケーションは、新しいマップを作成し、それに必要なエントリを入力して、古いマップをアトミックに置き換えることができます。

マップされたマッピングにより、リソースの分離機能と置換機能を備えた 2 つのノードが作成されます。

構成を個別のマップに分割し、それぞれが 1 つのエンティティの設定を記述することで、リソースの分離という追加の利点が得られ、マイナーアップデートの際に完全な構成を再作成する必要がなくなります。複数の各エンティティの構成は、置換可能なマップに保存できます。

この方法にはいくつかの欠点があります。置換マッピングは以前のマッピングと同じ場所に固定できないため、ユーザー空間は以前の固定パスを維持するために以前のマッピングの固定を解除する必要があります。これは、構成を頻繁に更新し、安定性のためにマップの固定に依存する長期的なプログラムの場合に特に重要です。

更新戦略 3: プログラムの置き換え

複数のマップをリンクすると、マップ置換メソッドが失敗する場合があります。マッピングのみを更新すると、古い構成も予期された新しい構成も反映されない、矛盾した状態または無効な状態が発生する可能性があります。

この問題を解決するには、アトミックな更新をより高いレベルで実行する必要があります。 eBPF には一連のマッピングをアトミックに置き換えるメカニズムがありませんが、通常、マッピングは特定の eBPF プログラムにリンクされています。この問題は、相互接続されたマッピングと対応するコードを末尾呼び出しでリンクされた個別の eBPF プログラムに分割することで解決できます。

パケットパイプラインからプログラムへのマッピングフローチャート。結果として、eBPF プログラムの置き換え可能なコードとマッピングパッケージが得られます。

これを実現するには、新しい eBPF プログラムをロードし、そのマッピングを作成して設定し、両方を固定してから、ユーザー空間からプログラムマッピングを更新する必要があります。このプロセスは単純なマッピングの置換よりも手間がかかりますが、マッピングと関連コードを同時に更新できるため、実行時コードの調整が容易になります。ただし、このアプローチの使用は、特に複数のマップとサブルーチンを使用して複雑なプログラム内の 1 つのマップエントリを更新する場合に、必ずしも効率的であるとは限りません。

エラー処理

eBPF を管理する際のエラーの処理は難しい場合があります。不整合を防ぐために構成を更新することが重要です。更新中にエラーが発生すると混乱が生じる可能性があるため、自動バックアップを使用すると、手動で修正する必要性を減らすことができます。

エラーは、回復可能なエラーと回復不可能なエラーの 2 つのカテゴリに分類できます。回復可能なエラーの場合、更新中に問題が発生した場合、更新を停止するだけで変更は加えられません。リスクを負わずにバグを修正できます。

回復不可能なエラーは少し複雑です。これらは特定の構成エンティティに影響を与え、システム全体に損害を与える可能性があるため、慎重に扱う必要があります。

更新の種類ではなく、構成エンティティごとに更新を整理することをお勧めします。こうすることで、エラーが発生した場合、一度にすべてではなく、特定の構成エンティティにのみ影響します。たとえば、分類ルールとセキュリティポリシーが異なるネットワークセグメントに対して定義されている場合、更新タイプごとではなく、ネットワークセグメントに基づいて別のサイクルでそれらを更新する方が効率的です。これにより、自動バックアップの処理が容易になり、回復不可能なエラーが発生した場合に、その影響を正確に知ることができます。ネットワークの一部だけが一貫性のない構成になっていますが、残りの部分は影響を受けないか、新しい構成にすぐに切り替えることができます。

eBPF プログラムの更新ライフサイクルを管理する

eBPF プログラムのライフサイクルを追跡することは、異なるコードインスタンス間での永続性、頻繁な更新、および状態の保持を必要とするプログラムにとって重要です。たとえば、XDP プログラムが既存のクライアントセッションを維持しながらコードを頻繁に更新する必要がある場合、そのライフサイクルを効果的に管理することが重要です。

柔軟性を最大限に高め、制約を回避したい開発者にとって、目標は、リロードの間に重要な情報、つまり不揮発性ストレージから取得できないデータのみを保持することである必要があります。このようにして、eBPF マッピングを使用して動的構成を調整できます。

ホットコードのリロードプロセスをより簡単にするには、状態マップと構成マップを区別し、リロード中に状態マップを再利用し、不揮発性ストレージから構成マップを再設定できる必要があります。古いプログラムから新しいプログラムに処理を移行し、すべての eBPF マッピングユーザーに変更を通知するのは少し面倒な場合があります。

トランジションを実装するには 2 つの一般的な方法があります。

アトミックプログラム置換: この方法では、XDP プログラムをネットワークインターフェイスに直接接続し、更新中にそれをアトミックに交換します。これは、多数のユーザー空間プログラムやマップと対話する大規模で複雑な eBPF プログラムには最適ではない可能性があります。
libxdp のようなアプローチ: スケジューラープログラムはネットワークインターフェイスにリンクし、末尾呼び出しを使用して、実際の処理が行われるプログラムマップ内の次のプログラムで処理を実行します。マップの使用と固定の管理に加えて、複数のハンドラーを調整し、ハンドラー間の高速な移行を可能にします。

ネットワークインターフェイスカード (NIC) は、スケジューラ、プログラムマップ、および状態マップに接続し、実際のプログラム構成を実現します。

ホットリロードプロセスは、構成の問題を迅速に検出して修正し、必要に応じて以前の安定したバージョンにすぐに戻します。 A/B テストなどの複雑なシナリオの場合、スケジューラーは分類テーブルを使用して、特定のトラフィックを XDP プログラムの新しいバージョンに送信できます。

結論は

eBPF/XDP プログラミングを通じて、Gcore はネットワークセキュリティとパフォーマンスの最適化の限界を押し広げました。私たちのこれまでの歩みは、高度な eBPF/XDP 機能を通じて新たな脅威と戦うという私たちの取り組みを示しています。当社はパケット処理コアの改善を継続するとともに、お客様のネットワークの堅牢性と俊敏性を維持するのに役立つ最先端のソリューションを提供することに取り組んでいます。

この記事はYunyunzhongsheng ( https://yylives.cc/ ) で最初に公開されたもので、どなたでもご覧いただけます。