NGINX Plus R17 の発表

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

NGINX Plus リリース 17 (R17)が利用可能になったことをお知らせします。 NGINX Plus は、ロードバランサー、コンテンツ キャッシュ、Web サーバー、API ゲートウェイをオールインワンで実現した唯一の製品です。 NGINX Plus は NGINX オープンソースをベースとしており、独自の拡張機能と受賞歴のあるサポートが含まれています。

このリリースの新機能は、インターネット上のすべての安全なトラフィックを担当するプロトコルの最新バージョンである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 をサポートしているため、本番環境で TLS 1.3 用のNGINX Plus R17と併用できます。他の OS ベンダーも、将来のリリースで TLS 1.3 をサポートすることは間違いありません。 F5 BIG-IPおよびその他のハードウェア ロード バランサーは現在、TLS 1.3 を完全にサポートしていないことに注意してください。

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

• 2 段階のレート制限- レート制限は、NGINX Open Source と NGINX Plus で最も人気のある機能の 1 つです。 これは、DDoS 攻撃を軽減し、一般的にアプリケーション サーバーが過剰なリクエストによって圧倒されることを防ぐために使用できます。 新しい遅延パラメータは、NGINX Plus のレート制限が一般的なブラウザのリクエスト パターンに適切に対応するのに役立ちます。 既存の遅延と拒否の強制方法を組み合わせて 2 段階のレート制限を提供できるようになりました。これにより、過剰なリクエストは最初に遅延され、それでもレート制限を超えている場合は最終的に拒否されます。
• より簡単な OpenID Connect 構成– NGINX Plus R15では、 OpenID Connect 統合を導入し、お客様がアプリケーションにシングル サインオン (SSO) を追加できるようにしました。 R17 では、アイデンティティ プロバイダー (IdP) から JSON Web キー (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 および Upstream Conf API が置き換えられました。 当時発表されたとおり、非推奨の API はかなりの期間にわたって引き続き利用可能でサポートされていましたが、 NGINX Plus R16で終了しました。 構成にstatusディレクティブやuploaded_confディレクティブが含まれている場合は、R17 へのアップグレードの一環として、それらをapiディレクティブに置き換える必要があります。

  NGINX Plus APIへの移行に関するアドバイスやサポートについては、ブログの移行ガイドを参照するか、サポート チームにお問い合わせください。

• サポートされる新しいオペレーティング システム:

  • アルパイン Linux 3.8
  • アルパイン Linux 3.9
  • フリーBSD11.2
  • フリーBSD 12.0
  • SUSE Linux Enterprise Server 15
  • Ubuntu 18.10 (コズミック)

• 削除された、または削除予定の古いオペレーティング システム:

  • FreeBSD 10.4 および 11.1 はサポートされなくなりました。
  • CentOS/Oracle/RHEL 7.3 以前のサポートは、 NGINX Plus R18では廃止されます。
  • NGINX Plus R19では Ubuntu 14.04 のサポートが廃止されます。

新機能の詳細

TLS 1.3: 減算による加算

TLS のメジャーアップデートから 10 年以上経ちました。 TLS 1.2 は 2008 年 8 月にRFC 5246として定義され、それ以来インターネットは大きく変化しました。 TLS 1.3 は、TLS 1.2 で見つかった多くの問題に対処し、将来に向けてよりスケーラブルなプラットフォームを確立するために、2018 年 8 月にRFC 8446として承認されました。

より安全に

長年にわたり、 FREAK 、 Heartbleed 、 POODLE 、 ROBOTなど、TLS 1.2 のセキュリティ脆弱性が数多く公開されてきました。 たとえば、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 キー トランスポートです。 このモードが主に使用されたのは、Perfect Forward Secrecy (PFS) による接続を確立するために追加のラウンドトリップを必要とする Diffie-Hellman よりも高速だったためです。 TLS 1.3 では追加のラウンドトリップは不要になります。 構成オプションが少ないため、交換する情報が少なくなり、Diffie-Hellman ハンドシェイクは 1 回の往復で完了します (図には、ハンドシェイク後のGET要求も示されています)。

さらに、TLS 1.3 はセッション再開をサポートしており、クライアントが以前にアクセスしたサイトに戻ったときに TLS ハンドシェイクを繰り返すオーバーヘッドを排除することで、接続の確立が高速化されます。 これは、再開されたセッションでクライアントとサーバーの間でハンドシェイク メッセージをやり取りする必要がないため、0-RTT (ゼロ ラウンド トリップ時間) 再開とも呼ばれます。 セッションの再開は、元のセッション中に共有秘密を作成し、それをセッション チケットに保存することによって実装されます。 クライアントが戻ると、チケット内の共有シークレットで暗号化されたセッション チケットがリクエストとともに提示されます。

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

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

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

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

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

TLS 1.3 を有効にするには、 ssl_protocolsディレクティブにTLSv1.3パラメータを含めます。 執筆時点ではすべてのブラウザが TLS 1.3 をサポートしているわけではないため、 TLSv1.2も含めることをお勧めします (次のセクションを参照)。 NGINX Plus は、クライアントが TLS 1.3 をサポートしている場合は 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 ; # 0-RTT (TLS 1.3) を有効にする location / { proxy_pass http://my_backend; } }

サポートされているプラットフォーム

サーバー側では、TLS 1.3 には OpenSSL 1.1.1 以降が必要です。 この記事の執筆時点では、Alpine Linux 3.9、FreeBSD 12.0、Ubuntu 18.10 のみに OpenSSL 1.1.1 が搭載されています。

クライアント側では、Chrome 70 または Firefox 63 をお勧めします。 TLS 1.3 の最終バージョンをサポートしていますが、デフォルトでは有効になっていません。ブラウザで TLS 1.3 を有効にするには、次の手順に従ってください。 この記事の執筆時点では、他の一般的なブラウザ (Android 版 Firefox、iOS 版と Mac 版 Safari など) はまだ TLS 1.3 をサポートしていません。 最新のステータス情報については、 使用できるもの: TLS1.3 。

2段階のレート制限

以前は、NGINX Plus は、過剰なリクエストを直ちに拒否するか、定義されたレート制限に従って処理できるようになるまで過剰なリクエストをキューに入れるかの 2 つの方法でリクエスト レートの制限を適用できました。 NGINX Plus R17では、2 段階のレート制限に両方の強制方法を組み合わせることができます。これにより、過剰なリクエストは最初に遅延され、レート制限をまだ超過している場合は最終的に拒否されます。

レート制限を適用するときは、正当なクライアントの典型的な動作を考慮することが重要です。 たとえば、Web ブラウザは通常、複数のリソースを同時にダウンロードしようとするため、HTML コンテンツのリクエストの直後にスタイルシート、JavaScript コード、画像のリクエストが続くのは当然です。 このため、レート制限を適用する前に、10 ～ 20 件の急速なリクエストのバーストを許可することが必要な場合があります。

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

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

limit_req_zone $binary_remote_addr ゾーン=ip:10m レート=5r/s;
server {
listen 80;
location / {
limit_req ゾーン=ip バースト=12 遅延=8;
proxy_pass http://website;
}
}

遅延パラメータは、バースト サイズ内で、定義されたレート制限に準拠するために過剰なリクエストが調整 (遅延) されるポイントを定義します。 この構成では、8 r/s でリクエストの連続ストリームを実行するクライアントでは、次のような動作が発生します。

最初の 8 つのリクエスト ( delayの値) は、遅延なく NGINX Plus によってプロキシされます。 次の 4 つの要求 (バースト-遅延) は、定義されたレート 5 r/s を超えないように遅延されます。 合計バースト サイズを超えたため、次の 3 つの要求は拒否されます。 後続のリクエストは遅延されます。

この図は、過剰なリクエストがいくつ処理されているかを計算する際の完了したリクエストの影響を無視しているため、プロセスを簡略化して説明したものであることに注意してください。 実際には、完了したリクエストごとに、構成されたバースト サイズ内に収まるように、別の過剰なリクエスト用のスロットが遅延キューに開きます。 レート制限の実装の詳細については、ブログの「NGINX および NGINX Plus を使用したレート制限」を参照してください。

OpenID Connect の設定が簡単になりました

JWT 検証を実行する場合、 NGINX Plus R17 は、新しいauth_jwt_key_requestディレクティブで指定されたリモート ロケーション (通常は ID プロバイダー、つまり IdP) から JSON Web キー (JWK) のセットを取得するように設定できるようになりました。 自動フェッチは、キーを頻繁にローテーションする IdP と統合する場合に特に便利です。

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

# IdPproxy_cache_path /var/cache/nginx/jwk から受信したキーをキャッシュするディレクトリを作成します。levels=1 keys_zone=jwk:1m max_size=10m;

server {
listen 80; # 本番環境では SSL/TLS を使用します

location / {
auth_jwt "closed site";
auth_jwt_key_request /_jwks_uri; # キーはサブリクエストによって取得されます

proxy_pass http://my_backend;
}

location = /_jwks_uri {
internal;
proxy_cache jwk; # 応答をキャッシュします
proxy_pass https://idp.example.com/oauth2/keys; # ここからキーを取得します
}
}

追加のキャッシュ ディレクティブを使用して、サブリクエストによって返されるExpires ヘッダーとCache-Controlヘッダーをオーバーライドできます。 proxy_cache_use_staleを使用すると、キーの URL が利用できない場合でも、NGINX Plus はキャッシュされたキーを引き続き使用できます。

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

NGINX Plus 用のNGINX ModSecurity WAFモジュールは、100 万を超えるサイトで使用されているオープン ソースの ModSecurity Web アプリケーション ファイアウォール (WAF) のサポート対象ビルドです。 当社は TrustWave SpiderLabs チームと積極的に協力して、NGINX Plus を使用した ModSecurity のパフォーマンスの向上に取り組んでおり、最新リリースのパフォーマンスは以前のリリースの 2 倍向上したことを報告できてうれしく思います。

このリリースでは、 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 キープアライブを有効にするかどうかを制御します。 TCP キープアライブは、NGINX とプロキシ サーバーの間にステートフル TCP ネットワーク デバイスがあり、接続が長時間持続し、アイドル状態になることが多いプロトコル (WebSocket など) のパフォーマンスを向上させます。 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 エコシステムのアップデート

イングレス コントローラの機能強化

Kubernetes 用の公式 NGINX Ingress Controller がバージョン 1.4.0 に更新されました。 変更ログにはすべての変更、修正、機能強化がリストされており、最も注目すべきものはブログで強調表示されています。

• 拡張されたPrometheusサポート
• TCP/UDP 負荷分散
• ランダム2択負荷分散アルゴリズムが新しいデフォルトになりました
• カスタム注釈

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

JavaScript モジュールの機能強化

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

• 引数オブジェクト
• 非整数分数
• 追加の時間メソッド: console.time()およびconsole.timeEnd()
• 変数と関数を再宣言できるようになりました

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

変更内容の完全なセットは、NGINX JavaScript モジュールの変更ログで確認できます。

NGINX Plus をアップグレードまたは試用する

NGINX Plus R17には、TLS 1.2 よりも安全でパフォーマンスに優れた TLS 1.3 のサポートが含まれています。 NGINX Plus を実行している場合は、できるだけ早くリリース 17 および TLS 1.3 にアップグレードすることを強くお勧めします。 また、多数の追加の修正と改善も行われ、サポート チケットを発行する必要があるときに NGINX, Inc. がサポートしやすくなります。

アップグレードを進める前に、このブログ投稿に記載されている新機能と動作の変更をよく確認してください。

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

[編集者注– NGINX ModSecurity WAF は、2022 年 4 月 1 日をもって正式に販売終了となり、 2024 年 3 月 31 日をもってサポート終了となります。 詳細については、弊社ブログの「F5 NGINX ModSecurity WAF はサポート終了に移行しています<.htmla>」をご覧ください。