Skip to content

Upgrading EOL Wallarm NGINX modules

These instructions describe the steps to upgrade the end‑of‑life Wallarm NGINX modules (version 3.6 and lower) to version 4.10. 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.

Inform Wallarm technical support that you are upgrading EOL node

If upgrading the end‑of‑life Wallarm NGINX modules (version 3.6 and lower) to version 4.10, inform Wallarm technical support about that and ask for assistance.

Besides any other help, 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.

Upgrade methods

You can upgrade in two different ways:

  • Migrate to the all-in-one installer usage during the upgrade procedure. This is the recommended approach as it automates various node installation and upgrade activities, such as NGINX and OS version identification, adding appropriate Wallarm repositories, installing packages, and others.

  • Keep using the current manual installation method via individual DEB/RPM packages. However, it's important to note that in further upgrades this approach will require additional effort and manual configuration in comparison to the new method.

Upgrade with all-in-one installer

Use the procedure below to upgrade the end‑of‑life Wallarm NGINX modules (version 3.6 and lower) to version 4.10 using all-in-one installer.

Requirements for upgrade using all-in-one installer

  • Access to the account with the Administrator role in Wallarm Console for the US Cloud or EU Cloud.

  • Access to https://meganode.wallarm.com to download all-in-one Wallarm installer. Ensure the access is not blocked by a firewall.

  • Access to https://us1.api.wallarm.com for working with US Wallarm Cloud or to https://api.wallarm.com for working with EU Wallarm Cloud. If access can be configured only via the proxy server, then use the instructions.

  • Executing all commands as a superuser (e.g. root).

Upgrade procedure

  • If filtering node and postanalytics modules are installed on the same server, then follow the instructions below to upgrade all.

    You will need to run a node of the newer version using all-in-one installer on a clean machine, test that it works well and stop the previous one and configure traffic to flow through the new machine instead of the previous one.

  • If filtering node and postanalytics modules are installed on different servers, first upgrade the postanalytics module and then the filtering module following these instructions.

Step 1: 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 → Vulnerabilities → Configure.

The module operation can cause false positives during the upgrade process. Disabling the module minimizes this risk.

Step 2: Prepare clean machine

When upgrading modules 4.x with all-in-one installer, you cannot upgrade an old package installation - instead you need to use a clean machine. Thus, as step 1, prepare a machine with one of the supported OS:

  • Debian 10, 11 and 12.x

  • Ubuntu LTS 18.04, 20.04, 22.04

  • CentOS 7, 8 Stream, 9 Stream

  • Alma/Rocky Linux 9

  • RHEL 8.x

  • Oracle Linux 8.x

  • Redos

  • SuSe Linux

  • Others (the list is constantly widening, contact Wallarm support team to check if your OS is in the list)

Using new clean machine will lead to that at some moment you will have both old and new node, which is good: you can test the new one working properly without stopping the old one.

Step 3: Install NGINX and dependencies

Install the latest NGINX version of:

  • NGINX stable - see how to install it in the NGINX documentation.

  • NGINX Mainline - see how to install it in the NGINX documentation.

  • NGINX Plus - see how to install it in the NGINX documentation.

  • Distribution-Provided NGINX - to install, use the following commands:

    sudo apt-get update 
    sudo apt -y install --no-install-recommends nginx
    
    sudo apt update 
    sudo apt -y install --no-install-recommends nginx
    
    sudo yum -y update 
    sudo yum install -y nginx
    
    sudo yum -y update 
    sudo yum install -y nginx
    
    sudo yum -y update 
    sudo yum install -y nginx
    

Step 4: Prepare Wallarm token

To install node, you will need a Wallarm token of the appropriate type. To prepare a token:

  1. Open Wallarm Console → SettingsAPI tokens in the US Cloud or EU Cloud.
  2. Find or create API token with the Deploy source role.
  3. Copy this token.
  1. Open Wallarm Console → Nodes in the US Cloud or EU Cloud.
  2. Do one of the following:
    • Create the node of the Wallarm node type and copy the generated token.
    • Use existing node group - copy token using node's menu → Copy token.

Step 5: Download all-in-one Wallarm installer

Wallarm suggests all-in-one installations for the following processors:

  • x86_64

  • ARM64 (beta)

To download all-in-one Wallarm installation script, execute the command:

curl -O https://meganode.wallarm.com/4.10/wallarm-4.10.1.x86_64-glibc.sh
curl -O https://meganode.wallarm.com/4.10/wallarm-4.10.1.aarch64-glibc.sh

Step 6: Run all-in-one Wallarm installer

Filtering node and postanalytics on the same server

  1. Run downloaded script:

    # If using the x86_64 version:
    sudo env WALLARM_LABELS='group=<GROUP>' sh wallarm-4.10.1.x86_64-glibc.sh
    
    # If using the ARM64 version:
    sudo env WALLARM_LABELS='group=<GROUP>' sh wallarm-4.10.1.aarch64-glibc.sh
    

    The WALLARM_LABELS variable sets group into which the node will be added (used for logical grouping of nodes in the Wallarm Console UI).

    # If using the x86_64 version:
    sudo sh wallarm-4.10.1.x86_64-glibc.sh
    
    # If using the ARM64 version:
    sudo sh wallarm-4.10.1.aarch64-glibc.sh
    
  2. Select US Cloud or EU Cloud.

  3. Enter Wallarm token.

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.

  1. Upgrade postanalytics module following these instructions.

  2. Upgrade filtering node:

    # If using the x86_64 version:
    sudo env WALLARM_LABELS='group=<GROUP>' sh wallarm-4.10.1.x86_64-glibc.sh filtering
    
    # If using the ARM64 version:
    sudo env WALLARM_LABELS='group=<GROUP>' sh wallarm-4.10.1.aarch64-glibc.sh filtering
    

    The WALLARM_LABELS variable sets group into which the node will be added (used for logical grouping of nodes in the Wallarm Console UI).

    # If using the x86_64 version:
    sudo sh wallarm-4.10.1.x86_64-glibc.sh filtering
    
    # If using the ARM64 version:
    sudo sh wallarm-4.10.1.aarch64-glibc.sh filtering
    

Step 7: Migrate allowlists and denylists from the previous Wallarm node version to 4.10 (only if upgrading node 2.18 or lower)

If upgrading node 2.18 or lower, migrate allowlist and denylist configuration from previous Wallarm node version to the latest version.

Step 8: Transfer NGINX and postanalytics configuration from old node machine to new

Transfer node-related NGINX configuration and postanalytics configuration from the configuration files on the old machine to the files on a new machine. You can do that by copying the required directives.

Source files

On an old machine, depending on OS and NGINX version, the NGINX configuration files may be located in different directories and have different names. Most common are the following:

  • /etc/nginx/conf.d/default.conf with NGINX settings

  • /etc/nginx/conf.d/wallarm-status.conf with Wallarm node monitoring settings. Detailed description is available within the link

Also, the configuration of the postanalytics module (Tarantool database settings) is usually located here:

  • /etc/default/wallarm-tarantool or

  • /etc/sysconfig/wallarm-tarantool

Target files

As all-in-one installer works with different combinations of OS and NGINX versions, on your new machine, the target files may have different names and be located in different directories.

When transferring configuration, you need to perform steps listed below.

Rename deprecated NGINX directives

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.

Update the node logging variables

In the new node version the following changes to the node logging variables have been implemented:

  • The wallarm_request_time variable has been renamed to wallarm_request_cpu_time.

    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.

  • The wallarm_request_mono_time variable has been added – place it in the configuration of the logging format if you need log information about total time being the sum of:

    • Time in the queue
    • Time in seconds the CPU spent processing the request

Adjust Wallarm node filtration mode settings to changes released in the latest versions

  1. Ensure that the expected behavior of settings listed below corresponds to the changed logic of the off and monitoring filtration modes:

  2. 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.

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:

  1. Open Wallarm Console → Rules and proceed to the Fine-tune the overlimit_res attack detection 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.
    • 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 or process_time_limit_block value is off, 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 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.

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

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 9: 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 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.

Step 10: Re-enable the Active threat verification module (only 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.

Step 11: Restart NGINX

Restart NGINX using the following command:

sudo systemctl restart nginx

Step 12: Test Wallarm node operation

To test the new node operation:

  1. Send the request with test SQLI and XSS attacks to the protected resource address:

    curl http://localhost/?id='or+1=1--a-<script>prompt(1)</script>'
    
  2. Open the Wallarm Console → Attacks section in the US Cloud or EU Cloud and ensure attacks are displayed in the list.

  3. As soon as your Cloud stored data (rules, IP lists) is synchronized to the new node, perform some test attacks to make sure your rules work as expected.

Step 13: Configure sending traffic to Wallarm node

Depending on the deployment approach being used, perform the following settings:

Update targets of your load balancer to send traffic to the Wallarm instance. For details, please refer to the documentation on your load balancer.

Before full redirecting of the traffic to the new node, it is recommended to first redirect it partially and check that the new node behaves as expected.

Configure your web or proxy server (e.g. NGINX, Envoy) to mirror incoming traffic to the Wallarm node. For configuration details, we recommend to refer to your web or proxy server documentation.

Inside the link, you will find the example configuration for the most popular of web and proxy servers (NGINX, Traefik, Envoy).

Step 14: Remove old node

  1. Delete old node in Wallarm Console → Nodes by selecting your node and clicking Delete.

  2. Confirm the action.

    When the node is deleted from Cloud, it will stop filtration of requests to your applications. Deleting the filtering node cannot be undone. The node will be deleted from the list of nodes permanently.

  3. Delete machine with the old node or just clean it from Wallarm node components:

    sudo apt remove wallarm-node nginx-module-wallarm
    
    sudo apt remove wallarm-node nginx-module-wallarm
    
    sudo yum remove wallarm-node nginx-module-wallarm
    
    sudo yum remove wallarm-node nginx-module-wallarm
    
    sudo yum remove wallarm-node nginx-module-wallarm
    

Manual upgrade

Requirements for manual upgrade

  • 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

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: 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 → Vulnerabilities → Configure.

The module operation can cause false positives during the upgrade process. Disabling the module minimizes this risk.

Step 2: 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 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.

Step 3: Upgrade NGINX to the latest version

Upgrade NGINX to the latest version using the relevant instructions:

DEB-based distributions:

sudo apt update
sudo apt -y install nginx

RPM-based distributions:

sudo yum update
sudo yum install -y nginx

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

sudo yum remove wallarm-node-repo
sudo yum clean all
sudo rpm -i https://repo.wallarm.com/centos/wallarm-node/7/4.8/x86_64/wallarm-node-repo-4.8-0.el7.noarch.rpm

Support for CentOS 8.x has been deprecated

Support for CentOS 8.x has been deprecated. You can install the Wallarm node on the AlmaLinux, Rocky Linux, Oracle Linux 8.x, or RHEL 8.x operating system instead.

sudo yum remove wallarm-node-repo
sudo yum clean all
sudo rpm -i https://repo.wallarm.com/centos/wallarm-node/8/4.8/x86_64/wallarm-node-repo-4.8-0.el8.noarch.rpm
sudo yum remove wallarm-node-repo
sudo yum clean all
sudo rpm -i https://repo.wallarm.com/centos/wallarm-node/8/4.8/x86_64/wallarm-node-repo-4.8-0.el8.noarch.rpm

Debian and Ubuntu

  1. Open the file with the Wallarm repository address in the installed text editor. In these instructions, vim is used.

    sudo vim /etc/apt/sources.list.d/wallarm.list
    
  2. Comment out or delete the previous repository address.

  3. Add a new repository address:

    Unsupported by NGINX stable and NGINX Plus

    Official NGINX versions (stable and Plus) and, as a result, Wallarm node 4.4 and above cannot be installed on Debian 10.x (buster). Please use this OS only if NGINX is installed from Debian/CentOS repositories.

    deb https://repo.wallarm.com/debian/wallarm-node buster/4.8/
    
    deb https://repo.wallarm.com/debian/wallarm-node bullseye/4.8/
    
    deb https://repo.wallarm.com/ubuntu/wallarm-node bionic/4.8/
    
    deb https://repo.wallarm.com/ubuntu/wallarm-node focal/4.8/
    

Step 5: Migrate allowlists and denylists from the previous Wallarm node version to 4.8 (only if upgrading node 2.18 or lower)

If upgrading node 2.18 or lower, migrate allowlist and denylist configuration from previous Wallarm node version to the latest version.

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:

sudo apt update
sudo apt dist-upgrade

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/4.8/ 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/4.8/ 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:

curl -fsSL https://repo.wallarm.com/wallarm.gpg | sudo apt-key add -
sudo apt update
sudo apt dist-upgrade

Upgrading Wallarm dependencies

The sudo apt dist-upgrade command upgrades both the Wallarm packages and filtering node dependencies. It is the recommended upgrade option providing correct operation of the newer filtering node version.

sudo apt update
sudo apt dist-upgrade

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/4.8/ 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/4.8/ 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:

curl -fsSL https://repo.wallarm.com/wallarm.gpg | sudo apt-key add -
sudo apt update
sudo apt dist-upgrade

Upgrading Wallarm dependencies

The sudo apt dist-upgrade command upgrades both the Wallarm packages and filtering node dependencies. It is the recommended upgrade option providing correct operation of the newer filtering node version.

sudo yum update
sudo yum update
sudo yum update

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.

  1. Upgrade postanalytics packages following these instructions.

  2. Upgrade Wallarm node packages:

    sudo apt update
    sudo apt dist-upgrade
    

    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/4.8/ 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/4.8/ 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:

    curl -fsSL https://repo.wallarm.com/wallarm.gpg | sudo apt-key add -
    sudo apt update
    sudo apt dist-upgrade
    

    Upgrading Wallarm dependencies

    The sudo apt dist-upgrade command upgrades both the Wallarm packages and filtering node dependencies. It is the recommended upgrade option providing correct operation of the newer filtering node version.

    sudo apt update
    sudo apt dist-upgrade
    

    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/4.8/ 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/4.8/ 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:

    curl -fsSL https://repo.wallarm.com/wallarm.gpg | sudo apt-key add -
    sudo apt update
    sudo apt dist-upgrade
    

    Upgrading Wallarm dependencies

    The sudo apt dist-upgrade command upgrades both the Wallarm packages and filtering node dependencies. It is the recommended upgrade option providing correct operation of the newer filtering node version.

    sudo yum update
    
    sudo yum update
    
    sudo yum update
    
  3. If the package manager asks for confirmation to rewrite the content of the configuration file /etc/cron.d/wallarm-node-nginx:

    1. Ensure that the IP lists migration is completed.
    2. 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 option Y is required for the correct IP address denylist operation in Wallarm node 3.x.

Step 7: Update the node type

The deployed node has the deprecated regular type that is now replaced with the new Wallarm node type.

It is recommended to install the new node type instead of the deprecated one during migration to the version 4.8. The regular node type will be removed in future releases, please migrate before.

If the postanalytics module is installed on a separate server

If the initial traffic processing and postanalytics modules are installed on separate servers, it is recommended to connect these modules to the Wallarm Cloud using the same node token. The Wallarm Console UI will display each module as a separate node instance, e.g.:

Node with several instances

The Wallarm node has already been created during the separate postanalytics module upgrade. To connect the initial traffic processing module to the Cloud using the same node credentials:

  1. Copy the node token generated during the separate postanalytics module upgrade.
  2. Proceed to the 4th step in the list below.

To replace the regular node with the Wallarm node:

  1. Open Wallarm Console → Nodes in the US Cloud or EU Cloud and create the node of the Wallarm node type.

    Wallarm node creation

  2. Copy the generated token.

  3. Pause the NGINX service on the server with the node of the older version:

    sudo systemctl stop nginx
    
    sudo service nginx stop
    
    sudo systemctl stop nginx
    
    sudo systemctl stop nginx
    
    sudo systemctl stop nginx
    

    The NGINX service pausing mitigates the risk of incorrect RPS calculation.

  4. Execute the register-node script to run the Wallarm node:

    sudo /usr/share/wallarm-common/register-node -t <TOKEN> -H us1.api.wallarm.com --force
    
    sudo /usr/share/wallarm-common/register-node -t <TOKEN> --force
    
    • <TOKEN> is the copied value of the node token or API token with the Deploy role.
    • The --force option forces rewriting of the Wallarm Cloud access credentials specified in the /etc/wallarm/node.yaml file.

Step 8: 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 9: Rename deprecated NGINX directives

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.

Step 10: Update the node logging variables

In the new node version the following changes to the node logging variables have been implemented:

  • The wallarm_request_time variable has been renamed to wallarm_request_cpu_time.

    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.

  • The wallarm_request_mono_time variable has been added – place it in the configuration of the logging format if you need log information about total time being the sum of:

    • Time in the queue
    • Time in seconds the CPU spent processing the request

Step 11: Adjust Wallarm node filtration mode settings to changes released in the latest versions

  1. Ensure that the expected behavior of settings listed below corresponds to the changed logic of the off and monitoring filtration modes:

  2. 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 12: 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:

  1. Open Wallarm Console → Rules and proceed to the Fine-tune the overlimit_res attack detection 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.
    • 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 or process_time_limit_block value is off, 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 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.

Step 13: 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 14: Restart NGINX

sudo systemctl restart nginx
sudo service nginx restart
sudo systemctl restart nginx
sudo systemctl restart nginx
sudo systemctl restart nginx

Step 15: Test Wallarm node operation

  1. Send the request with the test Path Traversal attack to the application address:

    curl http://localhost/etc/passwd
    
  2. Make sure the node of the new type processes the request in the same way as the regular node did, e.g.:

  3. 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.

    Attacks in the interface

Step 16: Re-enable the Active threat verification module (only 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.

Step 17: Delete the node of the previous version

Once the operation of the new node is properly tested, open the Nodes section of Wallarm Console and delete the regular node of the previous version from the list.

If the postanalytics module is installed on a separate server, please also delete the node instance related to this module.

Settings customization

The Wallarm modules are updated to version 4.8. Previous filtering node settings will be applied to the new version automatically. To make additional settings, use the available directives.

Common customization options: