Skip to content

Deploying with All-in-One Installer

An all-in-one installer is designed to streamline and standardize the process of installing Wallarm node as a dynamic module for NGINX in various environments. This installer automatically identifies your operating system’s and NGINX versions, and install all the necessary dependencies.

In comparison to the individual Linux packages offered by Wallarm for NGINX, NGINX Plus, and distribution-provided NGINX, the all-in-one installer simplifies the process by automatically performing the following actions:

  1. Checking your OS and NGINX version.

  2. Adding Wallarm repositories for the detected OS and NGINX version.

  3. Installing Wallarm packages from these repositories.

  4. Connecting the installed Wallarm module to your NGINX.

  5. Connecting the filtering node to Wallarm Cloud using the provided token.

All-in-one compared to manual

Use cases

Among all supported Wallarm deployment options, this solution is the recommended one for the following use cases:

  • Your infrastructure is based on bare metal or virtual machines without using container-based methods. Typically, these setups are managed with Infrastructure as Code (IaC) tools like Ansible or SaltStack.

  • Your services are built around NGINX. Wallarm can extend its functionalities using the all-in-one installer.

Requirements

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

  • 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
    • 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)

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

  • Access to the IP addresses of Google Cloud Storage listed within the link. When you allowlist, denylist, or graylist entire countries, regions, or data centers instead of individual IP addresses, the Wallarm node retrieves precise IP addresses related to the entries in the IP lists from the aggregated database hosted on Google Storage.

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

Step 1: Install NGINX and dependencies

Install the latest NGINX version of:

  • NGINX stable - 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

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 → Settings → API 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: 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.6/wallarm-4.6.12.x86_64-glibc.sh

curl -O https://meganode.wallarm.com/4.6/wallarm-4.6.12.aarch64-glibc.sh

Step 4: Run all-in-one Wallarm installer

  1. Run downloaded script:

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

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

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

  2. Select US Cloud or EU Cloud.

  3. Enter Wallarm token.

Commands in the further steps are the same for x86_64 and ARM64 installations.

Step 5: Enable Wallarm node to analyze traffic

By default, the deployed Wallarm node does not analyze incoming traffic.

Depending on the selected Wallarm deployment approach (in-line or Out-of-Band), configure Wallarm to either proxy traffic or process the traffic mirror.

Perform the following configuration in the NGINX configuration file on the machine with the installed node:

  1. Set an IP address for Wallarm to proxy legitimate traffic to. It can be an IP of an application instance, load balancer, or DNS name, etc., depending on your architecture.

    To do so, edit the proxy_pass value, e.g. Wallarm should send legitimate requests to http://10.80.0.5:

    server {
    listen 80;
    listen [::]:80 ipv6only=on;

    ...

    location / {
        proxy_pass http://10.80.0.5; 
        ...
    }
}

  2. For the Wallarm node to analyze the incoming traffic, set the wallarm_mode directive to monitoring:

    server {
    listen 80;
    listen [::]:80 ipv6only=on;
    wallarm_mode monitoring;

    ...
}

    The monitoring mode is the recommended one for the first deployment and solution testing. Wallarm provides safe blocking and blocking modes as well, read more.

  1. For the Wallarm node to accept mirrored traffic, set the following configuration in the server NGINX block:

    wallarm_force server_addr $http_x_server_addr;
wallarm_force server_port $http_x_server_port;
# Change 222.222.222.22 to the address of the mirroring server
set_real_ip_from  222.222.222.22;
real_ip_header    X-Forwarded-For;
real_ip_recursive on;
wallarm_force response_status 0;
wallarm_force response_time 0;
wallarm_force response_size 0;
    • The set_real_ip_from and real_ip_header directives are required to have Wallarm Console display the IP addresses of the attackers.
    • The wallarm_force_response_* directives are required to disable analysis of all requests except for copies received from the mirrored traffic.

  2. For the Wallarm node to analyze the mirrored traffic, set the wallarm_mode directive to monitoring:

    server {
    listen 80;
    listen [::]:80 ipv6only=on;
    wallarm_mode monitoring;

    ...
}

    Since malicious requests cannot be blocked, the only mode Wallarm accepts is monitoring. For in-line deployment, there are also safe blocking and blocking modes but even if you set the wallarm_mode directive to a value different from monitoring, the node continues to monitor traffic and only record malicious traffic (aside from the mode set to off).

Step 6: Restart NGINX

Restart NGINX using the following command:

sudo systemctl restart nginx

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

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 8: Test Wallarm node operation

  1. Send the request with test Path Traversal attack to a protected resource address:

    curl http://localhost/etc/passwd

  2. Open Wallarm Console → Events section in the US Cloud or EU Cloud and make sure the attack is displayed in the list.
    Attacks in the interface

Step 9: Fine-tune deployed solution

The dynamic Wallarm module with default settings is installed. The filtering node may require some additional configuration after deployment.

Wallarm settings are defined using the NGINX directives or the Wallarm Console UI. Directives should be set in the following files on the machine with the Wallarm node:

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

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

  • /opt/wallarm/etc/collectd/wallarm-collectd.conf.d/wallarm-tarantool.conf with the settings for the collectd plugin that collects statistics from Tarantool

Below there are a few of the typical settings that you can apply if needed:

Launch options

As soon as you have the all-in one script downloaded, you can get help on it with:

sudo sh ./wallarm-4.6.12.x86_64-glibc.sh -- -h

Which returns:

...
Usage: setup.sh [options]... [arguments]... [filtering/postanalytics]

OPTION                      DESCRIPTION
-b, --batch                 Batch mode, non-interactive installation.
-t, --token TOKEN           Node token, only used in a batch mode.
-c, --cloud CLOUD           Wallarm Cloud, one of US/EU, default is EU, only used in a batch mode.
-H, --host HOST             Wallarm API address, for example, api.wallarm.com or us1.api.wallarm.com, only used in a batch mode.
-P, --port PORT             Wallarm API pot, for example, 443.
    --no-ssl                Disable SSL for Wallarm API access.
    --no-verify             Disable SSL certificates verification.
-f, --force                 If there is a node with the same name, create a new instance.
-h, --help
    --version

Note that:

  • The --batch option enables a batch (non-interactive) mode. In this mode, if you do not use additional parameters, the node is installed immediately after script laungh, requiring no additional interaction or data input from the user. Batch mode:

    • Requires --token
    • Installs node into EU Cloud by default
    • Allows script behavior modifications with additional options

  • The filtering/postanalytics switcher allows installing separately the postanalytics module. If switcher is not used, filtering and postanalytics part are installed altogether.