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

NGINX | 2022年2月10日

Thelen Blumシニアプロダクトマーケティングマネージャー、NGINX App Protect | F5

過去2年間における商品やサービスへの顧客需要を通じて、組織が容易に拡張し、イノベーションを加速することの重要性が浮き彫りになりました。その結果、多くの組織がモノリシックアーキテクチャからクラウドネイティブアーキテクチャへの移行を加速させています。F5の最新レポート「The State of Application Strategy 2021」によると、アプリケーションのモダナイゼーションに取り組む組織の数は、昨年だけで133%増加しました。クラウド対応アプリケーションは、モジュール化および分散化され、自動的にデプロイ、管理できるように設計されています。既存のモノリシックアプリケーションをそのままリフト＆シフトすることも可能ですが、コストや柔軟性の面でメリットはありません。クラウドコンピューティングサービスがもたらす分散モデルのメリットを最大限に活用するには、モジュール化を検討するのが最善です。そこで登場するのが「マイクロサービス」です。

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

開発者は、効率を高め、アプリケーションのデプロイを迅速化する方法を常に模索しています。APIはソフトウェア間の通信を可能にし、開発の構成要素となります。サーバーにデータをリクエストするために、Web開発者は当初、HTTPを使用するSOAPを利用していました。SOAPでは、リクエストの詳細がXMLドキュメントで送信されます。しかし、XMLドキュメントはサイズが大きくなりやすく、相当なオーバーヘッドが発生するうえ、開発にも時間がかかります。

その後、多くの開発者が、ステートレスで信頼性の高いWeb APIを作成するためのアーキテクチャスタイルおよび一連のガイドラインであるRESTへと移行しました。これらのガイドラインに準拠するWeb APIはRESTfulと呼ばれます。RESTful Web APIでは通常、HTTPメソッドに基づき、URLエンコードされたパラメーターを介してリソースにアクセスし、データの送信にはJSONまたはXMLを使用します。RESTful APIを使用することで、アプリケーションをより迅速に開発でき、オーバーヘッドも削減できます。

技術の進歩により、アプリケーション設計を発展させる新たな可能性が生まれています。2015年、Googleは、あらゆる環境で実行できる最新のオープンソースRPCフレームワークとしてGoogle Remote Procedure Call（gRPC）を開発しました。RESTがHTTP 1.1プロトコルを基盤とし、リクエスト／レスポンス型の通信モデルを使用するのに対し、gRPCはトランスポートにHTTP/2を使用し、クライアントレスポンス型の通信モデルを採用しています。このモデルでは、サービスとデータを記述するためのインターフェース記述言語（IDL）としてprotocol buffers（protobuf）が実装されています。Protobufは構造化データのシリアル化に使用され、シンプルさとパフォーマンスを重視して設計されています。protobufの効率性とHTTP/2の使用により、gRPCはRESTと比べて、データ受信時は約7倍、送信時は約10倍高速です。また、gRPCはストリーミング通信に対応し、複数のリクエストを同時に処理できます。

gRPCは、低レイテンシー、多言語対応、コンパクトなデータ表現、リアルタイムストリーミングといった特長を備えており、マイクロサービス間の通信や、低消費電力かつ低帯域幅のネットワークを介した通信に特に適しています。そのため、開発者にとって、gRPCによるマイクロサービスの構築は、RESTful APIを使用する方法に代わる魅力的な選択肢となっています。gRPCは、クライアントとサーバーの双方で言語に依存せず、信頼性とスケーラビリティを高めながら、新しいサービスを迅速かつ効率的に構築しやすくすることから、普及が進んでいます。

gRPCプロトコルのオープンな性質にはいくつかの利点がありますが、この標準には、DoS攻撃がアプリケーションに及ぼす影響から保護する仕組みはありません。gRPCアプリケーションも、従来のアプリケーションと同じ種類のDoS攻撃による被害を受ける可能性があります。

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

マイクロサービスとコンテナにより、開発者は自由度と自律性を高め、新機能を迅速にお客さまへ提供できる一方で、新たな脆弱性や悪用の機会も生じます。近年増加しているサイバー攻撃の1つがサービス拒否（DoS）攻撃です。DoS攻撃に関連する共通脆弱性識別子（CVE）は近年増加しており、その多くはgRPCリクエストの不適切な処理に起因しています。アプリケーションとAPIを標的とするレイヤー7 DoS攻撃は、近年20%急増し、影響の規模と深刻度は約200%増加しています。

DoS攻撃では一般に、正規の通信に見える大量のトラフィックを送信してアプリケーションのリソースを枯渇させ、応答不能にします。典型的なDoS攻撃では、悪意のある攻撃者がWebサイトやアプリケーションに大量のトラフィックを送りつけます。その結果、サーバーが膨大なリクエストを処理しきれず、停止したり、クラッシュしたりすることもあります。DoS攻撃は、マシンやネットワークの動作を遅くしたり、完全に停止させたりして、必要とするユーザーがアクセスできない状態にすることを目的としています。攻撃が緩和されるまで、ECサイト、メール、オンラインアカウントなど、そのマシンやネットワークに依存するサービスは利用できません。

近年、HTTPやHTTP/2リクエスト、APIコールを使用してアプリケーション層（レイヤー7）を狙うDoS攻撃が増加しています。その主な理由は、最新のアプリケーションアーキテクチャを防御するように設計されていない従来型の防御策を、レイヤー7攻撃が回避できるためです。攻撃者がネットワーク層（レイヤー3および4）を狙う従来型のボリューム攻撃から、レイヤー7攻撃へと移行したのはなぜでしょうか。それは、最も抵抗の少ない経路を選んでいるからです。インフラストラクチャエンジニアは長年にわたり、レイヤー3およびレイヤー4攻撃に対する効果的な防御メカニズムを構築してきました。その結果、これらの攻撃は阻止しやすくなり、成功する可能性も低下しています。こうした攻撃は、金銭面でも時間面でも実行コストが高くなるため、攻撃者は別の手法へと移行しています。

gRPCアプリケーションに対するDoS攻撃の検知は極めて困難です。特に、スケールアウトが自動的に行われる最新の環境では、その傾向が顕著です。gRPCサービスは大量のトラフィックを処理するように設計されていない場合があり、攻撃者にとってサービスを停止させやすい標的となります。また、gRPCサービスは、h2loadなどのツールを使用したHTTP/2フラッド攻撃に対しても脆弱です。さらに、攻撃者がprotobuf仕様で適切に宣言されたデータ定義を悪用すると、gRPCサービスは容易に標的となる可能性があります。

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

gRPCアプリケーションに対するDoS攻撃のその他の例は次のとおりです。

gRPCメッセージに悪意のあるフィールドが挿入されると、アプリケーションが停止する可能性があります。
Slow POST攻撃は、gRPCヘッダーで不完全なリクエストを送信します。アプリケーションまたはサーバーは、リクエストの残りの部分が到着することを想定して、接続を開いたままにします。その結果、同時接続プールが上限に達し、クライアントからの追加の接続試行が拒否される可能性があります。
HTTP/2 Settings Flood（CVE-2019-9515）では、攻撃者が空のSETTINGフレームをgRPCプロトコルに送信してNGINXのリソースを消費させ、新しいリクエストを処理できない状態にします。

動的なユーザーおよびサイトの振る舞い分析を活用し、NGINX App Protect DoSでgRPC DoS攻撃を緩和

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

F5 NGINX App Protect DoSは、F5の市場をリードするWAFと振る舞いベースの保護機能を基盤とした、NGINX Plus向けの軽量ソフトウェアモジュールです。高度なLayer 7 DoS攻撃にも対抗できるよう設計されており、独自のアルゴリズムで動的な統計モデルを作成し、適応型機械学習と自動保護を提供します。緩和策の有効性を継続的に測定し、ユーザーやサイトの振る舞いの変化に適応するとともに、プロアクティブなサーバーヘルスチェックを実行します。詳しくは、F5ブログの「進化する攻撃環境にF5 NGINX App Protect DoSが適応する仕組み」をご覧ください。

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

統計的な異常検知に基づき、NGINX App Protect DoSは送信元IPアドレスとTLSフィンガープリントから悪意のある攻撃者を正確に特定します。これにより、特定の攻撃トラフィックパターンを自動的に識別して緩和する動的シグネチャを生成し、適用できます。このアプローチは、トラフィック量がしきい値を超えた時点で検知する従来の一般的なDoS対策ソリューションとは異なります。NGINX App Protect DoSは、リクエストが完全に正当なものに見え、各攻撃者が生成するトラフィック量が正規ユーザーの平均を下回る場合でも、攻撃をブロックできます。

以下のKibanaダッシュボードは、NGINX App Protect DoSがgRPCアプリケーションに対するDoSフラッド攻撃を迅速かつ自動的に検知し、緩和する仕組みを示しています。

図1は、DoSフラッド攻撃を受けているgRPCアプリケーションを示しています。gRPCでは、1秒あたりのメッセージ数に相当する1秒あたりのデータグラム数（DPS）が重要な指標です。この図の黄色の曲線は学習プロセスを表しています。つまり、ベースラインDPSの予測値が受信DPSの値（青色）に収束すると、NGINX App Protectは、このアプリケーションの「通常」のトラフィックを学習したことになります。12:25:00のDPSの急増は、攻撃の開始を示しています。赤いアラームベルは、NGINX App Protect DoSが攻撃の進行を確信し、緩和フェーズを開始した時点を示しています。

図1：DoS攻撃を受けているgRPCアプリケーション

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

図2： 段階的な緩和アプローチを使用してgRPC DoSフラッド攻撃を阻止するNGINX App Protect DoS

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

図3： 動的シグネチャ

図4は、攻撃が継続した場合に、NGINX App Protect DoSがシグネチャベースの緩和から悪意のあるアクターを対象とした緩和へ移行する仕組みを示しています。NGINX App Protect DoSは、ユーザーの行動を分析し、ここに示す送信元IPアドレスとTLSフィンガープリントに基づいて悪意のあるアクターを特定しています。異常な動作を示す特定のシグネチャがないかすべてのリクエストを調べる代わりに、特定の攻撃者に対してサービスを拒否します。これにより、こうした特定の攻撃パターンを識別し、自動的に緩和する動的シグネチャを生成できます。

図4： IPアドレスとTLSフィンガープリントに基づいて悪意のあるアクターを特定するNGINX App Protect DoS

gRPC APIでは、gRPCインターフェースを使用して、型ライブラリ（IDL）ファイルとprotobufのproto定義ファイルにセキュリティポリシーを設定します。これにより、ゼロタッチのセキュリティポリシーソリューションが実現し、gRPCサービスを攻撃から保護するためにprotobuf定義に依存する必要がなくなります。gRPC protoファイルは、多くの場合、CI/CDパイプラインの一部として使用されます。保護を自動化し、セキュリティをコードとして扱えるようにすることで、セキュリティチームと開発チームの連携を促進し、CI/CDパイプライン全体に統合できます。NGINX App Protect DoSは、gRPCアプリケーションに保護機能をシームレスに統合し、常に最新のセキュリティポリシーで保護することで、一貫したセキュリティを確保します。

gRPCは、最新のアプリケーションの設計とデプロイに必要なスピードと柔軟性を開発者に提供します。一方で、そのフレームワークは本質的にオープンであるため、DoS攻撃に対して非常に脆弱です。パフォーマンスの低下、アプリケーションやWebサイトの停止、収益機会の喪失、顧客ロイヤルティやブランドの毀損につながりかねない深刻なレイヤー7 DoS攻撃に先手を打つには、最新の防御策が必要です。そのため、最新のgRPCアプリケーションにはNGINX App Protect DoSが不可欠です。

NGINX Plusと組み合わせてNGINX App Protect DoSをお試しいただくには、今すぐ30日間の無料トライアルを開始するか、ユースケースについてご相談ください。