Deploying as an Amazon Machine Image (AMI)

To deploy an Amazon Machine Image with Wallarm Node:

  1. Log in to you Amazon Web Services account.
  2. Launch a Wallarm Node instance.
  3. SSH to the Wallarm Node instance.
  4. Set up the filter node for using a proxy server.
  5. Connect the Wallarm Node to Wallarm Cloud.
  6. Set up filtering and proxying rules.
  7. Instance memory allocation for the Wallarm Node.
  8. Restart NGINX.

1. Log in to Your Amazon Web Services Account

Log in at aws.amazon.com.

2. Launch a Wallarm Node Instance

Launch your Wallarm Node instance from Amazon Marketplace. The instance will launch with a pre-installed Wallarm Node.

For the reference: Amazon Elastic Compute Cloud: Launching an Instance.

3. SSH to the Wallarm Node Instance

Use the admin user name to connect to the instance.

See Amazon Elastic Compute Cloud: Connecting to Your Linux Instance Using SSH.

4. Set up the Filter Node for Using a Proxy Server

This setup step is intended for users who use their own proxy server for the operation of the protected web applications.

If you do not use a proxy server, skip this step of the setup.

You need to assign new values to the environment variables, which define the proxy server used, to configure Wallarm node for using your proxy server.

Add the following exports of the new values of the environment variables to the /etc/environment file:

  • Add export https_proxy to define a proxy for the https protocol.
  • Add export http_proxy to define a proxy for the http protocol.
  • Add export no_proxy to define the list of the resources proxy should not be used for.

Assign the <scheme>://<proxy_user>:<proxy_pass>@<host>:<port> string values to the https_proxy and http_proxy variables.

  • <scheme> defines the protocol used. It should match the protocol that the current environment variable sets up proxy for.
  • <proxy_user> defines the username for proxy authorization.
  • <proxy_pass> defines the password for proxy authorization.
  • <host> defines a host of the proxy server.
  • <port> defines a port of the proxy server.

Assign a "<res_1>, <res_2>, <res_3>, <res_4>, ..." array value, where <res_1>, <res_2>, <res_3>, and <res_4> are the IP addresses and/or domains, to the no_proxy variable to define a list of the resources which proxy should not be used for. This array should consist of IP addresses and/or domains.

Resources that need to be addressed without a proxy

Add the following IP addresses and domain to the list of the resources that have to be addressed without a proxy for the system to operate correctly: 127.0.0.1, 127.0.0.8, 127.0.0.9, and localhost.

The 127.0.0.8 and 127.0.0.9 IP addresses are used for the operation of the Wallarm filter node.

The example of the correct /etc/environment file contents below demonstrates the following configuration:

  • The https and http protocols use the 1.2.3.4 host and the 1234 port for request proxying.
  • The https and http protocols use the admin username and the 01234 password for proxy authorization.
  • Proxying is disabled for the requests sent to 127.0.0.1, 127.0.0.8, 127.0.0.9, and localhost.
export https_proxy=http://admin:01234@1.2.3.4:1234
export http_proxy=http://admin:01234@1.2.3.4:1234
export no_proxy="127.0.0.1, 127.0.0.8, 127.0.0.9, localhost"

5. Connect the Wallarm Node to the Wallarm Cloud

The filter node interacts with the Wallarm cloud located on a remote server.

The addnode script connects the filter node to the Wallarm cloud.

  1. Run the script addnode:

    You have to pick the script to run depending on the Cloud you are using.

    EU Cloud
    US Cloud
    sudo /usr/share/wallarm-common/addnode
    sudo /usr/share/wallarm-common/addnode -H us1.api.wallarm.com

  2. Enter the login and password. This is the same login and password that you use to access Wallarm console at https://my.wallarm.com or https://us1.my.wallarm.com/. The profile must have the Administrator role and 2FA should be disabled. If the profile has the Analyst role or has 2FA enabled, the script will error out.

API Access

The API choice for your filter node depends on the Cloud you are using. Please, select the API accordingly:

Ensure the access is not blocked by a firewall.

6. Set up Filtering and Proxying Rules

The etc/nginx/conf.d directory contains NGINX and Wallarm filter node configuration files.

By default, this directory contains the following configuration files:

  • The default.conf file defines the configuration of NGINX.
  • The wallarm.conf file defines the global configuration of Wallarm filter node.
  • The wallarm-status.conf file defines the Wallarm monitoring configuration.

You can create your own configuration files to define the operation of NGINX and Wallarm. It is recommended to create a separate configuration file with the server block for each group of the domains that should be processed in the same way.

To see detailed information about working with NGINX configuration files, proceed to the official NGINX documentation.

Wallarm directives define the operation logic of the Wallarm filter node. To see the list of Wallarm directives available, proceed to the Wallarm configuration options page.

A Configuration File Example

Let us suppose that you need to configure the server to work in the following conditions:

  • Only HTTP traffic is processed. There are no HTTPS requests processed.
  • The following domains receive the requests: example.com and www.example.com.
  • All requests must be passed to the server 10.80.0.5.
  • All incoming requests are considered less than 1MB in size (default setting).
  • The processing of a request takes no more than 60 seconds (default setting).
  • Wallarm must operate in the monitor mode.
  • Clients access the filter node directly, without an intermediate HTTP load balancer.

Creating a configuration file

You can create a custom NGINX configuration file (e.g. example.com.conf) or modify the default NGINX configuration file (default.conf).

When creating a custom configuration file, make sure that NGINX listens to the incoming connections on the free port.

To meet the listed conditions, the contents of the configuration file must be the following:


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

      # the domains for which traffic is processed
      server_name example.com; 
      server_name www.example.com;

      # turn on the monitoring mode of traffic processing
      wallarm_mode monitoring; 
      # wallarm_instance 1;

      location / {
        # setting the address for request forwarding
        proxy_pass http://10.80.0.5; 
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
      }
    }

7. Instance Memory Allocation for the Wallarm Node

Wallarm Node uses the in-memory storage Tarantool.

By default, the amount of RAM allocated to Tarantool is 75% of the total instance memory.

You can change the amount of RAM allocated for Tarantool

To allocate the instance RAM to Tarantool:

  1. Open the Tarantool configuration file:

    vi /etc/default/wallarm-tarantool

  2. Set the amount of allocated RAM in the SLAB_ALLOC_ARENA in GB. For example, to set 24 GB:

    SLAB_ALLOC_ARENA=24

  3. To apply changes, restart the Tarantool daemon:

    systemctl restart wallarm-tarantool

8. Restart NGINX

Restart NGINX by running the following command:

systemctl restart nginx

The Installation Is Complete

Check that the filter node runs and filters the traffic. See Check the filter node operation.

results matching ""

    No results matching ""