NGINX App Protect DoS で深刻な DoS 攻撃から gRPC アプリを保護します

過去 2 年間の商品やサービスに対する顧客の需要は、組織が容易に拡張し、より迅速に革新することがいかに重要であるかを強調しており、多くの組織がモノリシック アーキテクチャからクラウド ネイティブ アーキテクチャへの移行を加速させています。 最近の F5 レポート「application戦略の現状 2021」によると、applicationsを最新化する組織の数は、昨年だけで 133% 増加しました。 クラウド対応applicationsは、モジュール化、分散、展開、管理が自動化されるように設計されています。 既存のモノリシックapplicationを単純にリフト アンド シフトすることも可能ですが、コストや柔軟性の面で利点はありません。 クラウド コンピューティング サービスが提供する分散モデルからメリットを得る最善の方法は、モジュール化して考えることです。つまり、マイクロサービスを導入することです。

マイクロサービスは、開発者が、互いに、また基盤となるプラットフォームから構造的に独立した一連の軽量applicationサービスとしてapplicationを構築できるようにするアーキテクチャ アプローチです。 各マイクロサービスは独自のプロセスとして実行され、明確に定義され標準化されたAPIを介して他のサービスと通信します。 各サービスは、小規模な独立したチームによって開発および展開できます。 この柔軟性により、組織はパフォーマンス、コスト、スケーラビリティ、迅速なイノベーション能力の面で大きなメリットを得ることができます。

開発者は常に、効率を高め、applicationの展開を迅速化する方法を求めています。 API はソフトウェア間の通信を可能にし、開発のための構成要素を提供します。 HTTPを使用してサーバーからデータを要求するために、Web 開発者は当初、要求の詳細をXMLドキュメントで送信するSOAPを使用していました。 ただし、XML ドキュメントはサイズが大きくなり、かなりのオーバーヘッドが必要になり、開発に長い時間がかかります。

それ以来、多くの開発者が、ステートレスで信頼性の高い Web API を作成するためのアーキテクチャ スタイルとガイドライン セットであるRESTに移行しました。 これらのガイドラインに従う Web API は RESTful と呼ばれます。 RESTful Web API は通常、URL エンコードされたパラメータを介してリソースにアクセスし、 JSONまたは XML を使用してデータを送信するための HTTP メソッドに基づいています。 RESTful API を使用すると、applicationsの開発が速くなり、オーバーヘッドが削減されます。

テクノロジーの進歩により、application設計を進化させる新たな機会が生まれます。 2015 年に Google は、あらゆる環境で実行できる最新のオープンソース RPC フレームワークとして、Google Remote Procedure Call ( gRPC ) を開発しました。 REST は HTTP 1.1 プロトコル上に構築され、要求応答通信モデルを使用しますが、gRPC はトランスポートにHTTP/2を使用し、通信のクライアント応答モデルを使用します。これは、サービスとデータを記述するために使用されるインターフェース記述言語 (IDL) としてプロトコル バッファー(protobuf) に実装されています。 Protobuf は構造化データをシリアル化するために使用され、シンプルさとパフォーマンスを重視して設計されています。gRPC は、protobuf の効率性と HTTP/2 の使用により、データ受信時には REST より約 7 倍、データ送信時には 10 倍高速です。gRPC ではストリーミング通信も可能で、複数のリクエストを同時に処理できます。

開発者は、低レイテンシ、複数言語のサポート、コンパクトなデータ表現、リアルタイム ストリーミングなどの理由から、RESTful API を使用する代わりに gRPC を使用してマイクロサービスを構築することを魅力的な選択肢と見なしています。これらの理由により、gRPC はマイクロサービス間の通信や低電力、低帯域幅のネットワークでの通信に特に適しています。gRPC は、信頼性とスケーラビリティが高く、クライアントとサーバーの両方で言語に依存しない、新しいサービスを迅速かつ効率的に構築しやすくするため、人気が高まっています。

gRPC プロトコルのオープンな性質にはいくつかの利点がありますが、この標準では、DoS 攻撃がapplicationに及ぼす影響からの保護は提供されません。 gRPCapplicationは、従来のapplicationと同じ種類の DoS 攻撃を受ける可能性があります。

gRPC アプリに対する DoS 攻撃を特定するのが難しい理由

マイクロサービスとコンテナにより、開発者はより多くの自由と自律性を得て、顧客に新機能を迅速にリリースできるようになりますが、同時に新たな脆弱性や悪用される機会も生まれます。 人気が高まっているサイバー攻撃の 1 つに、サービス拒否 (DoS)攻撃があります。この攻撃は近年、共通脆弱性識別子 (CVE) の増加の原因となっており、その多くは gRPC リクエストの不適切な処理によって発生しています。 applicationsと API に対するレイヤー 7 DoS 攻撃は近年20% 増加しており、影響の規模と深刻度は 200% 近く増加しています。

DoS 攻撃では通常、正当なトラフィックのように見える大量のトラフィックを送信し、アプリケーションのリソースを使い果たして応答しないようにします。 典型的な DoS 攻撃では、悪意のある人物が Web サイトまたはapplicationに大量のトラフィックを送りつけるため、サーバーがすべてのリクエストに圧倒され、停止したりクラッシュしたりします。 DoS 攻撃は、マシンやネットワークを遅くしたり完全に無効にしたりして、それらを必要とするユーザーがアクセスできないようにすることを目的としています。 攻撃が緩和されるまで、eコマースサイト、電子メール、オンラインアカウントなど、マシンまたはネットワークに依存するサービスは使用できません。

HTTP および HTTP/2 リクエストや API 呼び出しを使用してapplicationレイヤー (レイヤー 7) を攻撃する DoS 攻撃が増えています。これは主に、レイヤー 7 攻撃が、最新のapplicationアーキテクチャを防御するように設計されていない従来の防御を回避できるためです。 攻撃者がネットワーク層（レイヤー 3 および 4）での従来のボリューム型攻撃からレイヤー 7 攻撃に切り替えたのはなぜでしょうか? 彼らは最も抵抗の少ない道を歩んでいる。 インフラストラクチャ エンジニアは、レイヤー 3 およびレイヤー 4 の攻撃に対する効果的な防御メカニズムの構築に何年も費やしており、攻撃をブロックしやすくし、攻撃が成功する可能性を低くしています。 そのため、このような攻撃は、金銭的にも時間的にも実行コストが高くなり、攻撃者は別の方法に移行しました。

gRPCapplicationsに対する DoS 攻撃を検出することは、特にスケールアウトが自動的に実行される最新の環境では非常に困難です。 gRPC サービスは、大量のトラフィックを処理するように設計されていない可能性があるため、攻撃者にとって簡単にダウンさせられる標的となります。gRPC サービスは、 h2loadなどのツールによる HTTP/2 フラッド攻撃に対しても脆弱です。 さらに、攻撃者が protobuf 仕様で適切に宣言されたデータ定義を悪用すると、gRPC サービスが簡単に標的にされる可能性があります。

gRPC サービスの典型的な（意図的でないとしても）誤用は、スクリプトのバグによってサービスへの過剰なリクエストが生成されることにあります。 たとえば、自動化スクリプトが、特定の条件が発生したときに API 呼び出しを発行し、設計者はその条件が 2 秒ごとに発生すると予想しているとします。 しかし、条件の定義に誤りがあったため、スクリプトは 2 ミリ秒ごとに呼び出しを発行し、バックエンドの gRPC サービスに予期しない負担をかけてしまいます。

gRPCapplicationに対する DoS 攻撃の他の例としては、次のようなものがあります。

• gRPC メッセージに悪意のあるフィールドを挿入すると、applicationが失敗する可能性があります。
• Slow POST攻撃は、gRPC ヘッダーで部分的なリクエストを送信します。 applicationまたはサーバーは、残りのリクエストの到着を予測して、接続を開いたままにします。 同時接続プールがいっぱいになり、クライアントからの追加の接続試行が拒否される可能性があります。
• HTTP/2 設定フラッド( CVE-2019-9515 )では、攻撃者が空のSETTINGフレームを gRPC プロトコルに送信し、NGINX リソースを消費して、新しいリクエストを処理できなくなります。

NGINX App Protect DoS で動的ユーザーおよびサイト行動分析のパワーを解き放ち、gRPC DoS 攻撃を軽減します。

今日の DoS 攻撃からapplicationsを保護するには、最新のアプローチが必要です。 複雑で適応性の高いapplicationsを保護するには、ユーザーとサイトの行動に基づいて非常に正確で動的な保護を提供し、セキュリティ チームの負担を軽減しながら、迅速なapplication開発と競争上の優位性をサポートするソリューションが必要です。

F5 NGINX App Protect DoS は、市場をリードする F5 の WAF と動作保護に基づいて構築された、NGINX Plus 用の軽量ソフトウェア モジュールです。 NGINX App Protect DoS は、最も高度なレイヤー 7 DoS 攻撃からも防御するように設計されており、独自のアルゴリズムを使用して、適応型機械学習と自動保護を提供する動的な統計モデルを作成します。 緩和効果を継続的に測定し、変化するユーザーとサイトの行動に適応し、プロアクティブなサーバーのヘルス チェックを実行します。 詳細については、弊社のブログの「NGINX App Protect のサービス拒否攻撃が進化する攻撃環境に適応する方法」をご覧ください。

従来の HTTP アプリと最新の HTTP/2 アプリ ヘッダーの両方に対して動作分析が提供されます。 NGINX App Protect DoS は、シグネチャと悪意のある行為者の識別の両方に基づいて攻撃を軽減します。 最初のシグネチャ緩和フェーズでは、NGINX App Protect DoS は異常な動作に関連する属性をプロファイルして動的なシグネチャを作成し、今後この動作に一致するリクエストをブロックします。 攻撃が継続する場合、NGINX App Protect DoS は悪意のある攻撃者の軽減フェーズに移行します。

NGINX App Protect DoS は、統計的な異常検出に基づいて、送信元 IP アドレスと TLS フィンガープリントによって悪意のある行為者を正常に識別し、攻撃トラフィックの特定のパターンを自動的に識別して軽減する動的シグネチャを生成して展開できるようにします。 このアプローチは、ボリュームしきい値を超えたときにそれを検出する、市場にある従来の DoS ソリューションとは異なります。 NGINX App Protect DoS は、リクエストが完全に正当に見え、各攻撃者が平均的な正当なユーザーよりも少ないトラフィックを生成する可能性のある攻撃をブロックできます。

次の Kibana ダッシュボードは、NGINX App Protect DoS が gRPCapplicationに対する DoS フラッド攻撃を迅速かつ自動的に検出し、軽減する方法を示しています。

図 1 は、DoS フラッド攻撃を受けている gRPCapplicationを示しています。 gRPC のコンテキストでは、重要なメトリックは 1 秒あたりのメッセージ レートに対応する 1 秒あたりのデータグラム数 (DPS) です。 この画像では、黄色の曲線は学習プロセスを表しています。ベースライン DPS予測が受信 DPS値 (青色) に収束すると、NGINX App Protect はこのapplicationの「通常の」トラフィックがどのようなものか学習したことになります。 12:25:00 の DPS の急激な上昇は攻撃の開始を示しています。 赤い警告ベルは、NGINX App Protect DoS が攻撃が進行中であると確信し、緩和フェーズを開始した時点を示します。

図 2 は、段階的な緩和アプローチを使用して異常な動作を検出し、gRPC DoS フラッド攻撃を阻止するプロセスにおける NGINX App Protect DoS を示しています。 赤いスパイクは、グローバル レート緩和フェーズ中にすべてのクライアントに送信された HTTP/2 リダイレクトの数を示します。 紫色のグラフは、異常な動作をモデル化するシグネチャとリクエストが一致した場合に特定のクライアントに送信されるリダイレクトを表します。 黄色のグラフは、IP アドレスと TLS フィンガープリントによって識別された特定の検出された悪意のある行為者に送信されたリダイレクトを表します。

図 3 は、機械学習を活用し、この gRPC フラッド攻撃の異常な動作に関連する属性をプロファイルする、NGINX App Protect DoS によって作成された動的シグネチャを示しています。 署名は、初期の署名緩和フェーズ中にそれに一致する要求をブロックします。

図 4 は、攻撃が継続する場合に、NGINX App Protect DoS がシグネチャベースの緩和から悪意のある人物による緩和に移行する様子を示しています。 NGINX App Protect DoS は、ユーザーの行動を分析することで、ここに示すソース IP アドレスと TLS フィンガープリントによって悪意のある行為者を特定しました。 異常な動作を示す特定の署名をすべてのリクエストで確認する代わりに、ここでは特定の攻撃者へのサービスが拒否されます。 これにより、特定の攻撃パターンを識別し、自動的に軽減する動的シグネチャを生成できるようになります。

gRPC API では、gRPC インターフェースを使用して、タイプ ライブラリ (IDL) ファイルと protobuf の proto 定義ファイルにセキュリティ ポリシーを設定します。 これにより、ゼロタッチのセキュリティ ポリシー ソリューションが実現します。gRPC サービスを攻撃から保護するために protobuf 定義に依存する必要はありません。gRPC proto ファイルはCI/CD パイプラインの一部として頻繁に使用され、保護を自動化し、完全な CI/CD パイプライン統合のためにコードとしてのセキュリティを有効にすることで、セキュリティ チームと開発チームを調整します。 NGINX App Protect DoS は、gRPCapplicationsに保護をシームレスに統合することで一貫したセキュリティを確保し、常に最新のセキュリティポリシーによって保護されます。

gRPC は、開発者が最新のapplicationsを設計および展開するために必要な速度と柔軟性を提供しますが、そのフレームワークの本質的なオープン性により、DoS 攻撃に対して非常に脆弱になります。 パフォーマンスの低下、applicationや Web サイトの停止、収益の喪失、顧客ロイヤルティやブランドへのダメージにつながる可能性がある深刻なレイヤー 7 DoS 攻撃に先手を打つには、最新の防御が必要です。 そのため、NGINX App Protect DoS は最新の gRPCapplicationsに不可欠です。

NGINX Plus を使用した NGINX App Protect DoS を実際にお試しいただくには、今すぐ30 日間の無料トライアルを開始するか、弊社にお問い合わせの上、使用事例についてご相談ください。

詳細については、ホワイトペーパー「レイヤー 7 DoS 攻撃に対する最新アプリの保護」をご覧ください。