NGINX Plus R10リリースのお知らせ

NGINX | 2016年8月23日

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

これまでで最も重要なリリースとなるNGINX Plus Release 10 (R10)を発表いたします。NGINX Plusは、NGINX Open Sourceに高度な機能と受賞歴のあるサポートを追加し、包括的なアプリケーションデリバリーソリューションを提供します。本リリースでは、NGINX Plusで配信するアプリケーションのセキュリティとパフォーマンスを大幅に向上させるさまざまな新機能に加え、ネットワーク統合の強化や、スクリプトによるNGINX Plusのカスタマイズを支援する追加機能も提供します。

［編集者 – NGINX Plus R10の主な新機能の詳細については、以下の関連リソースをご覧ください。

]

NGINX Plus R10では、Webアプリケーションファイアウォール（WAF）の初期リリースを提供します。ModSecurityを基盤とし、NGINX, Inc.が全面的にサポートします。過去1年間でWebアプリケーションへの攻撃は50%増加し、DDoS攻撃は2倍以上に増加しました。これはAkamaiの調査によるものです。今や、あらゆるアプリケーションが攻撃のリスクにさらされています。NGINX ModSecurity WAFは、悪意のあるユーザーからWebアプリケーションを保護するのに役立ち、アプリケーションとデータの安全性維持を支援する汎用性の高いツールを提供します。

NGINX ModSecurity WAFが侵入者をブロック

NGINX ModSecurity WAFは、新しいModSecurity 3ソフトウェアをベースとし、NGINX Plus内でネイティブに動作します。ダイナミックモジュールリポジトリで追加料金のオプションとして提供され、NGINX, Inc.のサポート対象となっており、NGINX Plusとの組み合わせで十分なテストが実施されています。Trustwaveと連携し、機能の追加、パフォーマンスの向上、問題への対処を進めながら、テスト済みのアップデートを継続的に提供します。

さらに、2つの新機能によってNGINX Plusのセキュリティ機能が強化されました。

JSON Web Token – 多くのお客さまがNGINX PlusをAPIゲートウェイとして使用しており、NGINX PlusレイヤーでAPIへのアクセスを認証するための共通かつ標準的な方法を求めています。このニーズに対応するため、今回のリリースではJSON Web Token（JWT）を使用した認証のサポートを追加しました。NGINX Plusは、クライアントにAPIへのアクセスを許可する前にJWTを検証できるようになりました。この機能により、アプリケーション管理者はオープン標準を使用してAPIへのアクセスを保護でき、独自規格によるベンダーロックインを回避できます。また、ネイティブのJWTサポートにより、OAuth 2.0準拠のOpenID Connectトークンの検証などの認証処理をアプリケーションサーバーからNGINX Plusにオフロードできるため、アプリケーション管理者の作業が簡素化されます。
ECC証明書とRSA証明書の「デュアルスタック」サポート – NGINX Plus R10では、RSA証明書とECC証明書の両方を使用してSSL/TLSサービスを公開できます。NGINX Plusは各クライアントの機能に基づいて最適な証明書を選択するため、従来のRSAのみをサポートするクライアントへの対応を維持しながら、最新のクライアントではより高速なECC証明書を使用できます。ECC証明書は、同等の強度を持つRSA証明書と比べて最大3倍高速です。これにより、サーバーあたりのSSL/TLS接続数が増加し、SSL/TLSハンドシェイクも高速化します。

NGINX Plus R10には、セキュリティ機能に加えて、以下の機能が含まれています。

透過プロキシのサポート – 最新のHTTPアプリケーションの多くは、X-Forwarded-Forヘッダーを利用するように設定できますが、一部のレガシーアプリケーションやその他のTCPまたはUDPサービスでは、ログ記録、セキュリティ、認証のためにトランザクションの送信元IPアドレスを参照します。NGINX Plusでは、アップストリームサーバーに転送するHTTPおよびTCP接続とUDPデータグラムの送信元IPアドレスとポートを「偽装」できるようになりました。これにより、IP透過性を実現できます。これは、NGINX PlusがリモートクライアントのIPアドレスを使用してパケットを送信し、アップストリームサーバーから見たパケットの送信元が、NGINX PlusサーバーのローカルIPアドレスではなく、リモートクライアントのIPアドレスになるようにする構成です。この機能は、UDPベースのプロトコルでDirect Server Returnを有効にするためにも使用できます。
NGINX JavaScriptモジュールのサポート – NGINX JavaScriptモジュールは、NGINXおよびNGINX Plus向けの次世代の設定・制御言語であり、アプリケーションの配信方法とセキュリティ確保をきめ細かく制御できます。このプレビューリリースでは、NGINX JavaScriptモジュールによりHTTP、TCP、UDPトラフィックの制御が強化され、レスポンスを生成し、リクエストを最適なサーバーにルーティングするための精密な判断が可能になります。

TCPおよびUDPロードバランシングのさらなる改善 – Streamモジュールの拡張により、より多くのNGINX変数、mapディレクティブを使用した計算、split_clientsディレクティブによるA/Bテスト、GeoおよびGeoIPの操作、選択的ルーティング（変数パラメーターをproxy_passディレクティブに指定）がサポートされます。これらの拡張により、NGINX構成言語と新しいNGINX JavaScript統合を活用して、より高度なTCPおよびUDPロードバランシングポリシーを作成できます。

NGINX Plus R10の詳細

NGINX ModSecurity Web Application Firewall

NGINX Plus R10の目玉機能は、広く知られ信頼されているModSecurityテクノロジーを基盤とするWAFの初回リリースです。ModSecurityは、2002年にオープンソースとして初めてリリースされて以来、悪意のあるユーザーから世界最大級のWebプロパティを保護するのに役立ってきました。セキュリティの「Swiss Army® knife」とも呼ばれています。NGINX ModSecurity WAFは追加料金のオプションで、ダイナミックモジュールリポジトリを通じてサブスクライバーに提供されます。

NGINX ModSecurity WAFは、重要なアプリケーションのセキュリティ確保に役立つ必須のソリューションです。柔軟性に欠ける高価なハードウェアアプライアンス（F5、Citrix、Impervaが提供する製品など）に代わるコスト効率の高い選択肢であり、ソフトウェアならではの柔軟性によって、それらを上回る機能も提供します。NGINX ModSecurity WAFは、オンプレミスサーバー、パブリッククラウド、プライベートクラウド、ハイブリッドクラウドなど、あらゆる環境に導入できます。

NGINX ModSecurity WAFは、DDoS攻撃からの保護に役立ちます

WAFは、ブロックやログ記録の対象となる悪意のある動作を定義した「ルール」のデータベースに基づいて動作します。OWASP ModSecurityコアルールセット（CRS）は、ModSecurityで最も広く使用されているルールセットの1つです。NGINX ModSecurity WAFはOWASP CRSを使用し、次のような機能によって幅広いアプリケーション攻撃を特定してブロックします。

レイヤー7攻撃対策 – HTTP違反、SQLインジェクション、XSS、RFI、LFIなど、幅広い攻撃からアプリケーションを保護します。
DDoS攻撃の緩和 – 高度なアプリケーションレベルのDDoS攻撃やボットネットを緩和し、その影響を軽減することで、継続的な稼働を維持します。
リアルタイム拒否リスト – レピュテーションに基づいて悪意があると判定されたIPアドレスからのトラフィックを拒否し、既知の悪意あるユーザーを自動的にブロックします。
PCI-DSS 6.6への準拠 – 安全なオンライン取引に関するPCI-DSS 6.6の要件への準拠を開始できます。
監査ログ – 詳細なログの情報を活用して、攻撃やその他の異常なアプリケーショントラフィックに、より迅速に対応できます。

さらに、TrustWaveなどのさまざまなベンダーから、価格帯の異なる追加のルールセットも提供されています。また、強力なModSecurityルール言語を使用して、現在使用しているルールセットを補完する独自のカスタムルールを定義できます。

NGINX ModSecurity WAFのサポートは、NGINX, Inc.が直接提供します。サポートチームが、WAFおよびOWASPコアルールセットのインストール、設定、問題のデバッグを支援します。

NGINX ModSecurity WAFは、標準のパッケージ管理ツールを使用してインストールできるダイナミックモジュールとして、NGINX Plusリポジトリで提供されています。以下のコマンドは、Debianベースのオペレーティングシステム向けです。

# apt-get update# apt-get install nginx-plus
# apt-get install nginx-plus-module-modsecurity

NGINX ModSecurity WAFモジュールを購入したサブスクライバー、およびアクセスをリクエストしたサブスクライバーと評価版ユーザーのみが、nginx-plus-module-modsecurityパッケージをダウンロードできることに注意してください。

NGINX ModSecurity WAFモジュールを読み込むには、NGINX Plus構成ファイルの最上位の「main」コンテキストにload_moduleディレクティブを含めます。

コード例を読み込み中…

NGINX PlusでNGINX ModSecurity WAFを有効にするには、ルールセットを指定するために、modsecurityディレクティブとmodsecurity_rules_fileディレクティブを含めます。

コード例を読み込み中…

次に、NGINX Plusの設定を再読み込みします：

# nginx -t && nginx -s reload

OAuth 2.0およびOpenID ConnectのネイティブJWTサポート

JSON Web Token（JWT）認証標準をネイティブにサポートするNGINX Plus R10により、アプリケーションやAPIに高度な認証ソリューションを簡単に追加できます。

「jot」と発音するJWTトークンは、RFC 7519で定義されており、OAuth 2.0プロトコル上の標準的なアイデンティティレイヤーであるOpenID Connect標準において、ユーザー情報の基盤となるデータ形式です。また、シンプルで柔軟なことから、APIやマイクロサービスの導入担当者にもJWT標準の採用が広がっています。

［編集者 – ネイティブJWTサポートを活用するユースケースについては、以下のブログをご覧ください：

JWTとNGINX PlusによるAPIクライアントの認証

OpenID ConnectとNGINX Plusを使用した既存アプリケーションのユーザー認証

]

NGINX Plusは、クライアントにアクセスを許可する前にJWTを検証します

NGINX Plusは、リバースプロキシおよびロードバランサーとしてアプリケーションの前段に配置されるため、各HTTPリクエストで提供されるJWTの検証をオフロードし、アプリケーション開発を簡素化するのに最適な位置にあります。これには2つの利点があります。第1に、NGINX Plusは、未認証のリクエスト、不正な形式のリクエスト、悪意のあるリクエストがアプリケーションに到達するのを防ぎ、こうしたリクエストの処理に伴う負担とリスクからアプリケーションを保護するのに役立ちます。

2つ目のメリットは、NGINX Plusが署名検証後の検証済みJWTに含まれるすべてのフィールドにアクセスでき、その設定構文が本来備える強力さと柔軟性を活用して、マイクロサービスとAPIの両方に高度な認証ソリューションを提供できることです。

マイクロサービスの一般的なユースケースでは、NGINX PlusでJWTを検証し、認証済みユーザーのIDをHTTPヘッダーとしてバックエンドアプリケーションに渡します。これにより、すべてのマイクロサービスに同じ認証機能を繰り返し実装する必要がなくなります。
APIでは、IPアドレスとエンドユーザーのおおよその対応付けに依存することなく、NGINX Plusで実際のユーザー単位にアクセスをレート制限できます。

次のNGINX Plus構成スニペットの例では、JWTを使用してWebサイトを保護する方法を示します。

The auth_jwtディレクティブは、ドメイン（この場合はmyrealm）にリクエストを送信するユーザーをJWTで認証するようNGINX Plusに指示します。auth_jwt_key_fileディレクティブは、トークン署名の検証に使用するJSON Web Key（JWK）を指定します。このキーは、SSL/TLS暗号化における公開鍵と同様に機能します。ファイルの保存場所は、NGINX Plusからアクセス可能である必要があります。

NGINX Plusは、トークンを検証して解析する際に、JWT内の「クレーム」に対応するNGINX変数を自動的に作成します。クレームは、JWTに関連付けられたエンティティ（発行者、発行先のユーザー、対象となる受信者など）を表します。変数名はすべて$jwt_claim_で始まります。その後、add_headerディレクティブを使用すると、NGINX Plusはクレームをバックエンドサーバーに渡すことができます。このクレームは、$jwt_claim_変数の値を設定したHTTPヘッダーとして渡されます。この例では、NGINX Plusは$jwt_claim_sub変数を使用してユーザーIDをバックエンドアプリケーションに渡します。この変数は、JWT内のユーザーID（subクレーム）に対応します。

コード例を読み込み中…

In NGINX Plus R8では、OAuth2 サポートのテクノロジープレビューをリリースしました。NGINX Plus R10では、お客さまからのフィードバックを取り入れ、ユーザーやコンピューターの認証という複雑な領域で特に重要なユースケースに対応する、本番環境向けの実装を提供しています。

「デュアルスタック」RSAおよびECC証明書のサポート

今や、すべてのアプリケーショントラフィックをSSL/TLSで暗号化すべき理由は数多くあります。Googleでは、SSL/TLSで暗号化されたサイトは検索エンジンでの掲載順位が高くなるというメリットがあります。さらに、HTTP/2などの最新のWeb標準では、すべてのWebサイトにSSL/TLS暗号化が必須となっています。

NGINX Plus R10では、RSA証明書とECC証明書の両方を使用してSSL/TLSサービスを公開できます。F5のテストでは、ECC証明書は同等の強度を持つRSA証明書と比べて最大3倍高速でした。これにより、サーバーあたりのSSL/TLS接続数が増え、SSL/TLSハンドシェイクも高速化します。NGINX Plusは各クライアントの機能に基づいて最適な証明書を選択するため、従来のRSAのみをサポートするクライアントへの対応を維持しながら、最新のクライアントではより高速なECC証明書を使用できます。

RSA証明書とECC証明書の両方をサポートするには、次の例のように、仮想サーバーの設定で証明書タイプごとに一対の「ssl_certificate」ディレクティブと「ssl_certificate_key」ディレクティブを指定するだけです。

コード例を読み込み中…

透過プロキシ

より幅広いアプリケーションと導入モデルに対応するため、NGINX PlusにはTCPおよびUDPの負荷分散などの機能を継続的に追加しています。NGINX Plus R10では、任意の送信元IPアドレスとポートを使用してアップストリームサーバーにパケットを送信できる透過プロキシ機能を追加しました。これにより、IP TransparencyやDirect Server Returnなどの構成が可能になります。

IP Transparencyは、ロードバランサー（NGINX Plus）がアップストリームサーバーに送信するパケットの送信元IPアドレスとして、リモートクライアントのIPアドレスを使用する構成です。これにより、アップストリームサーバーでは、パケットがロードバランサーのローカルIPアドレスではなく、リモートクライアントのIPアドレスから送信されたものとして認識されます。これは、アプリケーションがログ記録、セキュリティ、レート制限、認証の目的で送信元IPアドレスを参照する場合に重要です。

IP Transparencyは、ネットワーク負荷分散手法である「Direct Server Return」（DSR）を構成する要素でもあります。NGINX Plusは、UDPベースのプロトコルに対してDSRを実行できます（TCPまたはHTTPには対応していません）。これにより、応答パケットはロードバランサーを完全に迂回し、リモートクライアントに直接送信されます。

DSRモードでは、バックエンドサーバーがクライアントに直接応答します

IPトランスペアレンシーとDSRは、transparentディレクティブの新しいパラメーターを、proxy_bind、fastcgi_bind、memcached_bind、scgi_bind、およびuwsgi_bindディレクティブに指定して構成します。次の例は、DNSバックエンド用にDSRを設定する方法を示しています。proxy_responsesディレクティブは、NGINX Plusがサーバーからの応答を確認する必要がないことを指定します（DSRには0が適切な値です）。

コード例を読み込み中…

DSRが有効な場合、パッシブヘルスチェックは有効に機能しないことに注意してください。これは、NGINX Plusがサーバーからクライアントに応答が送信されたことを確認する仕組みであるためです。DSR構成では、アクティブなアプリケーション対応ヘルスチェックの設定が必須です。設定例については、負荷分散されたDNSサーバー向けの詳細な手順を参照してください。

IP TransparencyとDSRの構成は複雑で、NGINX Plusソフトウェアの範囲外となる追加のルーティング要件とパケット書き換え要件があります。詳細な手順については、F5のブログ記事「透過プロキシとしてのNGINXおよびNGINX PlusによるIP TransparencyとDirect Server Return」をご覧ください。

HTTP、TCP、UDPベースのアプリケーション向けNGINX JavaScriptモジュール

[編集者 – NGINX JavaScriptモジュールは、以前はnginScriptと呼ばれていました。このモジュールは、NGINX Plus R12（およびNGINX 1.11.10）で一般提供が開始されました。

NGINX JavaScriptモジュールのその他のユースケースについて詳しくは、「NGINX JavaScriptモジュールのユースケース」をご覧ください。

このセクションのコードは、 js_importディレクティブを使用するように更新されています。このディレクティブは、js_includeディレクティブに代わるもので、NGINX Plus R23以降で使用されます。詳細については、NGINX JavaScriptモジュールのリファレンスドキュメントを参照してください。設定例セクションでは、NGINX設定ファイルとJavaScriptファイルの正しい構文を示しています。]

NGINX Plus R10には、新しいNGINX JavaScript構成言語のプレビューリリースが含まれています。まだすべての機能が実装されているわけではありません。現時点での成果について、ぜひフィードバックをお寄せください。NGINX JavaScriptでは、JavaScriptコードを使用して、HTTP、TCP、UDPトラフィックに対して複雑なカスタム処理を実行できます。これにより、アプリケーションの配信方法とセキュリティ保護を制御するための強力な新しい手段が得られます。NGINX JavaScriptでは、次のことが可能です。

強力なJavaScriptプログラミング言語を使用して、NGINX Plus内に「サーバーレス」関数を直接記述
APIデータの書式設定、操作、変換
タイムサーバーなどのシンプルなTCPサービスを提供
JavaScriptを使用して、NGINX変数の設定、カスタムの負荷分散ロジックやキャッシュキーの作成などを行う

NGINX JavaScriptプレビューは、F5のダイナミックモジュールリポジトリで提供されています。標準のパッケージ管理ツールを使用してインストールできます。以下のコマンドは、Debianベースのオペレーティングシステム向けです。

# apt-get update
# apt-get install nginx-plus
# apt-get install nginx-plus-module-njs

HTTPおよびTCP/UDP用のNGINX JavaScriptモジュールを読み込むには、NGINX Plus構成ファイルの最上位の「main」コンテキストにload_moduleディレクティブを含めます。

コード例を読み込み中…

次に、NGINX JavaScriptモジュールを読み込むため、NGINX Plusの設定を再読み込みします：

# nginx -t && nginx -s reload

NGINX Open Sourceユーザーは、F5のオープンソースコードリポジトリからNGINX JavaScriptを入手できます。

JavaScriptコードはNGINX Plusの設定に直接含めません。代わりに、js_importディレクティブを使用して読み込みます。この例では、シンプルな「サーバーレス」関数のJavaScriptコードを/etc/nginx/conf.d/functions.jsから読み込みます。js_contentディレクティブは、JavaScript関数を呼び出し、その結果をクライアントに返すようNGINX Plusに指示します。

コード例を読み込み中…

The JavaScript code in /etc/nginx/conf.d/functions.jsのJavaScriptコードは、指定された文字セットを使用して文字列をパディングします：

コード例を読み込み中…

その他の機能

NGINX Plus R10では、安定したアプリケーションデリバリを支援するため、以下を含むさまざまな機能強化が追加されています。

TCP/UDP load balancing, implemented in the Streamモジュールに実装されたTCP/UDPロードバランシングでは、HTTPロードバランシングとの機能の同等性がさらに向上しました。新たにサポートされるモジュールには、A/Bテスト用のSplit Clients、クライアントの地理的位置に基づいて処理を実行するためのGeoIP、IPアドレスに基づいて変数を定義するためのGeoがあります。追加のNGINX変数を通じてより多くの情報を取得できるほか、変数をproxy_passディレクティブのパラメーターとして使用して、ルーティングを決定できます。
トラフィック量の多いアプリケーションでよく発生する問題の1つに、エフェメラルポートの枯渇があります。これは、OSで使用可能なポート番号が不足し、アップストリームサーバーへの新しい接続を確立できなくなる問題です。この問題に対処するため、NGINX Plusでは、利用可能な場合にIP_BIND_ADDRESS_NO_PORTソケットオプションを使用するようになりました。このオプションを使用すると、標準の「4タプル」（送信元IPアドレス、宛先IPアドレス、送信元ポート、宛先ポート）が一意である限り、アップストリームサーバーへの送信接続で送信元ポートを再利用できます。この機能は、Linuxカーネルバージョン4.2以降およびglibc 2.22以降を搭載したシステムで利用できます。
NGINX Plusは、新しいHTTPリクエストごとに新しい変数「$request_id」を自動生成し、実質的に一意の「トランザクションID」をリクエストに割り当てます。これにより、アプリケーションのトレースが容易になり、ログ分析ツールでAPM機能を利用できるようになります。トランザクションIDはバックエンドアプリケーションとマイクロサービスにプロキシされるため、システムのすべての部分で各トランザクションに共通する識別子をログに記録できます。
The proxy_request_buffering、fastcgi_request_buffering、scgi_request_buffering、uwsgi_request_bufferingの各ディレクティブがHTTP/2に対応し、リクエストバッファリングのオンとオフを切り替えられるようになりました。
新しいhttp2_body_preread_sizeディレクティブにより、HTTP/2クライアントはリクエストボディの送信を直ちに開始できます。このディレクティブは、NGINX Plusがクライアントのリクエストボディの読み取りを開始する前に使用するバッファのサイズを制御します。

NGINX Plus Extrasパッケージの非推奨化

NGINX Plus R9のリリース時に事前にお知らせしたとおり、NGINX Plus Extrasパッケージが含まれるのはR10が最後です。

nginx-plusパッケージを使用し、nginx-plus-extrasパッケージに含まれるモジュールのうち、実際に使用するものを動的にロードするよう、インストールおよび構成手順を今すぐ変更することを強く推奨します。NGINX Plus R11以降、nginx-plusパッケージに組み込まれていないモジュールを使用するには、この方法しかありません。

nginx-plusパッケージと動的モジュールに切り替えるには、次の手順を実行します。

nginx-plus-extrasパッケージを削除し、nginx-plusと使用する動的モジュールをインストールします。Debianベースのシステムでは、次の一連のコマンドを実行します。

# apt-get update
# apt-get remove nginx-plus-extras
# apt-get install nginx-plus
# apt-get install module-name

In the main (top‑level) context in /etc/nginx/nginx.conf のメイン（最上位）コンテキストに、動的にロードする各モジュールの load_module ディレクティブを追加します。
コード例を読み込み中…
新しい設定の構文が有効であることを確認し、再読み込みします：

# nginx -t && nginx -s reload

NGINX Plusへのアップグレードまたは無料トライアル

NGINX Plusをご利用の場合は、できるだけ早くRelease 10へアップグレードすることを強く推奨します。多数の修正と改善が適用されるほか、サポートチケットを起票する必要が生じた際に、F5がより円滑にサポートできるようになります。インストールとアップグレードの手順については、NGINX Plusカスタマーポータルをご覧ください。

注記：NGINX Plus R10は、nginx-plus-extrasパッケージを含む最後のリリースです。上記の「NGINX Plus Extrasパッケージの非推奨化」を参照してください。

まだNGINX Plusをお試しでない場合は、Webアクセラレーション、負荷分散、アプリケーションデリバリに、または強化された監視および管理APIを備え、充実したサポートを受けられるWebサーバーとして、ぜひお試しください。今すぐ無料の30日間評価版を利用して、NGINX Plusがアプリケーションのデリバリとスケールアウトにどのように役立つかをご確認いただけます。