NGINX Plusでセキュリティ脆弱性を迅速かつ容易に緩和

NGINX | 2021年3月04日

NGINXでは、世界中の文字どおり数百万もの組織から、Webサイトやアプリケーション配信インフラストラクチャを支えるソフトウェアとして信頼されていることを誇りに思っています。ユーザーがNGINXに大きく依存しているにもかかわらず、今日のインターネットで一般化しているCommon Vulnerabilities and Exposures（CVE）などのセキュリティ脆弱性に対する修正を含む最新バージョンを実行する重要性について、あまり考えたことがないと聞くと驚かされます。

もちろん、セキュリティ脅威への防御を検討するだけでは不十分です。脆弱性を追跡し、対策が利用可能になり次第導入するための明確なプロセスを確立する必要があります。オープンソースソフトウェアのように、これらすべてを自力で行う場合、必要な時間と労力を過小評価しがちです。実際、セキュリティ脅威への対策を迅速かつ容易に実施できることは、NGINX Plusのような商用サポート付きソフトウェアが持つ、見過ごされがちなメリットです。

このブログでは、オープンソースソフトウェアを保護するうえでの課題を取り上げ、NGINX PlusによってCVEsやその他のセキュリティ脅威をより迅速かつ容易に緩和できる仕組みを解説します。

オープンソースソフトウェアの脆弱性への対処

すべての開発者が完璧なコードを書いていると考えたいものですが、バグのないソフトウェアはありません。開発者が望むのは、厳格な品質基準への適合プロセスの一環として、ほとんどのバグが開発中に検出され、アプリの運用期間を通じて通常の使用時に表面化するバグがごくわずかにとどまることです。最悪の場合、悪意のあるユーザーによってバグが発見されます。

複数のオープンソースツール、プログラミング言語、プラットフォームを組み合わせてアプリケーションスタックを構築すると、バグによる影響は大幅に増大します。バグがないことを確認するには、各コンポーネントを個別に検証する必要があります。オープンソースソフトウェアでバグが見つかった場合に備え、検証、テスト、および可能であれば修正を行うための方針を定めておくことが重要です。

オープンソースソフトウェアに関するポリシーには、少なくとも次の3つのプロセスを含める必要があります。

定期的なレビューとテスト
脆弱性の追跡と社内報告
脆弱性への迅速な対処

脆弱性の報告

セキュリティ脆弱性が発見された場合、その開示は標準的な手順に沿って進められます。まず、ソフトウェアの開発者またはベンダーに詳細なレポートを提出します。報告者と開発者が協議して脆弱性を開示する方法と時期を決定し、通常は共通脆弱性識別子（CVE）データベースに登録します。慣例上、開発者には開示前に問題を解決するための期間として90日が与えられますが、期間の延長を交渉することも可能です。

NGINXとCVE

オープンソースソフトウェアの提供元および商用ソフトウェアのベンダーとして、NGINXは、NGINX Open Source、NGINX Plus、ならびにその他の商用製品（本稿執筆時点ではNGINX Controller［現在のF5 NGINX Management Suite］、NGINX App Protect、NGINX Ingress Controllerを含む）と、無償のオープンソース製品（NGINX Service Mesh、NGINX Unit、NGINX Amplifyを含む）に影響するCVEやその他の脆弱性について、報告および修正プロセスに積極的に参加しています。

NGINX PlusはNGINX Open Sourceをベースとしており、NGINX Plusのお客さまにエンタープライズレベルのサポートとプロセス標準を提供するという当社の取り組みは、NGINX Open Sourceのユーザーにもメリットをもたらします。これらの標準には、お客さまとのサービスレベル契約（SLA）が含まれます。SLAでは、コアソフトウェア、依存関係、サポート対象モジュールのいずれについても、パッチが準拠すべきバグ修正およびテスト手順を定めています。SLAは、脆弱性を悪用した攻撃にさらされるリスクを最小限に抑えながら、お客さまの規制遵守を支援します。

NGINX Open Sourceには、さらに複雑な事情があります。多くのサードパーティテクノロジーがNGINX Open Sourceを活用し、自社製品に組み込んでいるためです。これらのテクノロジーのプロバイダーは、ソフトウェアの脆弱性が発見された際の開示とパッチ適用について、独自のプロセスを設けています。次のセクションで説明するように、NGINX Open Source向けパッチのリリースから、サードパーティテクノロジー向けの対応パッチがリリースされるまでに、かなりの時間差が生じる場合があります。

NGINX Plusが脆弱性からサブスクライバーを保護する仕組み

冒頭で述べたように、NGINX Plusには見過ごされがちなメリットがあります。それは、お客さまが脆弱性への対策をより迅速かつ容易に行えるようになることです。オープンソースソフトウェアの脆弱性への対応には、一般に考えられている以上に多くの時間がかかり、その分コストも増大する可能性があります。

以下のセクションでは、NGINX Plusサブスクライバーが脆弱性により迅速かつ容易に対処できる5つの具体的な方法について説明します。

NGINXはNGINX Plusサブスクライバーにパッチ情報を事前に通知

NGINX Open SourceおよびNGINX Plus向けのセキュリティパッチをリリースする際、NGINX Plusのお客さまにはメールで事前にお知らせします。また、ほとんどのパッチについては、提供開始を告知するブログ記事も公開しています。しかし、NGINX Open Sourceのユーザーに直接お知らせする手段はありません。そのため、ユーザー自身がCVEやその他の脆弱性データベースを監視し、F5のブログを定期的に確認する必要があります。

F5 SIRTが攻撃を受けているNGINX Plusサブスクライバーをリアルタイムで支援

NGINX Plusサブスクライバーを含むF5のお客さまが攻撃の被害を受けた場合、F5 Security Incident Response Team（SIRT）がリアルタイムで支援します。SIRTは迅速に対応し、攻撃を効果的に緩和して、システムの復旧を支援します。攻撃が収束した後も支援を継続し、「報告されたインシデントにとどまらず、お客さまの組織への被害を全体として軽減するとともに、将来の脅威を把握、予測、抑止」します。

NGINX App Protectでアプリケーション保護を強化

NGINX App Protectは、F5が20年にわたり培ってきたセキュリティの経験を活用し、NGINX Plusのダイナミックモジュールとして導入される、エンタープライズグレードのWebアプリケーションファイアウォール（WAF）です。バックエンドのアプリケーションサーバーに存在する、より多くのCVEに対してアプリケーション固有の保護を提供し、NGINX Plusのレイヤー7セキュリティを強化します。NGINXとF5は、特定の攻撃キャンペーンに関連するシグネチャの提供に取り組んでいます。その結果、NGINX App Protectにより、NGINX Plusのサブスクライバーは独自のシグネチャを作成したり、多数の誤検知に対処したりする必要がなくなります。

NGINX PlusはJWTベース認証とOpenID Connect認証をサポート

パッチの適用が必要な特定の脆弱性がない場合でも、高度な認証プロトコルは、悪意のある第三者によるアプリケーションやインフラストラクチャへのアクセス防止に役立ちます。NGINX Open Sourceで利用可能な方式に加えて、NGINX Plusは、JSON Web Token（JWT）およびOpenID Connectに基づく認証を、WebクライアントとAPIクライアントの両方でサポートします。

NGINX Plusサブスクライバーにはパッチを即時提供

As described in 脆弱性の報告で説明しているとおり、NGINXソフトウェアに影響する脆弱性については、通常、CVEとして一般公開される前に通知を受けます。この事前通知により、一般公開前にパッチを準備でき、通常は公開当日（場合によっては数日以内）にリリースします。NGINX Plusのお客さまには、パッチ適用済みバイナリとして修正を提供します。NGINX Open Sourceユーザーには、修正済みソースコードと、サポート対象OS向けのパッチ適用済みバイナリとして提供しますが、前述のとおり、NGINX Open Sourceユーザーに直接通知する手段はありません。

NGINX Open Sourceを利用または組み込んでいるサードパーティ製テクノロジーでは、脆弱性が公開されるまで、その存在を把握できない可能性があります。事前に把握できた場合でも、F5の経験上、パッチの提供がNGINXのパッチより数か月遅れることがあります。特に、ボランティアによって保守されることの多いオープンソースソフトウェアでは、これはやむを得ない面もありますが、脆弱性の公開後もインフラストラクチャが保護されない状態となり、ハッカーに悪用されるおそれがあります。

一例として、2018年秋にHTTP/2の脆弱性に関する2件のCVE（CVE-2018-16843およびCVE-2018-16844）が発見されました。これを受け、NGINX Plus R16とNGINX Open Source 1.15.6にセキュリティパッチを適用しました。NGINX Open SourceをベースにNGINX Plusの一部機能を提供する広く利用されているソフトウェアOpenRestyが、これらのパッチを組み込んだリリース候補版を初めて公開したのは2019年3月3日で、NGINXによるパッチ公開から実に4か月後でした。さらに、OpenRestyをベースに構築されたソリューションでは、通常、コードベースへのパッチ適用にそれ以上の時間がかかります。

脆弱性の位置付けが明確でない場合や、潜在的な攻撃経路となり得るにもかかわらず、ソフトウェアプロバイダーがパッチは不要と判断する場合があります。2020年には、最も広く利用されているオープンソースWAFソフトウェアであるModSecurityで、このような事態が発生しました。OWASP ModSecurity Core Rule Set（CRS）のメンテナンスチームは、ModSecurity v3による正規表現のグローバルマッチングの仕組みによって、OWASP CRSチームがサービス拒否の脆弱性（CVE-2020-15598）と見なす問題が生じる可能性があることを発見しました。ModSecurity自体を管理する組織であるTrustwaveは、この挙動がセキュリティ上の問題であるとの見解に異議を唱え、パッチの提供を見送りました。

NGINX ModSecurity WAFは、ModSecurity v3をベースに構築されたNGINX Plus用の動的モジュールです。NGINXチームは、CVE-2020-15598に記載された動作がDoS脆弱性を引き起こす可能性が十分にあると判断し、2020年9月にパッチを公開しました。パッチの公開を告知したブログで説明したとおり、オープンソース版ModSecurityのビルドを使用するユーザー（NGINX Open Sourceユーザーを含む）は、OWASP CRSチームのパッチを適用するか、Trustwaveの未修正版ソフトウェアを引き続き使用し、必要に応じてTrustwaveが提案した緩和策を実施するかを、自ら判断する必要があります。

[編集者注 – NGINX ModSecurity WAFは、2022年4月1日付で正式に販売終了となり、2024年3月31日付でサポート終了となります。詳細については、ブログ記事「F5 NGINX ModSecurity WAF Is Transitioning to End-of-Life<.htmla>」をご覧ください。]