Skip to content

Upgrading Wallarm NGINX modules

These instructions describe the steps to upgrade the Wallarm NGINX modules 3.x to version 4.0. Wallarm NGINX modules are the modules installed in accordance with one of the following instructions:

To upgrade the node 2.18 or lower, please use the different instructions.

Requirements

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

  • Access to https://api.wallarm.com if working with EU Wallarm Cloud or to https://us1.api.wallarm.com if working with US 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: Update API port

Starting with version 4.0, the filtering node uploads data to the Cloud using the api.wallarm.com:443 (EU Cloud) and us1.api.wallarm.com:443 (US Cloud) API endpoints instead of api.wallarm.com:444 and us1.api.wallarm.com:444.

If 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 to version 4.0 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 2: Upgrade NGINX to the latest version

Upgrade NGINX to the latest version using the relevant instructions:

DEB-based distributions:

sudo apt update
sudo apt install nginx

RPM-based distributions:

sudo yum update
sudo yum install 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 Wallarm modules.

If your infrastructure needs to use a specific version of NGINX, please contact the Wallarm technical support to build the API Security module for a custom version of NGINX.

Step 3: 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/6/4.0/x86_64/wallarm-node-repo-4-0.el6.noarch.rpm

sudo yum remove wallarm-node-repo
sudo yum clean all
sudo rpm -i https://repo.wallarm.com/centos/wallarm-node/7/4.0/x86_64/wallarm-node-repo-4-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 or Oracle Linux 8.x operating system insted.

sudo yum remove wallarm-node-repo
sudo yum clean all
sudo rpm -i https://repo.wallarm.com/centos/wallarm-node/8/4.0/x86_64/wallarm-node-repo-4-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:

    deb http://repo.wallarm.com/debian/wallarm-node stretch/4.0/

    deb http://repo.wallarm.com/debian/wallarm-node stretch/4.0/
deb http://repo.wallarm.com/debian/wallarm-node stretch-backports/4.0/

    deb http://repo.wallarm.com/debian/wallarm-node buster/4.0/

    deb http://repo.wallarm.com/debian/wallarm-node bullseye/4.0/

    deb http://repo.wallarm.com/ubuntu/wallarm-node bionic/4.0/

    deb http://repo.wallarm.com/ubuntu/wallarm-node focal/4.0/

Step 4: Upgrade Wallarm API Security 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: http://repo.wallarm.com/ubuntu/wallarm-node focal/4.0/ Release:The following
signatures couldn't be verified because the public key is not available: NO_PUBKEY 1111FQQW999
E: The repository 'http://repo.wallarm.com/ubuntu/wallarm-node focal/4.0/ 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

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: http://repo.wallarm.com/ubuntu/wallarm-node focal/4.0/ Release:The following
signatures couldn't be verified because the public key is not available: NO_PUBKEY 1111FQQW999
E: The repository 'http://repo.wallarm.com/ubuntu/wallarm-node focal/4.0/ 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

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: http://repo.wallarm.com/ubuntu/wallarm-node focal/4.0/ Release:The following
signatures couldn't be verified because the public key is not available: NO_PUBKEY 1111FQQW999
E: The repository 'http://repo.wallarm.com/ubuntu/wallarm-node focal/4.0/ 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

    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: http://repo.wallarm.com/ubuntu/wallarm-node focal/4.0/ Release:The following
signatures couldn't be verified because the public key is not available: NO_PUBKEY 1111FQQW999
E: The repository 'http://repo.wallarm.com/ubuntu/wallarm-node focal/4.0/ 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

    sudo yum update

    sudo yum update

Step 5: Update the node type

The deployed node 3.6 or lower 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.0. 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. Make sure that your Wallarm account has the Administrator role enabled in Wallarm Console.

    You can check mentioned settings by navigating to the user list in the EU Cloud or US Cloud.

    User list in Wallarm console

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

    Wallarm node creation

  3. Copy the generated token.

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

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

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

    sudo /usr/share/wallarm-common/register-node -t <NODE_TOKEN> --force

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

Step 6: Update the Wallarm blocking page

In node 3.6, the Wallarm sample blocking page has been changed. The logo and support email on the page are now empty by default.

If you upgrade the node from version 3.4 or lower and the node is configured to return the &/usr/share/nginx/html/wallarm_blocked.html page in response to the blocked requests, copy and customize the new version of a sample page.

Step 7: Rename deprecated NGINX directives

Rename the following NGINX directives if they are explicitly specified in configuration files:

We only changed directive names, their logic remains the same. The directives with former names will be deleted in future releases, so it is recommended to rename them before.

Step 8: 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 9: 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 greylisted 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 10: Restart NGINX

sudo systemctl restart nginx

sudo service nginx restart

sudo systemctl restart nginx

sudo systemctl restart nginx

Step 11: Test Wallarm node operation

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

    curl http://localhost/?id='or+1=1--a-<script>prompt(1)</script>'

  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 → Events in the EU Cloud or US Cloud and make sure that:

    • Attacks are displayed in the list.
    • Hit details display the Wallarm node UUID.

    Attacks in the interface

Step 12: 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

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

Common customization options: