Skip to content

Deploying Wallarm from Amazon Machine Image

This article provides instructions for deploying Wallarm on AWS using the official Amazon Machine Image (AMI). The solution can be deployed either in-line or Out-of-Band.

Use cases

Among all supported Wallarm deployment options, AMI is recommended for Wallarm deployment in these use cases:

  • Your existing infrastructure resides on AWS.

  • You aim to deploy a security solution as a separate cloud instance, rather than installing it directly on frontend systems like NGINX.

Requirements

  • An AWS account

  • Understanding of AWS EC2, Security Groups

  • Any AWS region of your choice, there are no specific restrictions on the region for the Wallarm node deployment

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

  • Access to https://us1.api.wallarm.com:444 for working with US Wallarm Cloud or to https://api.wallarm.com:444 for working with EU Wallarm Cloud. If access can be configured only via the proxy server, then use the instructions

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

1. Create a pair of SSH keys in AWS

During the deploying process, you will need to connect to the virtual machine via SSH. Amazon EC2 allows creating a named pair of public and private SSH keys that can be used to connect to the instance.

To create a key pair:

  1. Navigate to the Key pairs tab on the Amazon EC2 dashboard.

  2. Click the Create Key Pair button.

  3. Enter a key pair name and click the Create button.

A private SSH key in PEM format will automatically start to download. Save the key to connect to the created instance in the future.

To see detailed information about creating SSH keys, proceed to the AWS documentation.

2. Create a Security Group

A Security Group defines allowed and forbidden incoming and outgoing connections for virtual machines. The final list of connections depends on the protected application (e.g., allowing all of the incoming connections to the TCP/80 and TCP/443 ports).

To create a security group for the filtering node:

  1. Navigate to the Security Groups tab on the Amazon EC2 dashboard and click the Create Security Group button.

  2. Enter a security group name and an optional description into the dialog window that appears.

  3. Select the required VPC.

  4. Configure incoming and outgoing connections rules on the Inbound and Outbound tabs.

  5. Click the Create button to create the security group.

Creating a security group

Rules for outgoing connections from the security group

When creating a security group, all of the outgoing connections are allowed by default. If you restrict outgoing connections from the filtering node, make sure that it is granted access to a Wallarm API server. The choice of a Wallarm API server depends on the Wallarm Cloud you are using:

  • If you are using the US Cloud, your node needs to be granted access to us1.api.wallarm.com.
  • If you are using the EU Cloud, your node needs to be granted access to api.wallarm.com.

The filtering node requires access to a Wallarm API server for proper operation.

To see detailed information about creating a security group, proceed to the AWS documentation.

3. Launch a Wallarm node instance

To launch an instance with the Wallarm filtering node, proceed to this link and subscribe to the filtering node.

When creating an instance, you need to specify the previously created security group as follows:

  1. While working with the Launch Instance Wizard, proceed to the 6. Configure Security Group instance launch step by clicking the corresponding tab.

  2. Choose the Select an existing security group option in the Assign a security group setting.

  3. Select the security group from the list that appears.

After specifying all of the required instance settings, click the Review and Launch button, make sure that instance is configured correctly, and click the Launch button.

In the window that appears, specify the previously created key pair by performing the following actions:

  1. In the first drop-down list, select the Choose an existing key pair option.

  2. In the second drop-down list, select the name of the key pair.

  3. Make sure you have access to the private key in PEM format from the key pair you specified in the second drop-down list and tick the checkbox to confirm this.

  4. Click the Launch Instances button.

The instance will launch with the preinstalled filtering node.

To see detailed information about launching instances in AWS, proceed to the AWS documentation.

4. Connect to the filtering node instance via SSH

To see detailed information about ways to connect to an instance via SSH, proceed to the AWS documentation.

You need to use the admin username to connect to the instance.

Using the key to connect via SSH

Use the private key in PEM format that you created earlier to connect to the instance via SSH. This must be the private key from the SSH key pair that you specified when creating an instance.

5. Connect the filtering node to the Wallarm Cloud

The Wallarm filtering node interacts with the Wallarm Cloud. You need to connect the node to the Cloud.

When connecting node to the Cloud, you can set the 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).

Grouped nodes

To connect the node to the Cloud, use a Wallarm token of the appropriate type:

  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.

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

    sudo /usr/share/wallarm-common/register-node -t <TOKEN> --labels 'group=<GROUP>'
    • <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).
  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.

  3. Run the register-node script on a machine where you install the filtering node:

    sudo /usr/share/wallarm-common/register-node -t <TOKEN> -H us1.api.wallarm.com

    sudo /usr/share/wallarm-common/register-node -t <TOKEN>
  • <TOKEN> is the copied value of the node token.
  • You may add -n <HOST_NAME> parameter to set a custom name for your node instance. Final instance name will be: HOST_NAME_NodeUUID.

6. Enable Wallarm to analyze the 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 /etc/nginx/sites-enabled/default file on the Wallarm instance:

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

7. Restart NGINX

To apply the settings, restart NGINX on the Wallarm instance:

sudo systemctl restart nginx

Each configuration file change requires NGINX to be restarted to apply it.

8. Configure sending traffic to the Wallarm instance

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

9. Test the Wallarm operation

  1. The request with test Path Traversal attack to an address of either the load balancer or the machine with the Wallarm node:

    curl http://<ADDRESS>/etc/passwd

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

Since Wallarm operates in the monitoring mode, the Wallarm node does not block the attack but registers it.

10. Fine-tune the deployed solution

The deployment is now complete. 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 Wallarm instance:

  • /etc/nginx/sites-enabled/default defines the configuration of NGINX

  • /etc/nginx/conf.d/wallarm.conf defines the global configuration of Wallarm filtering node

  • /etc/nginx/conf.d/wallarm-status.conf defines the filtering node monitoring service configuration

  • /etc/default/wallarm-tarantool or /etc/sysconfig/wallarm-tarantool with the Tarantool database settings

You can modify the listed files or 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 (e.g. example.com.conf). To see detailed information about working with NGINX configuration files, proceed to the official NGINX documentation.

Creating a configuration file

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

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