EOLのDocker NGINXベースイメージのアップグレード¶

本ドキュメントでは、稼働中のサポート終了（EOL）のDocker NGINXベースイメージ（バージョン3.6以下）を6.xにアップグレードする手順を説明します。

Wallarm nodes 3.6 and lower are not supported

You are recommended to upgrade the Wallarm nodes 3.6 and lower since these versions are not supported, they are end-of-life.

Node configuration and traffic filtration have been significantly simplified in the Wallarm node of the latest versions. Before upgrading the modules, please carefully review the list of changes and general recommendations. Please note that some settings of the latest node are incompatible with the nodes 3.6 and lower.

要件¶

Docker installed on your host system
Access to https://hub.docker.com/r/wallarm/node to download the Docker image. Please ensure the access is not blocked by a firewall
Access to the account with the Administrator role in Wallarm Console in the US Cloud or EU Cloud
Access to https://us1.api.wallarm.com if working with US Wallarm Cloud or to https://api.wallarm.com if working with EU Wallarm Cloud. Please ensure the access is not blocked by a firewall
Access to the IP addresses and their corresponding hostnames (if any) listed below. This is needed for downloading updates to attack detection rules and API specifications, as well as retrieving precise IPs for your allowlisted, denylisted, or graylisted countries, regions, or data centers
US CloudEU Cloud
node-data0.us1.wallarm.com - 34.96.64.17 node-data1.us1.wallarm.com - 34.110.183.149 us1.api.wallarm.com - 35.235.66.155 34.102.90.100 34.94.156.115 35.235.115.105
node-data1.eu1.wallarm.com - 34.160.38.183 node-data0.eu1.wallarm.com - 34.144.227.90 api.wallarm.com - 34.90.110.226

手順1: フィルタリングノードモジュールをアップグレードすることをWallarmテクニカルサポートに連絡します（ノード2.18以下をアップグレードする場合のみ）¶

ノード2.18以下をアップグレードする場合は、フィルタリングノードモジュールを6.xにアップグレードする旨をWallarmテクニカルサポートに連絡し、Wallarmアカウントに対して新しいIPリストロジックの有効化を依頼してください。新しいIPリストロジックが有効になったら、Wallarm ConsoleのIP listsセクションが利用可能であることを確認してください。

手順2: Threat Replay Testingモジュールを無効化します（ノード2.16以下をアップグレードする場合のみ）¶

Wallarmノード2.16以下をアップグレードする場合は、Wallarm Console→Vulnerabilities→ConfigureでThreat Replay Testingモジュールを無効化してください。

アップグレードの過程でこのモジュールの動作により誤検知が発生する可能性があります。モジュールを無効化すると、このリスクを最小化できます。

手順3: APIポートを更新します¶

Starting with version 4.0, the filtering node uploads data to the Cloud using the us1.api.wallarm.com:443 (US Cloud) and api.wallarm.com:443 (EU Cloud) API endpoints instead of us1.api.wallarm.com:444 and api.wallarm.com:444.

If you upgrade the node from the version 3.x or lower and your server with the deployed node has a limited access to the external resources and the access is granted to each resource separately, then after upgrade the synchronization between the filtering node and the Cloud will stop.

To restore the synchronization, in your configuration, change port 444 to 443 for API endpoint for each resource.

手順4: 更新済みのフィルタリングノードイメージをダウンロードします¶

docker pull wallarm/node:6.4.1

手順5: Wallarm Cloudへのトークンベース接続に切り替えます¶

Wallarm Cloudにコンテナを接続する方法は次のように更新されました。

「email and password」ベースの方法は非推奨になりました。この方法では、DEPLOY_USERおよびDEPLOY_PASSWORD変数に正しい認証情報を指定してコンテナを起動すると、ノードは自動的にWallarm Cloudに登録されていました。
トークンベースの方法が追加されました。コンテナをCloudに接続するには、Wallarm ConsoleのUIからコピーしたWallarm APIトークンを含むWALLARM_API_TOKEN変数を指定してコンテナを実行します。

6.xのイメージの実行には新しい方法を使用することを推奨します。「email and password」ベースの方法は将来のリリースで削除されますので、事前に移行してください。

新しいWallarmノードを作成してトークンを取得するには次のとおりです。

Wallarm Console→Settings→API Tokensを開き、使用タイプにNode deployment/Deploymentを選択してトークンを生成します。
生成したトークンをコピーします。

手順6: 以前のWallarmノードバージョンから6.xへallowlist/denylistを移行します（ノード2.18以下をアップグレードする場合のみ）¶

ノード2.18以下をアップグレードする場合は、以前のWallarmノードバージョンのallowlist/denylist設定を6.xへ移行してください。

手順7: 非推奨の設定オプションから切り替えます¶

以下の設定オプションは非推奨です。

WALLARM_ACL_ENABLE環境変数は非推奨になりました。

IPリストを新しいノードバージョンに移行した場合は、この変数をdocker runコマンドから削除してください。
TARANTOOL_MEMORY_GB環境変数でpostanalyticsのメモリ量を設定している場合は、変数名をSLAB_ALLOC_ARENAに変更してください。
以下のNGINXディレクティブは名称が変更されました。
- wallarm_instance → wallarm_application
- wallarm_local_trainingset_path → wallarm_custom_ruleset_path
- wallarm_global_trainingset_path → wallarm_protondb_path
- wallarm_ts_request_memory_limit → wallarm_general_ruleset_memory_limit
変更はディレクティブ名のみであり、動作は同じです。旧名称のディレクティブは間もなく非推奨になりますので、事前に名称を変更することを推奨します。

マウントしている設定ファイル内で旧名称のディレクティブを明示的に指定していないか確認してください。指定している場合は名称を変更してください。
wallarm_request_timeログ変数はwallarm_request_cpu_timeに名称変更されました。

変更は変数名のみであり、動作は同じです。旧名称も当面はサポートされますが、変数の名称は変更することを推奨します。

手順8: Wallarmのブロッキングページを更新します（NGINXベースイメージをアップグレードする場合）¶

新しいノードバージョンでは、Wallarmのサンプルブロッキングページが変更されました。ページ上のロゴとサポート用メールアドレスはデフォルトで空になっています。

Dockerコンテナがブロック対象のリクエストに対して&/usr/share/nginx/html/wallarm_blocked.htmlページを返すように設定されている場合は、次のように設定を変更してください。

サンプルページの新しいバージョンをコピーしてカスタマイズします。
次の手順で、新しいDockerコンテナにカスタマイズしたページとNGINXの設定ファイルをマウントします。

手順9: 直近のアーキテクチャ変更を確認します（NGINXベースのDockerイメージ向け）¶

最新のアップデートでは、イメージの最適化やPostanalytics向けのTarantoolのwstoreへの置き換えに伴うアーキテクチャの変更が導入されています。特定のファイルのパスが変更されたため、特にコンテナ起動時にカスタム設定ファイルをマウントしているユーザーに影響する可能性があります。新しいイメージを正しく設定・利用できるよう、これらの変更点を把握してください。

手順10: `overlimit_res`攻撃検出の設定をディレクティブからルールへ移行します¶

Starting from the version 3.6, you can fine-tune the overlimit_res attack detection using the rule in Wallarm Console.

Earlier, the wallarm_process_time_limit and wallarm_process_time_limit_block NGINX directives have been used.

The listed directives and parameters are considered to be deprecated with the new rule release and will be deleted in future releases.

If the overlimit_res attack detection settings are customized via the listed parameters, it is recommended to transfer them to the rule as follows:

Open Wallarm Console → Rules and proceed to the Limit request processing time rule setup.
Configure the rule as done in the mounted configuration files:
- The time limit for the node to process a single request (milliseconds): the value of wallarm_process_time_limit or process_time_limit.
  
  Risk of running out of system memory
  
  The high time limit and/or continuation of request processing after the limit is exceeded can trigger memory exhaustion or out-of-time request processing.
- The node will either block or pass the overlimit_res attack depending on the node filtration mode:
  - In the monitoring mode, the node forwards the original request to the application address. The application has the risk to be exploited by the attacks included in both processed and unprocessed request parts.
  - In the safe blocking mode, the node blocks the request if it is originated from the graylisted IP address. Otherwise, the node forwards the original request to the application address. The application has the risk to be exploited by the attacks included in both processed and unprocessed request parts.
  - In the block mode, the node blocks the request.
Delete the wallarm_process_time_limit, wallarm_process_time_limit_block NGINX directives from the mounted configuration file.

If the overlimit_res attack detection is fine-tuned using both the parameters and the rule, the node will process requests as the rule sets.

手順11: 稼働中のコンテナを停止します¶

docker stop <RUNNING_CONTAINER_NAME>

手順12: 更新済みイメージを使用してコンテナを起動します¶

更新済みイメージを使用してコンテナを起動し、イメージの最適化や置き換えによる最近の変更がある場合は、マウントするファイルのパスを必要に応じて調整してください。

更新済みイメージでコンテナを実行する方法は2つあります。

手順13: 最新バージョンでの変更に合わせてWallarmノードのフィルタリングモード設定を調整します（ノード2.18以下をアップグレードする場合のみ）¶

以下の設定について、期待する挙動がoffおよびmonitoringフィルタリングモードの変更されたロジックと一致していることを確認してください。
- NGINXベースのDockerコンテナの環境変数WALLARM_MODEまたはディレクティブwallarm_mode
- Wallarm Consoleで構成した全体フィルタリングルール
- Wallarm Consoleで構成したエンドポイント対象のフィルタリングルール
期待する挙動が変更後のフィルタリングモードのロジックと一致しない場合は、手順に従って設定を変更内容に合わせて調整してください。

手順14: フィルタリングノードの動作をテストします¶

Send the request with the test Path Traversal attack to the application address:
```
curl http://localhost/etc/passwd
```
If traffic is configured to be proxied to example.com, include the -H "Host: example.com" header in the request.
Make sure the node of the new type processes the request in the same way as the regular node did, e.g.:
- Blocks the request if the appropriate filtration mode is configured.
- Returns the custom blocking page if it is configured.
Open Wallarm Console → Attacks in the EU Cloud or US Cloud and make sure that:
- The attack is displayed in the list.
- Hit details display the Wallarm node UUID.

手順15: 以前のバージョンのフィルタリングノードを削除します¶

デプロイした6.xのイメージが正しく動作していることを確認できたら、Wallarm Console→Nodesセクションで以前のバージョンのフィルタリングノードを削除できます。

手順16: Threat Replay Testingモジュールを再度有効化します（ノード2.16以下をアップグレードする場合のみ）¶

Threat Replay Testingモジュールの設定に関する推奨事項を確認し、必要に応じて再度有効化してください。

しばらく運用した後、このモジュールの動作によって誤検知が発生していないことを確認してください。誤検知が発生する場合は、Wallarmテクニカルサポートにお問い合わせください。