HTTP/2 Rapid Reset 攻撃が F5 NGINX 製品に影響

このブログ投稿は、HTTP/2 プロトコルに関連して最近発見された脆弱性に焦点を当てています。 特定の条件下では、この脆弱性が悪用され、NGINX Open Source、NGINX Plus、および HTTP/2 仕様のサーバー側部分を実装する関連製品に対してサービス拒否攻撃が実行される可能性があります。 この攻撃からシステムを保護するために、NGINX 構成をすぐに更新することをお勧めします。

HTTP/2 ストリーム リセットの問題

サーバーとの接続を確立した後、HTTP/2 プロトコルにより、クライアントはデータ交換のための同時ストリームを開始できます。 プロトコルの以前のバージョンとは異なり、エンドユーザーがページから移動したり、その他の理由でデータ交換を停止したりする場合、HTTP/2 ではストリームをキャンセルする方法が提供されます。 これは、サーバーに RST_STREAM フレームを発行することで実現され、サーバーが不必要な作業を実行するのを防ぎます。

この脆弱性は、確立された接続を介して大量の HTTP/2 ストリームを開始し、急速にキャンセルすることで、サーバーの同時ストリームの最大値を回避することで悪用されます。 これは、着信ストリームが後続のストリームが到着するよりも速くリセットされ、クライアントが構成されたしきい値に達することなくサーバーを過負荷にすることができるために発生します。

NGINX への影響

パフォーマンスとリソース消費の理由から、NGINX は同時ストリームの数をデフォルトの 128 に制限します ( http2_max_concurrent_streamsを参照)。 さらに、ネットワークとサーバーのパフォーマンスを最適にバランスさせるために、NGINX では、HTTP キープアライブ ( keepalive_requestsを参照) を使用して、クライアントがデフォルトで最大 1000 件のリクエストまで HTTP 接続を維持できるようにしています。

NGINX はデフォルトのキープアライブ制限に依存することで、このタイプの攻撃を防ぎます。 この制限を回避するために追加の接続を作成すると、標準のレイヤー 4 監視およびアラート ツールによって悪意のある行為者が露出することになります。

ただし、NGINX がデフォルトおよび推奨設定よりも大幅に高いキープアライブで構成されている場合、攻撃によってシステム リソースが枯渇する可能性があります。 ストリームのリセットが発生すると、HTTP/2 プロトコルでは、そのストリームで後続のデータがクライアントに返されないことが要求されます。 通常、リセットにより、キャンセルを適切に処理するタスクの形でサーバーのオーバーヘッドはごくわずかになります。 ただし、NGINX のストリームしきい値を回避すると、クライアントはこのオーバーヘッドを利用し、数千のストリームを急速に開始して増幅することができます。 これにより、サーバーの CPU 使用率が急上昇し、正当なクライアントへのサービスが拒否されます。

HTTP/2 ストリームを確立し、その後異常に高いキープアライブ制限下でストリームをキャンセルすることによるサービス拒否。

攻撃の露出を軽減するための手順

フル機能のサーバーおよびプロキシとして、NGINX は管理者にサービス拒否攻撃を軽減するための強力なツールを提供します。 これらの機能を活用するには、NGINX 構成ファイルに次の更新を加えて、サーバーの攻撃対象領域を最小限に抑えることが不可欠です。

• keepalive_requestsはデフォルト設定の1000リクエストのままにしておく必要があります。
• http2_max_concurrent_streamsは、デフォルト設定の128ストリームのままにしておく必要があります。

ベストプラクティスとして、次の安全対策を追加することをお勧めします。

• limit_conn は、単一のクライアントから許可される接続の数に制限を適用します。 このディレクティブは、アプリケーションのパフォーマンスとセキュリティのバランスを取った適切な設定で追加する必要があります。
• limit_req は、指定された時間内に単一のクライアントから処理されるリクエストの数に制限を適用します。 このディレクティブは、アプリケーションのパフォーマンスとセキュリティのバランスを取った適切な設定で追加する必要があります。

弊社の対応方法

当社は複数の緩和戦略を実験し、この攻撃が幅広い顧客やユーザーにどのような影響を与えるかを理解することができました。 この調査により、NGINX には攻撃を回避するために必要なツールがすべて装備されていることが確認されましたが、推奨仕様を超えて NGINX を構成する必要があるユーザーがそれを実行できるように、追加の手順を実行したいと考えました。

私たちの調査により、HTTP/2 プロトコル上で理論的に起こり得るさまざまな形式のフラッド攻撃に対するサーバーの回復力を向上させる方法が明らかになりました。 その結果、このような状況下でシステムの安定性を向上させるパッチをリリースしました。 このような脅威から保護するために、NGINX オープンソース ユーザーは最新のコードベースからバイナリを再構築し、NGINX Plus のお客様は最新のパッケージ (R29p1 または R30p1) にすぐに更新することをお勧めします。

パッチの仕組み

NGINX に対するフラッド攻撃を早期に検出できるように、このパッチでは、1 つのイベント ループ内で導入できる新しいストリームの数に制限を設けています。 この制限は、 http2_max_concurrent_streamsディレクティブを使用して設定された値の 2 倍に設定されます。 リクエストの送信直後にストリームがリセットされた場合など (この攻撃の場合のように)、最大しきい値に到達しない場合でも制限が適用されます。

影響を受ける製品

この脆弱性は、NGINX HTTP/2 モジュール ( ngx_http_v2_module ) に影響します。 影響を受ける可能性のある特定の NGINX または F5 製品の詳細については、 https ://my.f5.com/manage/s/article/K000137106 をご覧ください。

CVE-2023-44487 – HTTP/2 ラピッド リセット攻撃の詳細については、https: //www.cve.org/CVERecord?id=CVE -2023-44487 を参照してください。

謝辞

この脆弱性の特定と軽減における発見と協力に貢献した Cloudflare、Amazon、Google に感謝の意を表します。