NGINX Plus R17を発表

Liam Crillyプロダクトマネジメント担当シニアディレクター

[編集者注 – NGINX ModSecurity WAFモジュール（NGINX Plus向け）は、2022年4月1日付で正式に販売終了となり、2024年3月31日付でサポート終了に移行します。詳細については、ブログ記事「F5 NGINX ModSecurity WAFのサポート終了への移行<.htmla>」をご覧ください。]

NGINX Plus Release 17（R17）の提供開始をお知らせします。NGINX Plusは、ロードバランサー、コンテンツキャッシュ、Webサーバー、APIゲートウェイを一体化した唯一のソリューションです。NGINX PlusはNGINX Open Sourceをベースとしており、独自の拡張機能と受賞歴のあるサポートが含まれています。

このリリースでは、新たにTLS 1.3をサポートしました。TLS 1.3は、インターネット上のすべてのセキュアな通信を担うプロトコルの最新バージョンです。TLS 1.2のリリースから10年以上が経過し、その間に多くの変化がありました。TLS 1.2では、FREAK、Heartbleed、POODLE、ROBOTなど、多数のセキュリティ脆弱性が発見されています。こうした脆弱性の多くは、TLS 1.2に安全でない設定オプションが多すぎたため、サイトが攻撃を受けやすい状態になっていたことに起因します。

TLS 1.3は、機能を削ることで価値を高めています。安全でない暗号スイートの多くが削除され、Diffie‑Hellman鍵交換が必須になりました。その結果、TLSはよりシンプルかつ高速で、セキュリティも強化されています。本稿執筆時点では、Alpine Linux 3.9、FreeBSD 12.0、Ubuntu 18.10がTLS 1.3をサポートしているため、本番環境でNGINX Plus R17と組み合わせてTLS 1.3を利用できます。ほかのOSベンダーも、今後のリリースでTLS 1.3をサポートすることは間違いないでしょう。なお、F5 BIG-IPをはじめとするハードウェアロードバランサーは、現時点ではTLS 1.3を完全にはサポートしていません。

NGINX Plus R17には、次の新機能も含まれています。

• 2段階のレート制限 – レート制限は、NGINX Open SourceとNGINX Plusで特に広く利用されている機能の1つです。DDoS攻撃の緩和に使用できるほか、過剰なリクエストによってアプリケーションサーバーに過負荷がかかるのを防ぐためにも利用できます。新しいdelayパラメーターにより、NGINX Plusのレート制限で一般的なブラウザのリクエストパターンにより適切に対応できます。既存の遅延と拒否の適用方法を組み合わせて2段階のレート制限を実現できるようになりました。過剰なリクエストはまず遅延され、その後もレート制限を超過している場合は最終的に拒否されます。
• OpenID Connectの設定を簡素化 – NGINX Plus R15では、OpenID Connect連携を導入し、アプリケーションにシングルサインオン（SSO）を追加できるようにしました。R17では設定を簡素化し、アイデンティティプロバイダー（IdP）からJSON Web Key（JWK）を自動的に取得できるようにしました。
• NGINX Modsecurity WAFが2倍高速化 – ModSecurity v3をベースとするNGINX Plus用ダイナミックモジュールのNGINX ModSecurity WAFは、レイヤー7攻撃に対する強力な保護を提供します。ModSecurityは活発に開発が進められており、最新バージョンのNGINX ModSecurity WAFでは、パフォーマンスが2倍に向上し、さらに複数の改善が加えられています。

その他の機能強化として、NGINX Plus R17ではアップストリームへのTCPキープアライブ、クラスタ環境でのSNIサポートなどが追加されています。

動作に関する重要な変更

• NGINX Plus R13では、メトリクス収集とアップストリームグループの動的な再構成に対応する、まったく新しいNGINX Plus APIが導入され、従来これらの機能を提供していたStatus APIとUpstream Conf APIに置き換わりました。当時お知らせしたとおり、非推奨となったAPIはその後も長期間にわたり利用およびサポートが継続されましたが、NGINX Plus R16をもって終了しました。構成にstatusまたはupstream_confディレクティブが含まれている場合は、R17へのアップグレード時に、これらをapiディレクティブに置き換える必要があります。NGINX Plus APIへの移行に関するガイダンスやサポートについては、F5のブログに掲載されている移行ガイドをご覧いただくか、サポートチームにお問い合わせください。
• 新たにサポートされるオペレーティングシステム：
  • Alpine Linux 3.8
  • Alpine Linux 3.9
  • FreeBSD 11.2
  • FreeBSD 12.0
  • SUSE Linux Enterprise Server 15
  • Ubuntu 18.10 (Cosmic)
• 削除済みまたは削除予定の旧バージョンのオペレーティングシステム：
  • FreeBSD 10.4および11.1はサポート対象外となりました。
  • CentOS/Oracle/RHEL 7.3以前のサポートは、NGINX Plus R18で終了します。
  • Ubuntu 14.04のサポートは、NGINX Plus R19で終了します。

新機能の詳細

TLS 1.3：削ることで得られるもの

TLSのメジャーアップデートは10年以上ぶりです。TLS 1.2は2008年8月にRFC 5246として定義されましたが、それ以降、インターネットは大きく変化しました。TLS 1.3は、TLS 1.2で見つかった多くの問題への対処を支援し、将来に向けてより拡張性の高い基盤を確立するため、2018年8月にRFC 8446として承認されました。

セキュリティを強化

これまでに、TLS 1.2では多数のセキュリティ脆弱性が公表されています。たとえば、FREAK、Heartbleed、POODLE、ROBOTなどです。たとえばFREAKでは、攻撃者がTLS接続をダウングレードし、総当たり攻撃で解読可能な40ビット長の鍵を持つエクスポート暗号を使用させることができます。TLS 1.3では、エクスポート暗号が完全に廃止されています。

TLS 1.2以前の仕様で生じた問題の多くは、ユーザーが設定できるオプションが多数存在することに起因します。オプションを誤って使用すると、攻撃者に悪用される可能性のある安全でない構成になることが少なくありませんでした。TLS 1.3では、これらのオプションの一部が削除されています。

• AES‑CBC
• 任意のDiffie‑Hellmanグループ
• 輸出用暗号スイート
• DES/3DES
• MD5
• PKCS#1 v1.5パディング
• RC4
• RSA鍵転送（Diffie-Hellmanが必須）
• SHA‑1

パフォーマンスの向上

削除された機能の中で注目すべきものに、RSA鍵転送があります。このモードが主に使用されていたのは、完全前方秘匿性（PFS）を確保して接続を確立するために追加のラウンドトリップが必要だったDiffie‑Hellmanよりも高速だったためです。TLS 1.3では、この追加のラウンドトリップは不要になりました。設定オプションが減ったことで、交換する情報も少なくなり、Diffie‑Hellmanハンドシェイクはわずか1回のラウンドトリップで完了します（図には、ハンドシェイク後の「GET」リクエストも示されています）。

TLS 1.3では、安全な接続の確立に必要なラウンドトリップ数を削減することで、パフォーマンスが向上します

さらに、TLS 1.3はセッション再開をサポートしています。クライアントが以前アクセスしたサイトに再度アクセスする際、TLSハンドシェイクを繰り返すオーバーヘッドがなくなるため、接続をより迅速に確立できます。これは、0‑RTT（ゼロラウンドトリップタイム）再開とも呼ばれます。再開されたセッションでは、クライアントとサーバーの間でハンドシェイクメッセージをやり取りする必要がないためです。セッション再開は、最初のセッションで共有シークレットを作成し、セッションチケットに保存することで実装されます。クライアントが再度アクセスすると、リクエストとともにセッションチケットを提示します。このリクエストは、チケット内の共有シークレットで暗号化されています。

TLS 1.3により、TLSセッションを迅速に再開できます

0‑RTTを使用すると、以下に示すようにリプレイ攻撃のリスクが生じます。このシナリオでは、攻撃者が2つの銀行口座間の送金リクエストなど、状態の変更を引き起こすパケットを再送信します。

0-RTTを利用したリプレイ攻撃

リプレイ攻撃から保護するため、クライアントが0‑RTTデータ（共有シークレットで暗号化されたデータ）で送信すべきHTTPリクエストタイプは、GETのみに限定されます。HTTP GETリクエストは定義上、冪等であるため（RFC 7231）、リプレイされても影響はありません。通常、クライアントがサイトを再訪した際に最初に行うのはページの読み込みであり、ほとんどのページ読み込みはGETリクエストから始まります。そのため、セッション再開を有効にすると、ほとんどのWebサイトで大部分のリクエストを高速化できます。ただし、NGINX PlusをAPIゲートウェイとして導入する場合は、0‑RTT再開を有効にしない方がよいことがあります。APIトラフィックでは、再開されたTLSセッションに非冪等なリクエストタイプが含まれる可能性が高いためです。

TLS 1.3自体も、セッションチケットとクライアントリクエストにタイミング情報を含めることで、リプレイ攻撃から保護します。これによりサーバーは、クライアントがリクエストを送信してから妥当な時間内にそのリクエストが到着したかどうかを判断できます。攻撃者はタイミング情報を改ざんできないため、到着までに時間がかかりすぎたリクエストは、リプレイされた可能性があります。

NGINX PlusでTLS 1.3を有効にする方法

TLS 1.3と0‑RTTは、デフォルトでは有効になっていません。

TLS 1.3を有効にするには、TLSv1.3パラメーターをssl_protocolsディレクティブに追加します。執筆時点では、すべてのブラウザがTLS 1.3をサポートしているわけではないため、TLSv1.2も追加することを推奨します（次のセクションを参照）。クライアントがTLS 1.3をサポートしている場合、NGINX PlusはTLS 1.3を使用し、サポートしていない場合はTLS 1.2にフォールバックします。

0‑RTTを有効にするには、ssl_early_dataディレクティブもonに設定します。

この設定により、両方の機能が有効になります。

server {    listen 443 ssl;
    ssl_certificate     /etc/ssl/my_site_cert.pem;
    ssl_certificate_key /etc/ssl/my_site_key.pem;
    ssl_protocols       TLSv1.2 TLSv1.3;
    ssl_early_data on; # Enable 0-RTT (TLS 1.3)

    location / {
        proxy_pass http://my_backend;
    }
}

サポート対象プラットフォーム

サーバー側でTLS 1.3を使用するには、OpenSSL 1.1.1以降が必要です。本稿執筆時点でOpenSSL 1.1.1を搭載しているのは、Alpine Linux 3.9、FreeBSD 12.0、Ubuntu 18.10のみです。

クライアント側では、Chrome 70またはFirefox 63を推奨します。これらはTLS 1.3の最終バージョンをサポートしていますが、デフォルトでは有効になっていません。こちらのブラウザーでTLS 1.3を有効にする手順に従ってください。本稿執筆時点では、その他の主要なブラウザー（Android版Firefox、iOS版およびMac版Safariを含む）は、まだTLS 1.3をサポートしていません。最新の対応状況については、Can I Use: TLS 1.3をご覧ください。

2段階レート制限

従来、NGINX Plusでは、過剰なリクエストを即座に拒否する方法と、定義されたレート制限に従って処理できるようになるまでキューに入れる方法の2通りで、リクエストレートの制限を適用できました。NGINX Plus R17では、この2つの適用方法を組み合わせた2段階のレート制限が可能です。過剰なリクエストはまず遅延され、それでもレート制限を超過している場合は最終的に拒否されます。

レート制限を適用する際は、正当なクライアントの一般的な動作を考慮することが不可欠です。たとえば、Webブラウザは通常、複数のリソースを同時にダウンロードしようとするため、HTMLコンテンツのリクエストに続いて、スタイルシート、JavaScriptコード、画像のリクエストが短時間に送信されるのは自然な動作です。そのため、レート制限を適用する前に、10～20件のリクエストが短時間に集中するバーストを許可することが考えられます。

NGINX Plus R17では、一般的なWebブラウザーのリクエストパターンに対応するためにバーストを許可し、その後、一定の上限までは追加の過剰なリクエストを遅延させ、上限を超えた分を拒否できるようになりました。2段階のレート制限は、delayディレクティブの新しいlimit_reqパラメーターで有効にできます。

2段階のレート制限の例として、ここでは1秒あたり5リクエスト（rate=5r/s）のレート制限を適用し、Webサイトを保護するようにNGINX Plusを設定します。このWebサイトでは通常、1ページあたり4～6個のリソースが使用され、12個を超えることはありません。この設定では最大12リクエストのバーストを許可し、そのうち最初の8リクエストは遅延なく処理されます。過剰なリクエストが8件を超えると、5 r/sの制限を適用するために遅延が追加されます。過剰なリクエストが12件を超えると、それ以降のリクエストは拒否されます。

limit_req_zone $binary_remote_addr zone=ip:10m rate=5r/s;
server {
    listen 80;
    location / {
        limit_req zone=ip burst=12 delay=8;
        proxy_pass http://website;
    }
}

The delayパラメーターは、バーストサイズの範囲内で、定義されたレート制限に従うために過剰なリクエストのスロットリング（遅延）を開始するポイントを指定します。この設定では、8 r/sでリクエストを継続的に送信するクライアントは、次のように動作します。

次の設定におけるレート制限の動作図：rate=5r/s burst=12 delay=8

最初の8件のリクエスト（delayの値）は、NGINX Plusによって遅延なくプロキシされます。次の4件のリクエスト（burst - delay）には、定義されたレートである5 r/sを超えないように遅延が適用されます。次の3件のリクエストは、合計バーストサイズを超過したため拒否されます。それ以降のリクエストには遅延が適用されます。

この図は、処理済みリクエストが処理中の超過リクエスト数の計算に与える影響を考慮していないため、プロセスを簡略化して説明したものであることに注意してください。実際には、リクエストが1件処理されるたびに遅延キューに空きが生じ、設定されたバーストサイズの範囲内で別の超過リクエストを格納できるようになります。レート制限の実装について詳しくは、F5ブログの「NGINXおよびNGINX Plusによるレート制限」をご覧ください。

OpenID Connectの設定をより簡単に

JWT検証を実行する際、NGINX Plus R17では、新しい「auth_jwt_key_request」ディレクティブで指定したリモートの場所（通常はアイデンティティプロバイダー（IdP））からJSON Web Key（JWK）のセットを取得するように設定できるようになりました。キーを頻繁にローテーションするIdPと統合する場合は、自動取得が特に便利です。

ほとんどのIdPでは、現在のキーセットを取得できる固定URLが提供されています。特に、OpenID Connect Discoveryをサポートしている場合、キーのURLはjwks_uriの値で定義されます。

# Create a directory to cache the keys received from IdPproxy_cache_path /var/cache/nginx/jwk levels=1 keys_zone=jwk:1m max_size=10m;

server {
    listen 80; # Use SSL/TLS in production

    location / {
        auth_jwt "closed site";
        auth_jwt_key_request /_jwks_uri; # Keys will be fetched by subrequest

        proxy_pass http://my_backend;
    }

    location = /_jwks_uri {
        internal;
        proxy_cache jwk; # Cache responses
        proxy_pass https://idp.example.com/oauth2/keys; # Obtain keys from here
    }
}

追加のキャッシュディレクティブを使用して、サブリクエストから返される「Expires」ヘッダーと「Cache-Control」ヘッダーを上書きできます。「proxy_cache_use_stale」を使用すると、キーのURLが利用できない場合でも、NGINX Plusはキャッシュ済みのキーを引き続き使用できます。

F5の「OpenID Connectリファレンス実装」が更新され、auth_jwt_key_requestのサポートと、OpenID Connect DiscoveryをサポートするIdPの自動設定が追加されました。

JWTのサポートも拡張され、エドワーズ曲線デジタル署名アルゴリズム（EdDSA）の2つのバリアント、Ed448とEd25519がサポートされるようになりました。EdDSAにはOpenSSL 1.1.1以降が必要です。執筆時点では、Ubuntu 18.10とFreeBSD 12.0でのみ利用できます。

注： OpenID ConnectはNGINX Plusでのみサポートされます。

2倍高速なNGINX ModSecurity WAF

The NGINX ModSecurity WAFは、100万を超えるサイトで使用されているオープンソースのModSecurity Webアプリケーションファイアウォール（WAF）を、NGINX Plus向けにビルドし、サポートを提供するモジュールです。F5はTrustWave SpiderLabsチームと積極的に連携し、NGINX PlusでのModSecurityのパフォーマンス向上に取り組んでいます。最新リリースでは、以前のリリースと比べてパフォーマンスが2倍に向上しました。

NGINX WAFはレイヤー7攻撃から保護します

このリリースでは、pdateActionById、ctl:requestBodyProcessor=URLENCODED、およびsetenvアクションのサポートも追加されました。

新しいNGINX ModSecurity WAFビルドはModSecurity 3.0.3をベースにしています。詳細については、TrustWave SpiderLabsブログをご覧ください。

注： NGINX ModSecurity WAFはNGINX Plus専用です。

NGINX Plus R17のその他の新機能

アップストリームへのTCPキープアライブ

新しい「proxy_socket_keepalive」ディレクティブでは、NGINX Plusとプロキシ先サーバーの間でTCPキープアライブを有効にするかどうかを制御します。NGINXとプロキシ先サーバーの間にステートフルなTCPネットワークデバイスがあり、接続が長時間維持され、アイドル状態になることが多いプロトコル（WebSocketなど）では、TCPキープアライブによってパフォーマンスが向上します。TCPキープアライブを使用しない場合、このようなデバイスがアイドル状態のTCP接続をより頻繁に切断する可能性があり、接続を最初から再確立するためのオーバーヘッドが発生します。

このディレクティブは、FastCGI、gRPC、memcached、SCGI、uwsgiの各モジュールでも使用できます。

アップストリームHTTPキープアライブのタイムアウトとリクエスト数の上限

新しい「keepalive_timeout」ディレクティブでは、NGINX Plusとプロキシ先サーバー間のHTTPキープアライブ接続が切断されるまでの最大アイドル時間を設定します。また、「keepalive_requests」ディレクティブでは、キープアライブ接続を介して送信できるリクエストの最大数を設定します（この数に達すると接続が切断され、新しい接続が作成されます）。

アップストリームUDPセッションサイズの上限

新しいproxy_requestsディレクティブ（Streamモジュール）は、新しいUDP「セッション」が作成されるまでにNGINX Plusからプロキシ先サーバーへ送信されるUDPパケットの最大数を設定します。これにより、単一のクライアントが短時間に大量のUDPパケットを送信する場合（ダウンストリームプロキシが存在する場合など）に、UDPパケットの負荷をより均等に分散できます。

クラスター状態共有の機能強化

クラスターで状態共有を使用する際、クラスターのノードへの接続時にSNIを使用してサーバー名を渡し、サーバー名を検証できるようになりました。この機能は、zone_sync_ssl_nameディレクティブとzone_sync_ssl_server_nameディレクティブによって実装されます。

注：クラスタリングとzone_syncモジュールはNGINX Plus専用です

NGINX Plusエコシステムのアップデート

Ingress Controllerの機能強化

公式のNGINX Ingress Controller for Kubernetesがバージョン1.4.0に更新されました。変更履歴には、すべての変更、修正、機能強化が記載されています。特に注目すべき点については、F5のブログで詳しくご紹介しています。

• Prometheusサポートの拡張
• TCP/UDP負荷分散
• Random with Two Choicesロードバランシングアルゴリズムが新しいデフォルトになりました
• カスタムアノテーション

詳細については、F5のWebサイトおよび公式NGINX Ingress Controller for KubernetesのGitHubリポジトリをご覧ください。

JavaScriptモジュールの機能強化

NGINX Plus R17には、JavaScript言語のサポート範囲を拡張する複数の機能強化が含まれています。

• argumentsオブジェクト
• 非整数の小数
• その他の時間計測メソッド：console.time()とconsole.timeEnd()
• 変数と関数を再宣言できるようになりました

TCP/UDPアプリケーション向けNGINX Streamモジュールとの統合がリファクタリングされ、受信トラフィックを変更するためのsend()メソッドを含む、各種の戻り関数を使用するようになりました。送信トラフィックはコールバックを通じて利用できるようになりました。

変更内容の全一覧については、NGINX JavaScript Moduleの変更履歴をご覧ください。

NGINX Plusへのアップグレードまたはお試し

NGINX Plus R17は、TLS 1.2よりもセキュリティとパフォーマンスに優れたTLS 1.3をサポートしています。NGINX Plusをご利用の場合は、できるだけ早くRelease 17およびTLS 1.3へアップグレードすることを強く推奨します。これにより、その他のさまざまな修正や改善も適用されるほか、サポートチケットを起票する際にNGINX, Inc.がより適切に支援できるようになります。

アップグレードを実行する前に、このブログ記事で説明している新機能と動作の変更を十分にご確認ください。

まだNGINX PlusまたはNGINX ModSecurity WAFをお試しでない場合は、ぜひご利用ください。セキュリティ、ロードバランシング、APIゲートウェイとして、または強化された監視APIと管理APIを備え、完全なサポートが提供されるWebサーバーとして活用できます。今すぐ30日間の無料評価版を利用して、無料で始められます。NGINX Plusがアプリケーションの配信とスケーリングにどのように役立つか、ぜひお確かめください。

［編集者注：NGINX ModSecurity WAFは2022年4月1日付で正式に販売終了となり、2024年3月31日付でサポート終了となります。詳細については、F5のブログ記事「F5 NGINX ModSecurity WAFのサポート終了への移行<.htmla>」をご覧ください。］

著者について

Liam Crillyプロダクトマネジメント担当シニアディレクター

Liam Crillyのその他のブログ記事