Upgrading the Docker NGINX- or Envoy-based image¶
These instructions describe the steps to upgrade the running Docker NGINX- or Envoy-based image 3.4 or 3.2 to the version 3.6.
Using credentials of already existing Wallarm node
We do not recommend using the already existing Wallarm node of the previous version. Please follow these instructions to create a new filtering node of the version 3.6 and deploy it as the Docker container.
To upgrade the node 2.18 or lower, please use the different instructions.
Requirements¶
-
Access to the account with the Deploy or Administrator role and two‑factor authentication disabled in Wallarm Console in the US Cloud or EU Cloud
-
Access to
https://us1.api.wallarm.com:444
if working with US Wallarm Cloud or tohttps://api.wallarm.com:444
if working with EU Wallarm Cloud. Please ensure the access is not blocked by a firewall
Step 1: Download the updated filtering node image¶
Step 2: Stop the running container¶
Step 3: Switch from deprecated configuration options¶
There are the following deprecated configuration options:
-
The following NGINX directives have been renamed:
wallarm_instance
→wallarm_application
wallarm_local_trainingset_path
→wallarm_custom_ruleset_path
wallarm_global_trainingset_path
→wallarm_protondb_path
We only changed the names of the directives, their logic remains the same. Directives with former names will be deprecated soon, so you are recommended to rename them before.
Please check if the directives with former names are explicitly specified in the mounted configuration files. If so, rename them.
-
The following Envoy parameters have been renamed:
lom
→custom_ruleset
instance
→application
We only changed the names of the directives, their logic remains the same. Directives with former names will be deprecated soon, so you are recommended to rename them before.
Please check if the directives with former names are explicitly specified in the mounted configuration files. If so, rename them.
Step 4: Update the Wallarm blocking page (if upgrading NGINX-based image)¶
In the new node version, the Wallarm sample blocking page has been changed. The logo and support email on the page are now empty by default.
If your Docker container was configured to return the &/usr/share/nginx/html/wallarm_blocked.html
page in response to the blocked requests, transfer this configuration as follows:
-
Copy and customize the new version of a sample page.
-
Mount the new customized or previously used page and the NGINX configuration file to a new Docker container in the next step.
Step 5: Transfer the overlimit_res
attack detection configuration from directives to the rule¶
Starting from the version 3.6, you can fine-tune the overlimit_res
attack detection using the rule in Wallarm Console.
Earlier, the following options have been used:
-
The
wallarm_process_time_limit
andwallarm_process_time_limit_block
NGINX directives -
The
process_time_limit
andprocess_time_limit_block
Envoy parameters
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 Fine-tune the overlimit_res attack detection rule setup.
-
Configure the rule as done in the mounted configuration files:
- The rule condition should match the NGINX or Envoy configuration block with the
wallarm_process_time_limit
andwallarm_process_time_limit_block
directives or theprocess_time_limit
andprocess_time_limit_block
parameters specified. - The time limit for the node to process a single request (milliseconds): the value of
wallarm_process_time_limit
orprocess_time_limit
. -
Request processing: the Stop processing option is recommended.
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.
-
Register the overlimit_res attack: the Register and display in the events option is recommended.
If the
wallarm_process_time_limit_block
orprocess_time_limit_block
value isoff
, choose the Do not create attack event option. -
The rule does not have the explicit equivalent option for the
wallarm_process_time_limit_block
(process_time_limit_block
in Envoy) directive. If the rule sets Register and display in the events, the node will either block or pass theoverlimit_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.
- The rule condition should match the NGINX or Envoy configuration block with the
-
Delete the
wallarm_process_time_limit
,wallarm_process_time_limit_block
NGINX directives and theprocess_time_limit
,process_time_limit_block
Envoy parameters 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.
Step 6: Run the container using the updated image¶
Run the container using the updated image. You can pass the same configuration parameters that were passed when running a previous image version except for the ones listed in the previous steps.
There are two options for running the container using the updated image:
-
With the environment variables specifying basic filtering node configuration
-
In the mounted configuration file specifying advanced filtering node configuration
Step 7: Test the filtering node operation¶
-
Send the request with test SQLI and XSS attacks to the protected resource address:
-
Open the Wallarm Console → Attacks section in the US Cloud or EU Cloud and ensure attacks are displayed in the list.
Step 8: Delete the filtering node of the previous version¶
If the deployed image of the version 3.6 operates correctly, you can delete the filtering node of the previous version in the Wallarm Console → Nodes section.