Skip to content

Separate Postanalytics Module Installation

In Wallarm's request processing, two stages are involved, including the postanalytics stage for statistical request analysis. Postanalytics is memory-intensive, which may require it to be performed on a dedicated server for optimized performance. This article explains how to install the postanalytics module on a separate server.

The option to install the postanalytics module on a separate server is available for the following Wallarm artifacts:

By default, Wallarm deployment instructions guide you to install both modules on the same server.

Overview

The processing of requests in the Wallarm node consists of two stages:

  • Primary processing in the NGINX-Wallarm module, which is not memory demanding and can be executed on frontend servers without altering server requirements.

  • Statistical analysis of the processed requests in the postanalytics module which is memory demanding.

The schemes below depict module interaction in two scenarios: when installed on the same server and on different servers.

Traffic flow between postanalytics and nginx-wallarm

Traffic flow between postanalytics and nginx-wallarm

Installation methods

You can install the postanalytics module on a separate server in two different ways:

  • Using all-in-one installer (available starting from Wallarm node 4.6) - automates a lot of activities and makes postanalytics module deployment much easier. Thus this is a recommended installation method.

  • Manually - use for older node versions.

When installing filtering and postanalytics module separately, you can combine manual and automatic approaches: install the postanalytics part manually and then the filtering part with all-in-one installer, and vise versa: the postanalytics part with all-in-one installer and then then the filtering part manually.

All-in-one automatic installation

Starting from Wallarm node 4.6, to install postanalytics separately, it is recommended to use the all-in-one installation which automates a lot of activities and makes postanalytics module deployment much easier.

Requirements

  • Access to the account with the Administrator role and two‑factor authentication disabled in Wallarm Console for the US Cloud or EU Cloud

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

  • 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 if working with US Wallarm Cloud or to https://api.wallarm.com if working with EU Wallarm Cloud. If access can be configured only via the proxy server, then use the instructions

  • Installed text editor vim, nano, or any other. In the commands in this article, vim is used

Step 1: Download all-in-one Wallarm installer

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

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

Step 2: 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 3: Run all-in-one Wallarm installer to install postanalytics

To install postanalytics separately with all-in-one installer, use:

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

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

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.5.x86_64-glibc.sh postanalytics

# If using the ARM64 version:
sudo sh wallarm-4.10.5.aarch64-glibc.sh postanalytics

Step 4: Configure the postanalytics module

Resources and memory

To change how much memory Tarantool uses, look for the SLAB_ALLOC_ARENA setting in the /opt/wallarm/env.list file. It is set to use 1 GB by default. If you need to change this, you can adjust the number to match the amount of memory Tarantool actually needs. For help on how much to set, see our recommendations.

To change allocated memory:

  1. Open for editing the /opt/wallarm/env.list file:

    sudo vim /opt/wallarm/env.list
    
  2. Set the SLAB_ALLOC_ARENA attribute to memory size. The value can be an integer or a float (a dot . is a decimal separator). For example:

    SLAB_ALLOC_ARENA=2.0
    

Host and port

By default, the postanalytics module is set to accept connections on all IPv4 addresses of the host (0.0.0.0) using port 3313. It is recommended to retain the default configuration unless a change is necessary.

However, if you need to change the default configuration:

  1. Open for editing the /opt/wallarm/env.list file:

    sudo vim /opt/wallarm/env.list
    
  2. Update the HOST and PORT values as required. Define the PORT variable if it is not already specified, for example:

    # tarantool
    HOST=0.0.0.0
    PORT=3300
    
  3. Open for editing the /opt/wallarm/etc/wallarm/node.yaml file:

    sudo vim /opt/wallarm/etc/wallarm/node.yaml
    
  4. Enter the new host and port values for the tarantool parameters, as shown below:

    hostname: <name of postanalytics node>
    uuid: <UUID of postanalytics node>
    secret: <secret key of postanalytics node>
    tarantool:
        host: '0.0.0.0'
        port: 3300
    

Step 5: Enable inbound connections for the postanalytics module

The postanalytics module uses port 3313 by default, but some cloud platforms may block inbound connections on this port.

To guarantee integration, allow inbound connections on port 3313 or your custom port. This step is essential for the NGINX-Wallarm module, installed separately, to connect with the Tarantool instance.

Step 6: Restart the Wallarm services

After making the necessary changes, restart the Wallarm services on the machine hosting the postanalytics module to apply the updates:

sudo systemctl restart wallarm.service

Step 7: Install the NGINX-Wallarm module on a separate server

Once the postanalytics module is installed on the separate server:

  1. Install the NGINX-Wallarm module on a different server following the corresponding guide.

  2. When launching the installation script for the NGINX-Wallarm module on a separate server, include the filtering option, for example:

    # If using the x86_64 version:
    sudo env WALLARM_LABELS='group=<GROUP>' sh wallarm-4.10.5.x86_64-glibc.sh filtering
    
    # If using the ARM64 version:
    sudo env WALLARM_LABELS='group=<GROUP>' sh wallarm-4.10.5.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.5.x86_64-glibc.sh filtering
    
    # If using the ARM64 version:
    sudo sh wallarm-4.10.5.aarch64-glibc.sh filtering
    

Step 8: Connect the NGINX-Wallarm module to the postanalytics module

On the machine with the NGINX-Wallarm module, in the NGINX configuration file, specify the postanalytics module server address:

upstream wallarm_tarantool {
    server <ip1>:3313 max_fails=0 fail_timeout=0 max_conns=1;
    server <ip2>:3313 max_fails=0 fail_timeout=0 max_conns=1;

    keepalive 2;
    }

    # omitted

wallarm_tarantool_upstream wallarm_tarantool;
  • max_conns value must be specified for each of the upstream Tarantool servers to prevent the creation of excessive connections.

  • keepalive value must not be lower than the number of the Tarantool servers.

Once the configuration file changed, restart NGINX/NGINX Plus on the NGINX-Wallarm module server:

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

Step 9: Check the NGINX‑Wallarm and separate postanalytics modules interaction

To check the NGINX‑Wallarm and separate postanalytics modules interaction, you can send the request with test attack to the address of the protected application:

curl http://localhost/etc/passwd

If the NGINX‑Wallarm and separate postanalytics modules are configured properly, the attack will be uploaded to the Wallarm Cloud and displayed in the Attacks section of Wallarm Console:

Attacks in the interface

If the attack was not uploaded to the Cloud, please check that there are no errors in the services operation:

  • Analyze the postanalytics module logs

    sudo cat /opt/wallarm/var/log/wallarm/tarantool-out.log
    

    If there is the record like SystemError binary: failed to bind: Cannot assign requested address, make sure that the server accepts connection on specified address and port.

  • On the server with the NGINX‑Wallarm module, analyze the NGINX logs:

    sudo cat /var/log/nginx/error.log
    

    If there is the record like [error] wallarm: <address> connect() failed, make sure that the address of separate postanalytics module is specified correctly in the NGINX‑Wallarm module configuration files and separate postanalytics server accepts connection on specified address and port.

  • On the server with the NGINX‑Wallarm module, get the statistics on processed requests using the command below and make sure that the value of tnt_errors is 0

    curl http://127.0.0.8/wallarm-status
    

    Description of all parameters returned by the statistics service →

Manual installation

Requirements

  • Access to the account with the Administrator role and two‑factor authentication disabled in Wallarm Console for the US Cloud or EU Cloud

  • SELinux disabled or configured upon the instructions

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

  • Access to https://repo.wallarm.com to download packages. Ensure the access is not blocked by a firewall

  • 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. If access can be configured only via the proxy server, then use the instructions

  • Installed text editor vim, nano, or any other. In the commands in this article, vim is used

Step 1: Add Wallarm repositories

The postanalytics module, like the other Wallarm modules, is installed and updated from the Wallarm repositories. To add repositories, use the commands for your platform:

sudo apt -y install dirmngr
curl -fsSL https://repo.wallarm.com/wallarm.gpg | sudo apt-key add -
sh -c "echo 'deb https://repo.wallarm.com/debian/wallarm-node buster/4.8/' | sudo tee /etc/apt/sources.list.d/wallarm.list"
sudo apt update
sudo apt -y install dirmngr
curl -fSsL https://repo.wallarm.com/wallarm.gpg | sudo gpg --no-default-keyring --keyring gnupg-ring:/etc/apt/trusted.gpg.d/wallarm.gpg --import
sudo chmod 644 /etc/apt/trusted.gpg.d/wallarm.gpg
sh -c "echo 'deb https://repo.wallarm.com/debian/wallarm-node bullseye/4.8/' | sudo tee /etc/apt/sources.list.d/wallarm.list"
sudo apt update
curl -fsSL https://repo.wallarm.com/wallarm.gpg | sudo apt-key add -
sh -c "echo 'deb https://repo.wallarm.com/ubuntu/wallarm-node bionic/4.8/' | sudo tee /etc/apt/sources.list.d/wallarm.list"
sudo apt update
curl -fsSL https://repo.wallarm.com/wallarm.gpg | sudo apt-key add -
sh -c "echo 'deb https://repo.wallarm.com/ubuntu/wallarm-node focal/4.8/' | sudo tee /etc/apt/sources.list.d/wallarm.list"
sudo apt update
curl -fsSL https://repo.wallarm.com/wallarm.gpg | sudo apt-key add -
sh -c "echo 'deb https://repo.wallarm.com/ubuntu/wallarm-node jammy/4.8/' | sudo tee /etc/apt/sources.list.d/wallarm.list"
sudo apt update
sudo yum install -y epel-release
sudo rpm -i https://repo.wallarm.com/centos/wallarm-node/7/4.8/x86_64/wallarm-node-repo-4.8-0.el7.noarch.rpm
sudo yum install -y https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm
sudo rpm -i https://repo.wallarm.com/centos/wallarm-node/7/4.8/x86_64/wallarm-node-repo-4.8-0.el7.noarch.rpm
sudo yum install -y epel-release
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 dnf install -y https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm
sudo rpm -i https://repo.wallarm.com/centos/wallarm-node/8/4.8/x86_64/wallarm-node-repo-4.8-0.el8.noarch.rpm

Step 2: Install packages for the postanalytics module

Install the wallarm-node-tarantool package from the Wallarm repository for the postanalytics module and Tarantool database:

sudo apt -y install --no-install-recommends wallarm-node-tarantool
sudo apt -y install --no-install-recommends wallarm-node-tarantool
sudo yum install -y wallarm-node-tarantool
sudo yum install -y wallarm-node-tarantool
sudo yum install -y wallarm-node-tarantool

Step 3: Connect the postanalytics module to Wallarm Cloud

The postanalytics module interacts with the Wallarm Cloud. It is required to create the Wallarm node for the postanalytics module and connect this node to the Cloud. When connecting, you can set the postanalytics node name, under which it will be displayed in the Wallarm Console UI and put the node into the appropriate node group (used to logically organize nodes in UI). It is recommended to use the same node group for the node processing initial traffic and for the node performing postanalysis.

Grouped nodes

To provide the node with access, you need to generate a token on the Cloud side and specify it on the machine with the node packages.

To connect the postanalytics filtering node to the Cloud:

  1. Get Wallarm token of the appropriate type:

    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.
  2. Run the register-node script on a machine where you install the filtering node:

    sudo /usr/share/wallarm-common/register-node -t <TOKEN> --labels 'group=<GROUP>' -H us1.api.wallarm.com --no-sync --no-sync-acl
    
    • <TOKEN> is the copied value of the API token with the Deploy role.
    • --labels 'group=<GROUP>' parameter puts your node to the <GROUP> node group (existing, or, if does not exist, it will be created).
    sudo /usr/share/wallarm-common/register-node -t <TOKEN> -H us1.api.wallarm.com --no-sync --no-sync-acl
    
    • <TOKEN> is the copied value of the node token.
    • Use -H us1.api.wallarm.com to install into US Cloud, remove this option to install to EU Cloud.
    • You may add -n <HOST_NAME> parameter to set a custom name for your node instance. Final instance name will be: HOST_NAME_NodeUUID.

Step 4: Update postanalytics module configuration

The configuration files of the postanalytics module are located in the paths:

  • /etc/default/wallarm-tarantool for Debian and Ubuntu operating systems

  • /etc/sysconfig/wallarm-tarantool for CentOS and Amazon Linux 2.0.2021x and lower operating systems

To open the file in the editing mode, please use the command:

sudo vim /etc/default/wallarm-tarantool
sudo vim /etc/default/wallarm-tarantool
sudo vim /etc/sysconfig/wallarm-tarantool
sudo vim /etc/sysconfig/wallarm-tarantool
sudo vim /etc/sysconfig/wallarm-tarantool

Memory

The postanalytics module uses the in-memory storage Tarantool. For production environments, it is recommended to have larger amount of memory. If testing the Wallarm node or having a small server size, the lower amount can be enough.

The allocated memory size is set in GB via the SLAB_ALLOC_ARENA directive in the /etc/default/wallarm-tarantool or /etc/sysconfig/wallarm-tarantool configuration file. The value can be an integer or a float (a dot . is a decimal separator).

Detailed recommendations about allocating memory for Tarantool are described in these instructions.

Address of the separate postanalytics server

To set the address of the separate postanalytics server:

  1. Open the Tarantool file in the editing mode:

    sudo vim /etc/default/wallarm-tarantool
    
    sudo vim /etc/default/wallarm-tarantool
    
    sudo vim /etc/sysconfig/wallarm-tarantool
    
    sudo vim /etc/sysconfig/wallarm-tarantool
    
    sudo vim /etc/sysconfig/wallarm-tarantool
    
  2. Uncomment the HOST and PORT variables and set them the following values:

    # address and port for bind
    HOST='0.0.0.0'
    PORT=3313
    
  3. If the configuration file of Tarantool is set up to accept connections on the IP addresses different from 0.0.0.0 or 127.0.0.1, then please provide the addresses in /etc/wallarm/node.yaml:

    hostname: <name of postanalytics node>
    uuid: <UUID of postanalytics node>
    secret: <secret key of postanalytics node>
    tarantool:
        host: '<IP address of Tarantool>'
        port: 3313
    

Step 5: Restart Wallarm services

To apply the settings to the postanalytics module:

sudo systemctl restart wallarm-tarantool
sudo systemctl restart wallarm-tarantool
sudo systemctl restart wallarm-tarantool
sudo systemctl restart wallarm-tarantool
sudo systemctl restart wallarm-tarantool

Step 6: Install the NGINX-Wallarm module on a separate server

Once the postanalytics module is installed on the separate server, install the other Wallarm modules on a different server. Below are the links to the corresponding instructions and the package names to be specified for the NGINX-Wallarm module installation:

  • NGINX stable

    In the package installation step, specify wallarm-node-nginx and nginx-module-wallarm.

  • NGINX Plus

    In the package installation step, specify wallarm-node-nginx and nginx-plus-module-wallarm.

  • Distribution-provided NGINX

    In the package installation step, specify wallarm-node-nginx and libnginx-mod-http-wallarm/nginx-mod-http-wallarm.

The wallarm-node-tarantool package version

The wallarm-node-tarantool package must be of the same or a higher version than the primary NGINX-Wallarm module packages installed on a separate server.

To check versions:

# run from the server with primary NGINX-Wallarm module
apt list wallarm-node-nginx
# run from the server with the postanalytics module
apt list wallarm-node-tarantool
# run from the server with primary NGINX-Wallarm module
apt list wallarm-node-nginx
# run from the server with the postanalytics module
apt list wallarm-node-tarantool
# run from the server with primary NGINX-Wallarm module
yum list wallarm-node-nginx
# run from the server with the postanalytics module
yum list wallarm-node-tarantool
# run from the server with primary NGINX-Wallarm module
yum list wallarm-node-nginx
# run from the server with the postanalytics module
yum list wallarm-node-tarantool
# run from the server with primary NGINX-Wallarm module
yum list wallarm-node-nginx
# run from the server with the postanalytics module
yum list wallarm-node-tarantool

Step 7: Connect the NGINX-Wallarm module to the postanalytics module

On the machine with the NGINX-Wallarm module, in the NGINX configuration file, specify the postanalytics module server address:

upstream wallarm_tarantool {
    server <ip1>:3313 max_fails=0 fail_timeout=0 max_conns=1;
    server <ip2>:3313 max_fails=0 fail_timeout=0 max_conns=1;

    keepalive 2;
    }

    # omitted

wallarm_tarantool_upstream wallarm_tarantool;
  • max_conns value must be specified for each of the upstream Tarantool servers to prevent the creation of excessive connections.

  • keepalive value must not be lower than the number of the Tarantool servers.

  • The # wallarm_tarantool_upstream wallarm_tarantool; string is commented by default - please delete #.

Once the configuration file changed, restart NGINX/NGINX Plus on the NGINX-Wallarm module server:

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

Step 8: Check the NGINX‑Wallarm and separate postanalytics modules interaction

To check the NGINX‑Wallarm and separate postanalytics modules interaction, you can send the request with test attack to the address of the protected application:

curl http://localhost/etc/passwd

If the NGINX‑Wallarm and separate postanalytics modules are configured properly, the attack will be uploaded to the Wallarm Cloud and displayed in the Attacks section of Wallarm Console:

Attacks in the interface

If the attack was not uploaded to the Cloud, please check that there are no errors in the services operation:

  • Make sure that the postanalytics service wallarm-tarantool is in the status active

    sudo systemctl status wallarm-tarantool
    

    wallarm-tarantool status

  • Analyze the postanalytics module logs

    sudo cat /var/log/wallarm/tarantool.log
    

    If there is the record like SystemError binary: failed to bind: Cannot assign requested address, make sure that the server accepts connection on specified address and port.

  • On the server with the NGINX‑Wallarm module, analyze the NGINX logs:

    sudo cat /var/log/nginx/error.log
    

    If there is the record like [error] wallarm: <address> connect() failed, make sure that the address of separate postanalytics module is specified correctly in the NGINX‑Wallarm module configuration files and separate postanalytics server accepts connection on specified address and port.

  • On the server with the NGINX‑Wallarm module, get the statistics on processed requests using the command below and make sure that the value of tnt_errors is 0

    curl http://127.0.0.8/wallarm-status
    

    Description of all parameters returned by the statistics service →

Postanalytics module protection

Protect installed postanalytics module

We highly recommend to protect a newly installed Wallarm postanalytics module with a firewall. Otherwise, there is a risk of getting unauthorized access to the service that may result in:

  • Disclosure of information about processed requests
  • Possibility of executing arbitrary Lua code and operating system commands

Please note that no such risk exists if you are deploying the postanalytics module alongside with the NGINX-Wallarm module on the same server. This holds true because the postanalytics module will listen to the port 3313.

Here are the firewall settings that should be applied to the separately installed postanalytics module:

  • Allow the HTTPS traffic to and from the Wallarm API servers, so the postanalytics module can interact with these servers:
    • us1.api.wallarm.com is the API server in the US Wallarm Cloud
    • api.wallarm.com is the API server in the EU Wallarm Cloud
  • Restrict the access to the 3313 Tarantool port via TCP and UDP protocols by allowing connections only from the IP addresses of the Wallarm filtering nodes.

Tarantool troubleshooting

Tarantool troubleshooting