All-in-Oneインストーラーによるデプロイ¶

これらの手順は、さまざまな環境においてNGINXの動的モジュールとしてWallarmノードをインストールするプロセスの効率化と標準化を目的とした、OOB動的モジュールとしてWallarmをインストールするためのall-in-one installerを使用した手順を説明します。このインストーラーは、使用しているオペレーティングシステムおよびNGINXのバージョンを自動的に識別し、必要な依存関係をすべてインストールします。

all-in-one installerは、以下の動作を自動的に実行することにより、シンプルなノードのインストールプロセスを提供します：

1. OSおよびNGINXのバージョンを確認します。

2. 検出されたOSとNGINXのバージョンに対してWallarmリポジトリを追加します。

3. これらのリポジトリからWallarmパッケージをインストールします。

4. インストールされたWallarmモジュールをNGINXに接続します。

5. 提供されたトークンを使用してフィルタリングノードをWallarm Cloudに接続します。

ユースケース¶

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.

要件¶

• 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 9.x
  • RHEL 8.x
  • RHEL 9.x
  • Oracle Linux 8.x
  • Redox
  • 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 below for downloading updates to attack detection rules and API specifications, as well as retrieving precise IPs for your allowlisted, denylisted, or graylisted countries, regions, or data centers

  US CloudEU Cloud

  34.96.64.17
  34.110.183.149
  35.235.66.155
  34.102.90.100
  34.94.156.115
  35.235.115.105
  

  34.160.38.183
  34.144.227.90
  34.90.110.226
  

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

ステップ1: NGINXと依存関係をインストールします¶

Install the latest NGINX version of:

• NGINX stable (the latest supported version is v1.28.0) - see how to install it in the NGINX documentation.

• NGINX Mainline (the latest supported version is v1.27.5) - see how to install it in the NGINX documentation.

• NGINX Plus (the latest supported version is NGINX Plus R33) - see how to install it in the NGINX documentation.

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

  DebianUbuntuCentOSAlmaLinux, Rocky Linux or Oracle Linux 8.xRHEL 8.x

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

  sudo apt-get update
  sudo apt-get install 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
  

ステップ2: Wallarmトークンの準備¶

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

ステップ3: all-in-one Wallarmインストーラーのダウンロード¶

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/6.1/wallarm-6.1.0.x86_64-glibc.sh

curl -O https://meganode.wallarm.com/6.1/wallarm-6.1.0.aarch64-glibc.sh

ステップ4: all-in-one Wallarmインストーラーの実行¶

1. Run downloaded script:

   API tokenNode token

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

2. Select US Cloud or EU Cloud.

3. Enter Wallarm token.

以降の手順のコマンドは、x86_64およびARM64インストールに共通です。

ステップ5: Wallarmノードによるトラフィック解析を有効化します¶

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

Perform the following configuration in the NGINX configuration file on the machine with the installed node to configure Wallarm to process the traffic mirror:

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

3. If present, remove the try_files directive from the NGINX locations to ensure traffic is directed to Wallarm without local file interference:

   server {
       ...
       location / {
   -        # try_files $uri $uri/ =404;
       }
       ...
   }
   

ステップ6: NGINXの再起動¶

Restart NGINX using the following command:

sudo systemctl restart nginx

ステップ7: Wallarmノードへのトラフィック送信を設定します¶

Configure your environment to mirror incoming traffic to an instance with the Wallarm node you are deploying. For configuration details, we recommend to refer to documentation on the solution you are going to use to produce the traffic mirror (web server, proxy server, etc.).

Inside the link, you will find the example configuration for NGINX, Traefik, Envoy.

ステップ8: Wallarmノードの動作をテストします¶

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

   curl http://localhost/etc/passwd
   

   If traffic is configured to be proxied to example.com, include the -H "Host: example.com" header in the request.

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

   

3. Optionally, test other aspects of the node functioning.

ステップ9: デプロイ済みソリューションの微調整¶

既定の設定で動的Wallarmモジュールがインストールされます。デプロイ後、フィルタリングノードには追加の設定が必要になる場合があります。

Wallarmの設定はNGINXディレクティブまたはWallarm Console UIを使用して定義されます。ディレクティブは、Wallarmノードがインストールされているマシンの以下のファイルに設定します：

• /etc/nginx/sites-available/default （サーバーレベルおよびロケーションレベルの設定用）

• /etc/nginx/nginx.conf （httpレベルの設定用）

• /etc/nginx/wallarm-status.conf はWallarmノードの監視設定用です。詳細な説明はリンクをご参照ください。

• /opt/wallarm/etc/collectd/wallarm-collectd.conf.d/wallarm-tarantool.conf はTarantoolから統計情報を収集するcollectdプラグインの設定用です。

以下に、必要に応じて適用できる一般的な設定例をいくつか示します：

• Wallarmノードのリソース割り当て

• Wallarmノード変数のログ記録

• フィルタリングノードの背後にあるプロキシサーバーのバランサーの使用

• ディレクティブwallarm_process_time_limitにおける単一リクエスト処理時間の制限

• NGINXディレクティブproxy_read_timeoutにおけるサーバー応答待機時間の制限

• NGINXディレクティブclient_max_body_sizeにおける最大リクエストサイズの制限

• NGINXにおける動的DNS解決の設定

起動オプション¶

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

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

Which returns:

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

OPTION                      DESCRIPTION
-b, --batch                 Batch mode, non-interactive installation.
    --install-only          Initiates the first stage of the all-in-one installer in batch mode. Copies essential configurations, including files and binaries, and sets up NGINX for node installation, bypassing Cloud registration and activation. Requires --batch.
    --skip-ngx-config       Avoids automatic NGINX configuration changes that occur during the --install-only stage in batch mode, suitable for users who prefer manual adjustments later. When used with --install-only, it ensures only essential configurations are copied without altering NGINX settings. Requires --batch.
    --register-only         Initiates the second stage of the all-in-one installer in batch mode, completing the setup by registering the node in the Cloud and starting its service. Requires --batch.
-t, --token TOKEN           Node token, required 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

Batch mode¶

The --batch option triggers batch (non-interactive) mode, where the script requires configuration options via the --token and --cloud flags, along with the WALLARM_LABELS environment variable if needed. In this mode, the script does not prompt the user for data input step by step as in the default mode; instead, it requires explicit commands for interaction.

Below are examples of commands to run the script in batch mode for node installation, assuming the script has already been downloaded:

# If using the x86_64 version:
sudo env WALLARM_LABELS='group=<GROUP>' sh wallarm-6.1.0.x86_64-glibc.sh -- --batch -t <TOKEN> -c US

# If using the ARM64 version:
sudo env WALLARM_LABELS='group=<GROUP>' sh wallarm-6.1.0.aarch64-glibc.sh -- --batch -t <TOKEN> -c US

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

# If using the ARM64 version:
sudo env WALLARM_LABELS='group=<GROUP>' sh wallarm-6.1.0.aarch64-glibc.sh -- --batch -t <TOKEN>

Separate execution of node installation stages¶

When preparing your own machine image using the all-in-one installer for cloud infrastructure, the standard installation process outlined in this article may not suffice. Instead, you will need to execute specific stages of the all-in-one installer separately to accommodate the requirements of creating and deploying a machine image:

1. Build machine image: At this stage, it is necessary to download binaries, libraries, and configuration files of the filtering node and create a machine image based on them. Utilizing the --install-only flag, the script copies the required files and modifies NGINX configurations for node operation. If you wish to make manual adjustments, you can opt to bypass the NGINX file modification by using the --skip-ngx-config flag.

2. Initialize a cloud instance with cloud-init: During instance initialization, the bootstrap phase (cloud registration and service start) can be executed using cloud-init scripts. This stage can be run independently from the build phase by applying the --register-only flag to the /opt/wallarm/setup.sh script copied during the build stage.

This functionality is supported starting from version 4.10.0 of the all-in-one installer in batch mode. The commands below enable the sequential execution of the outlined steps:

# If using the x86_64 version:
curl -O https://meganode.wallarm.com/6.1/wallarm-6.1.0.x86_64-glibc.sh
sudo sh wallarm-6.1.0.x86_64-glibc.sh -- --batch --install-only
sudo env WALLARM_LABELS='group=<GROUP>' /opt/wallarm/setup.sh --batch --register-only -t <TOKEN> -c US

# If using the ARM64 version:
curl -O https://meganode.wallarm.com/6.1/wallarm-6.1.0.aarch64-glibc.sh
sudo sh wallarm-6.1.0.aarch64-glibc.sh -- --batch --install-only
sudo env WALLARM_LABELS='group=<GROUP>' /opt/wallarm/setup.sh --batch --register-only -t <TOKEN> -c US

# If using the x86_64 version:
curl -O https://meganode.wallarm.com/6.1/wallarm-6.1.0.x86_64-glibc.sh
sudo sh wallarm-6.1.0.x86_64-glibc.sh -- --batch --install-only
sudo env WALLARM_LABELS='group=<GROUP>' /opt/wallarm/setup.sh --batch --register-only -t <TOKEN>

# If using the ARM64 version:
curl -O https://meganode.wallarm.com/6.1/wallarm-6.1.0.aarch64-glibc.sh
sudo sh wallarm-6.1.0.aarch64-glibc.sh -- --batch --install-only
sudo env WALLARM_LABELS='group=<GROUP>' /opt/wallarm/setup.sh --batch --register-only -t <TOKEN>

Finally, to complete the installation, you need to enable Wallarm to analyze traffic and restart NGINX.

Separate installation of filtering and postanalytics nodes¶

The filtering/postanalytics switch provides the option to install the postanalytics module separately. Without this switch, both filtering and postanalytics components are installed together by default.

API Discovery-only mode¶

You can use the node in API Discovery-only mode (available since version 5.3.7). In this mode, attacks - including those detected by the Node's built-in mechanisms and those requiring additional configuration (e.g., credential stuffing, API specification violation attempts, and malicious activity from denylisted and graylisted IPs) - are detected and blocked locally (if enabled) but not exported to Wallarm Cloud. Since there is no attack data in the Cloud, [Threat Replay Testing][threat-replay-testing-docs] does not work. Traffic from whitelisted IPs is allowed.

Meanwhile, [API Discovery][api-discovery-docs], [API session tracking][api-sessions-docs], and [security vulnerability detection][vuln-detection-docs] remain fully functional, detecting relevant security entities and uploading them to the Cloud for visualization.

This mode is for those who want to review their API inventory and identify sensitive data first, and plan controlled attack data export accordingly. However, disabling attack export is rare, as Wallarm securely processes attack data and provides [sensitive attack data masking][masking-sensitive-data-rule] if needed.

To enable API Discovery-only mode:

1. Create or modify the /etc/wallarm-override/env.list file:

   sudo mkdir /etc/wallarm-override
   sudo vim /etc/wallarm-override/env.list
   

   Add the following variable:

   WALLARM_APID_ONLY=true
   

2. Follow the node installation procedure.

With the API Discovery-only mode enabled, the /opt/wallarm/var/log/wallarm/wcli-out.log log returns the following message:

{"level":"info","component":"reqexp","time":"2025-01-31T11:59:38Z","message":"requests export skipped (disabled)"}

インストールの再実行¶

Wallarmノードのインストールを削除し、再度開始する必要がある場合は、以下の手順に従ってください。

1. Wallarmプロセスを終了し、設定ファイルを削除します：

   sudo systemctl stop wallarm
   sudo rm -rf /opt/wallarm
   

2. ステップ2のセットアップ手順に従い、再インストールプロセスを続行します。

Was this page helpful?

How can we improve this article? (Optional)

Information is unclear or confusing

Insufficient information

Outdated or incorrect information

0/240

Send