サポート終了(EOL)クラウドノードイメージのアップグレード¶

本書では、AWSまたはGCPにデプロイされたサポート終了のクラウドノードイメージ(バージョン3.6以下)を6.xにアップグレードする手順を説明します。

要件¶

• 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以下をアップグレードする場合は、フィルタリングノードモジュールを最新バージョンにアップグレードする旨を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: 直近のアーキテクチャ更新を確認する¶

最新のアップデートでは、特にノードのデフォルト設定ファイルを変更しているユーザーに影響する可能性のあるアーキテクチャの変更が導入されています。新しいイメージを正しく構成・利用できるよう、これらの変更点を必ず把握してください。

手順5: フィルタリングノード6.xの新規インスタンスを起動する¶

以前のWallarmノードバージョンの次の設定ファイルから、要求の処理とプロキシの設定をフィルタリングノード6.xのファイルにコピーしてください:

1. クラウドプラットフォームのマーケットプレイスでWallarmフィルタリングノードのイメージを開き、イメージの起動に進みます:

   • Amazon Marketplace
   • GCP Marketplace

2. 起動時の手順で、以下を設定します:

   • イメージバージョン6.xを選択します
   • AWSの場合、Security Group Settingsフィールドで作成済みのセキュリティグループを選択します
   • AWSの場合、Key Pair Settingsフィールドで作成済みのキーペアの名前を選択します

3. インスタンスの起動を確定します。

4. GCPの場合、これらの手順に従ってインスタンスを構成します。

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

1. 以下の設定の想定どおりの動作が、offおよびmonitoringフィルタリングモードの変更されたロジックに合致していることを確認してください:

   • ディレクティブwallarm_mode
   • Wallarm Consoleで構成された全体フィルタリングルール
   • Wallarm Consoleで構成されたエンドポイント対象のフィルタリングルール

2. 想定動作が変更後のフィルタリングモードロジックに合致していない場合は、手順に従って設定を最新の変更内容に合わせて調整してください。

手順7: フィルタリングノードをWallarm Cloudに接続する¶

1. SSHでフィルタリングノードのインスタンスに接続します。インスタンスへの接続に関する詳細な手順は各クラウドプラットフォームのドキュメントをご参照ください:

   • AWSのドキュメント
   • GCPのドキュメント

2. クラウドプラットフォーム別の手順に従い、生成したトークンを使用して新しいWallarmノードを作成し、Wallarm Cloudに接続します:

   • AWS
   • GCP

手順8: 以前のバージョンから新バージョンへフィルタリングノードの設定をコピーする¶

1. 以前のWallarmノードバージョンの次の設定ファイルから、要求の処理とプロキシの設定をフィルタリングノード6.xのファイルにコピーします:

   • /etc/nginx/nginx.confおよびその他のNGINX設定ファイル

   • フィルタリングノードの監視サービス設定を含む/etc/nginx/conf.d/wallarm-status.conf

     コピーしたファイル内容が推奨される安全な構成に準拠していることを確認してください。

   • 環境変数を含む/etc/environment

   • 最近のアーキテクチャの変更を踏まえ、/etc/nginx/sites-available/defaultなど、要求の処理やプロキシに関するその他のカスタム設定ファイル

2. 設定ファイルで明示的に指定している場合、以下の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

   ディレクティブは名前のみ変更され、ロジックは同一です。旧名称のディレクティブはまもなく非推奨となるため、事前にリネームすることを推奨します。

3. 拡張ログ形式を設定している場合、設定内でwallarm_request_time変数を明示的に指定していないか確認してください。

   指定している場合は、wallarm_request_cpu_timeにリネームしてください。

   変数は名称のみ変更され、ロジックは同一です。旧名称も一時的にサポートされていますが、リネームを推奨します。

4. ノード2.18以下をアップグレードする場合、以前のWallarmノードバージョンの許可リストと拒否リストの設定を6.xに移行してください。

5. ブロックされたリクエストに対してページ&/usr/share/nginx/html/wallarm_blocked.htmlを返している場合は、その新しいバージョンをコピーしてカスタマイズしてください。

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

NGINX設定ファイルの取り扱いに関する詳細は、公式NGINXドキュメントをご参照ください。

フィルタリングノードのディレクティブ一覧はこちらです。

手順8: 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 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 directives, it is recommended to transfer them to the rule as follows:

1. Open Wallarm Console → Rules and proceed to the Limit request processing time rule setup.

2. Configure the rule as done via the NGINX directives:

   • The rule condition should match the NGINX configuration block with the wallarm_process_time_limit and wallarm_process_time_limit_block directives specified.

   • The time limit for the node to process a single request (milliseconds): the value of wallarm_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.

3. Delete the wallarm_process_time_limit and wallarm_process_time_limit_block NGINX directives from the NGINX configuration file.

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

手順9: NGINXを再起動する¶

設定を適用するため、NGINXを再起動します:

sudo systemctl restart nginx

手順10: Wallarmノードの動作をテストする¶

1. Send the request with test Path Traversal attack to a protected resource 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.

2. Open Wallarm Console → Attacks section in the US Cloud or EU Cloud and make sure the attack is displayed in the list.

   

3. Optionally, test other aspects of the node functioning.

手順11: AWSまたはGCPでフィルタリングノード6.xをベースに仮想マシンイメージを作成する¶

フィルタリングノード6.xをベースに仮想マシンイメージを作成するには、AWSまたはGCPの手順に従ってください。

手順12: 前のWallarmノードインスタンスを削除する¶

新バージョンのフィルタリングノードが正常に構成・テストできたら、AWSまたはGCPの管理コンソールを使用して、旧バージョンのフィルタリングノードのインスタンスと仮想マシンイメージを削除してください。

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

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

しばらく運用した後、当該モジュールの動作が誤検知を引き起こしていないことを確認してください。誤検知が発生する場合は、Wallarmテクニカルサポートにご連絡ください。

Was this page helpful?

How can we improve this article? (Optional)

Information is unclear or confusing

Insufficient information

Outdated or incorrect information

0/240

Send