Upgrading the cloud node image 2.18 or lower¶
These instructions describe the steps to upgrade the cloud node image 2.18 or lower deployed on AWS or GCP up to 4.2.
Wallarm nodes 2.18 and lower are not supported
You are recommended to upgrade the Wallarm nodes 2.18 and lower since these versions are not supported.
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 2.18 and lower.
https://us1.api.wallarm.comif working with US Wallarm Cloud or to
https://api.wallarm.comif working with EU Wallarm Cloud. Please ensure the access is not blocked by a firewall
Step 1: Inform Wallarm technical support that you are upgrading filtering node modules¶
Please inform Wallarm technical support that you are upgrading filtering node modules up to the latest version and ask to enable new IP list logic for your Wallarm account. When new IP list logic is enabled, please ensure the section IP lists of Wallarm Console is available.
Step 2: Disable the Active threat verification module (if upgrading node 2.16 or lower)¶
If upgrading Wallarm node 2.16 or lower, please disable the Active threat verification module in Wallarm Console → Scanner → Settings.
The module operation can cause false positives during the upgrade process. Disabling the module minimizes this risk.
Step 3: Update API port¶
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
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
443 for API endpoint for each resource.
Step 4: Launch a new instance with the filtering node 4.2¶
Open the Wallarm filtering node image on the cloud platform marketplace and proceed to the image launch:
At the launch step, set the following settings:
Confirm the instance launch.
For GCP, configure the instance following these instructions.
Step 5: Adjust Wallarm node filtration mode settings to changes released in the latest versions¶
Ensure that the expected behavior of settings listed below corresponds to the changed logic of the
If the expected behavior does not correspond to the changed filtration mode logic, please adjust the filtration mode settings to released changes using the instructions.
Step 6: Connect the filtering node to Wallarm Cloud¶
Connect to the filtering node instance via SSH. More detailed instructions for connecting to the instances are available in the cloud platform documentation:
Create a new Wallarm node and connect it to the Wallarm Cloud using the generated token as described in the instructions for the cloud platform:
Step 7: Copy the filtering node settings from the previous version to the new version¶
Copy the settings for processing and proxying requests from the following configuration files of the previous Wallarm node version to the files of the filtering node 4.2:
/etc/nginx/nginx.confand other files with NGINX settings
/etc/nginx/conf.d/wallarm.confwith global filtering node settings
/etc/nginx/conf.d/wallarm-status.confwith the filtering node monitoring service settings
/etc/environmentwith environment variables
/etc/default/wallarm-tarantoolwith Tarantool settings
- other files with custom settings for processing and proxying requests
Rename the following NGINX directives if they are explicitly specified in configuration files:
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.
If the extended logging format is configured, please check if the
wallarm_request_timevariable is explicitly specified in the configuration.
If so, please rename it to
We only changed the variable name, its logic remains the same. The old name is temporarily supported as well, but still it is recommended to rename the variable.
Migrate allowlist and denylist configuration from previous Wallarm node version to 4.2.
If the page
&/usr/share/nginx/html/wallarm_blocked.htmlis returned to blocked requests, copy and customize its new version.
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.
Detailed information about working with NGINX configuration files is available in the official NGINX documentation.
The list of filtering node directives is available here.
Step 8: 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.
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.
overlimit_res attack detection settings are customized via the listed directives, 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 via the NGINX directives:
- The rule condition should match the NGINX configuration block with the
- The time limit for the node to process a single request (milliseconds): the value of
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.
off, choose the Do not create attack event option.
The rule does not have the explicit equivalent option for the
wallarm_process_time_limit_blockdirective. If the rule sets Register and display in the events, the node will either block or pass the
overlimit_resattack 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 configuration block with the
wallarm_process_time_limit_blockNGINX directives from the NGINX configuration file.
overlimit_resattack detection is fine-tuned using both the directives and the rule, the node will process requests as the rule sets.
Step 9: Restart NGINX¶
Restart NGINX to apply the settings:
sudo systemctl restart nginx
Step 10: Test Wallarm node operation¶
Step 11: Create the virtual machine image based on the filtering node 4.2 in AWS or GCP¶
Step 12: Delete the previous Wallarm node instance¶
If the new version of the filtering node is successfully configured and tested, remove the instance and virtual machine image with the previous version of the filtering node using the AWS or GCP management console.
Step 13: Re-enable the Active threat verification module (if upgrading node 2.16 or lower)¶
Learn the recommendation on the Active threat verification module setup and re-enable it if required.
After a while, ensure the module operation does not cause false positives. If discovering false positives, please contact the Wallarm technical support.