Upgrading Wallarm NGINX modules 2.18 or lower¶
These instructions describe the steps to upgrade the Wallarm NGINX modules 2.18 or lower to version 3.6. Wallarm NGINX modules are the modules installed in accordance with one of the following instructions:
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.
Upgrade procedure¶
-
If filtering node and postanalytics modules are installed on the same server, then follow the instructions below to upgrade all packages.
-
If filtering node and postanalytics modules are installed on different servers, first upgrade the postanalytics module following these instructions and then perform the steps below for filtering node modules.
Step 1: Inform Wallarm technical support that you are upgrading filtering node modules¶
Inform Wallarm technical support that you are updating filtering node modules up to 3.6 and ask to enable new IP lists logic for your Wallarm account. When new IP lists logic is enabled, please open Wallarm Console and ensure that the section IP lists 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: Upgrade NGINX to the latest version¶
Upgrade NGINX to the latest version using the relevant instructions:
DEB-based distributions:
RPM-based distributions:
For NGINX Plus, please follow the official upgrade instructions.
For NGINX installed from Debian/CentOS repository, please skip this step. The installed NGINX version will be upgraded later along with the Wallarm modules.
If your infrastructure needs to use a specific version of NGINX, please contact the Wallarm technical support to build the Wallarm module for a custom version of NGINX.
Step 4: Add new Wallarm repository¶
Delete the previous Wallarm repository address and add a repository with a new Wallarm node version package. Please use the commands for the appropriate platform.
CentOS and Amazon Linux 2.0.2021x and lower
Support for CentOS 8.x has been deprecated
Support for CentOS 8.x has been deprecated. You can install the Wallarm node 3.6 on the AlmaLinux, Rocky Linux or Oracle Linux 8.x operating system insted.
Debian and Ubuntu
-
Open the file with the Wallarm repository address in the installed text editor. In these instructions, vim is used.
-
Comment out or delete the previous repository address.
-
Add a new repository address:
Step 5: Migrate allowlists and denylists from the previous Wallarm node version to 3.6¶
Migrate allowlist and denylist configuration from previous Wallarm node version to 3.6.
Step 6: Upgrade Wallarm packages¶
Filtering node and postanalytics on the same server¶
-
Execute the following command to upgrade the filtering node and postanalytics modules:
The error "signatures couldn't be verified"
If added GPG keys expired, the following error would be returned:
W: GPG error: https://repo.wallarm.com/ubuntu/wallarm-node focal/3.6/ Release:The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 1111FQQW999 E: The repository 'https://repo.wallarm.com/ubuntu/wallarm-node focal/3.6/ Release' is not signed. N: Updating from such a repository can't be done securely, and is therefore disabled by default. N: See apt-secure(8) manpage for repository creation and user configuration details.
To fix the problem, please import new GPG keys for the Wallarm packages and then upgrade the packages using the following commands:
The error "signatures couldn't be verified"
If added GPG keys expired, the following error would be returned:
W: GPG error: https://repo.wallarm.com/ubuntu/wallarm-node focal/3.6/ Release:The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 1111FQQW999 E: The repository 'https://repo.wallarm.com/ubuntu/wallarm-node focal/3.6/ Release' is not signed. N: Updating from such a repository can't be done securely, and is therefore disabled by default. N: See apt-secure(8) manpage for repository creation and user configuration details.
To fix the problem, please import new GPG keys for the Wallarm packages and then upgrade the packages using the following commands:
-
If the package manager asks for confirmation to rewrite the content of the configuration file
/etc/cron.d/wallarm-node-nginx
:- Ensure that the IP lists migration is completed.
-
Confirm the file rewrite by using the option
Y
.The package manager would ask for the rewrite confirmation if the file
/etc/cron.d/wallarm-node-nginx
had been changed in the previous Wallarm node versions. Since IP list logic was changed in Wallarm node 3.x, the/etc/cron.d/wallarm-node-nginx
content was updated accordingly. For the IP address denylist to operate correctly, the Wallarm node 3.x should use the updated configuration file.By default, the package manager uses the option
N
but the optionY
is required for the correct IP address denylist operation in Wallarm node 3.x.
Filtering node and postanalytics on different servers¶
Sequence of steps to upgrade the filtering node and postanalytics modules
If the filtering node and postanalytics modules are installed on different servers, then it is required to upgrade the postanalytics packages before updating the filtering node packages.
-
Upgrade postanalytics packages following these instructions.
-
Upgrade Wallarm node packages:
The error "signatures couldn't be verified"
If added GPG keys expired, the following error would be returned:
W: GPG error: https://repo.wallarm.com/ubuntu/wallarm-node focal/3.6/ Release:The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 1111FQQW999 E: The repository 'https://repo.wallarm.com/ubuntu/wallarm-node focal/3.6/ Release' is not signed. N: Updating from such a repository can't be done securely, and is therefore disabled by default. N: See apt-secure(8) manpage for repository creation and user configuration details.
To fix the problem, please import new GPG keys for the Wallarm packages and then upgrade the packages using the following commands:
The error "signatures couldn't be verified"
If added GPG keys expired, the following error would be returned:
W: GPG error: https://repo.wallarm.com/ubuntu/wallarm-node focal/3.6/ Release:The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 1111FQQW999 E: The repository 'https://repo.wallarm.com/ubuntu/wallarm-node focal/3.6/ Release' is not signed. N: Updating from such a repository can't be done securely, and is therefore disabled by default. N: See apt-secure(8) manpage for repository creation and user configuration details.
To fix the problem, please import new GPG keys for the Wallarm packages and then upgrade the packages using the following commands:
-
If the package manager asks for confirmation to rewrite the content of the configuration file
/etc/cron.d/wallarm-node-nginx
:- Ensure that the IP lists migration is completed.
-
Confirm the file rewrite by using the option
Y
.The package manager would ask for the rewrite confirmation if the file
/etc/cron.d/wallarm-node-nginx
had been changed in the previous Wallarm node versions. Since IP list logic was changed in Wallarm node 3.x, the/etc/cron.d/wallarm-node-nginx
content was updated accordingly. For the IP address denylist to operate correctly, the Wallarm node 3.x should use the updated configuration file.By default, the package manager uses the option
N
but the optionY
is required for the correct IP address denylist operation in Wallarm node 3.x.
Step 7: Update the Wallarm blocking page¶
In 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 the page &/usr/share/nginx/html/wallarm_blocked.html
was configured to be returned in response to blocked requests, copy and customize the new version of a sample page.
Step 8: Rename deprecated NGINX directives¶
Rename the following NGINX directives if they are explicitly specified in configuration files:
-
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.
Step 9: 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
off
andmonitoring
filtration modes: -
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 10: 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 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:
-
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
wallarm_process_time_limit
andwallarm_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
. -
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
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 configuration block with the
-
Delete the
wallarm_process_time_limit
andwallarm_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.
Step 11: Update the wallarm-status.conf
file contents¶
Update the /etc/nginx/conf.d/wallarm-status.conf
contents as follows:
server {
listen 127.0.0.8:80;
server_name localhost;
allow 127.0.0.0/8; # Access is only available for loopback addresses of the filter node server
deny all;
wallarm_mode off;
disable_acl "on"; # Checking request sources is disabled, denylisted IPs are allowed to request the wallarm-status service. https://docs.wallarm.com/admin-en/configure-parameters-en/#disable_acl
access_log off;
location ~/wallarm-status$ {
wallarm_status on;
}
}
More details on the statistics service configuration
Step 12: Restart NGINX¶
Step 13: Test Wallarm 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 14: 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.
Settings customization¶
The Wallarm modules are updated to version 3.6. Previous filtering node settings will be applied to the new version automatically. To make additional settings, use the available directives.
Common customization options:
-
Using the balancer of the proxy server behind the filtering node
-
Limiting the single request processing time in the directive
wallarm_process_time_limit
-
Limiting the server reply waiting time in the NGINX directive
proxy_read_timeout
-
Limiting the maximum request size in the NGINX directive
client_max_body_size