Installing with Kong

Prerequisites

Kong must meet the following criteria:

  • Must be installed from packages
  • Must be installed on one of the following operating systems:
    • Debian 8.x (jessie)
    • Debian 9.x (stretch)
    • Ubuntu 14.04 LTS (trusty)
    • Ubuntu 16.04 LTS (xenial)
    • Ubuntu 18.04 LTS (bionic)
    • CentOS 6.x
    • CentOS 7.x

Known Limitations

Installation

Installation of postanalytics on a separate server

If you are planning to install postanalytics on a separate server, you must install postanalytics first. See details in Separate postanalytics installation.

To install the Wallarm module with Kong, you need to:

  1. Add Wallarm repositories.
  2. Install Wallarm packages.
  3. Configure postanalytics.
  4. Set up the filter node for using a proxy server.
  5. Connect the filter node to the Wallarm cloud.
  6. Configure the postanalytics server addresses.
  7. Configure the filtration mode.

Prerequisites

Make sure that you execute all commands below as superuser (e.g. root).

1. Add Wallarm Repositories

The filter node installs and updates from the Wallarm repositories.

Depending on your operating system, run one of the following commands:

Debian 8.x (jessie)
Debian 9.x (stretch)
Ubuntu 14.04 LTS (trusty)
Ubuntu 16.04 LTS (xenial)
Ubuntu 18.04 LTS (bionic)
CentOS 6.x
CentOS 7.x
# apt-key adv --keyserver keys.gnupg.net --recv-keys 72B865FD
# echo 'deb http://repo.wallarm.com/debian/wallarm-node jessie/' >/etc/apt/sources.list.d/wallarm.list
# apt-get update
# apt-get install dirmngr
# apt-key adv --keyserver keys.gnupg.net --recv-keys 72B865FD
# sh -c "echo 'deb http://repo.wallarm.com/debian/wallarm-node stretch/' >/etc/apt/sources.list.d/wallarm.list"
# apt-get update
# apt-key adv --keyserver keys.gnupg.net --recv-keys 72B865FD
# echo 'deb http://repo.wallarm.com/ubuntu/wallarm-node trusty/' >/etc/apt/sources.list.d/wallarm.list
# apt-get update
# apt-key adv --keyserver keys.gnupg.net --recv-keys 72B865FD
# echo 'deb http://repo.wallarm.com/ubuntu/wallarm-node xenial/' >/etc/apt/sources.list.d/wallarm.list
# apt-get update
# apt-key adv --keyserver keys.gnupg.net --recv-keys 72B865FD
# sh -c "echo 'deb http://repo.wallarm.com/ubuntu/wallarm-node bionic/' >/etc/apt/sources.list.d/wallarm.list"
# apt-get update
# yum install --enablerepo=extras -y epel-release centos-release-SCL
# rpm -i https://repo.wallarm.com/centos/wallarm-node/6/x86_64/Packages/wallarm-node-repo-1-2.el6.noarch.rpm
# yum install -y epel-release
# rpm -i https://repo.wallarm.com/centos/wallarm-node/7/x86_64/Packages/wallarm-node-repo-1-2.el7.centos.noarch.rpm

Repository access

Your system must have access to https://repo.wallarm.com to download the packages. Ensure the access is not blocked by a firewall.

2. Install Wallarm Packages

To install the filter node and postanalytics on the same server, run the command:

Debian 8.x (jessie)
Debian 9.x (stretch)
Ubuntu 14.04 LTS (trusty)
Ubuntu 16.04 LTS (xenial)
Ubuntu 18.04 LTS (bionic)
CentOS 6.x
CentOS 7.x
# apt-get install --no-install-recommends wallarm-node kong-module-wallarm
# apt-get install --no-install-recommends wallarm-node kong-module-wallarm
# apt-get install --no-install-recommends wallarm-node kong-module-wallarm
# apt-get install --no-install-recommends wallarm-node kong-module-wallarm
# apt-get install --no-install-recommends wallarm-node kong-module-wallarm
# yum install wallarm-node kong-module-wallarm
# yum install wallarm-node kong-module-wallarm
To install the filter node alone, run the command:

Debian 8.x (jessie)
Debian 9.x (stretch)
Ubuntu 14.04 LTS (trusty)
Ubuntu 16.04 LTS (xenial)
Ubuntu 18.04 LTS (bionic)
CentOS 6.x
CentOS 7.x
# apt-get install --no-install-recommends wallarm-node-nginx kong-module-wallarm
# apt-get install --no-install-recommends wallarm-node-nginx kong-module-wallarm
# apt-get install --no-install-recommends wallarm-node-nginx kong-module-wallarm
# apt-get install --no-install-recommends wallarm-node-nginx kong-module-wallarm
# apt-get install --no-install-recommends wallarm-node-nginx kong-module-wallarm
# yum install wallarm-node-nginx kong-module-wallarm
# yum install wallarm-node-nginx kong-module-wallarm

3. Configure Postanalytics

Skip this step if you installed postanalytics on a separate server as you already have your postanalytics configured.

The amount of memory determines the quality of work of the statistical algorithms. The recommended value is 75% of the total server memory. For example, if the server has 32 GB of memory, the recommended allocation size is 24 GB.

Allocate the operating memory size for Tarantool:

Open for editing the configuration file of Tarantool:

Debian 8.x (jessie)
Debian 9.x (stretch)
Ubuntu 14.04 LTS (trusty)
Ubuntu 16.04 LTS (xenial)
Ubuntu 18.04 LTS (bionic)
CentOS 6.x
CentOS 7.x
# vi /etc/default/wallarm-tarantool
# vi /etc/default/wallarm-tarantool
# vi /etc/default/wallarm-tarantool
# vi /etc/default/wallarm-tarantool
# vi /etc/default/wallarm-tarantool
# vi /etc/sysconfig/wallarm-tarantool
# vi /etc/sysconfig/wallarm-tarantool

Set the allocated memory size in the configuration file of Tarantool via the SLAB_ALLOC_ARENA directive.

For example:

SLAB_ALLOC_ARENA=24

Restart Tarantool:

Debian 8.x (jessie)
Debian 9.x (stretch)
Ubuntu 14.04 LTS (trusty)
Ubuntu 16.04 LTS (xenial)
Ubuntu 18.04 LTS (bionic)
CentOS 6.x
CentOS 7.x
# systemctl restart wallarm-tarantool
# systemctl restart wallarm-tarantool
# service wallarm-tarantool restart
# service wallarm-tarantool restart
# service wallarm-tarantool restart
# service wallarm-tarantool restart
# systemctl restart wallarm-tarantool

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 new values of the environment variables to the /etc/environment file:

  • Add https_proxy to define a proxy for the https protocol.
  • Add http_proxy to define a proxy for the http protocol.
  • Add 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.
https_proxy=http://admin:01234@1.2.3.4:1234
http_proxy=http://admin:01234@1.2.3.4:1234
no_proxy="127.0.0.1, 127.0.0.8, 127.0.0.9, localhost"

5. Connect the Filter Node to the Wallarm Cloud

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.

The filter node interacts with the Wallarm cloud.

To connect the node to the cloud using your cloud account requisites, proceed with the following steps:

  1. Make sure that your Wallarm account has the Administrator role enabled and two-factor authentication disabled, therefore allowing you to connect a filter node to the cloud.

    You can check the aforementioned parameters by navigating to the user account list in the Wallarm console.

    User list in Wallarm console

  2. On the virtual machine run the addnode script:

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

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

  3. Provide your Wallarm account’s login and password when prompted.

    6. Configure the Postanalytics Server Addresses

  • Skip this step if you installed postanalytics and the filter node on the same server.
  • Do this step if you installed postanalytics and the filter node on separate servers.

Add the server address of postanalytics to /etc/kong/nginx-wallarm.template:


     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;
    }

    ...

    wallarm_tarantool_upstream wallarm_tarantool;

Required conditions

It is required that the following conditions are satisfied for the max_conns and the keepalive parameters:

  • The value of the keepalive parameter must not be lower than the number of the tarantool servers.
  • The value of the max_conns parameter must be specified for each of the upstream Tarantool servers to prevent the creation of excessive connections.

7. Set up the Filtration Mode

The filtering and proxying rules are configured in the /etc/kong/nginx-wallarm.template file.

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.

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;
      }
    }

Start Kong

To start Kong with the installed Wallarm module, run the command:

# kong start --nginx-conf /etc/kong/nginx-wallarm.template

The Installation Is Complete

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

Additional Settings

The filter node may require some additional configuration after installation.

The document below lists a few of the typical setups that you can apply if needed.

To get more information about other available settings, proceed to the “Configuration” section of the Administrator’s Guide.

Configuring the Display of the Client's Real IP

If the filter node is deployed behind a proxy server or load balancer without any additional configuration, the request source address may not be equal to the actual IP address of the client. Instead, it may be equal to one of the IP addresses of the proxy server or the load balancer.

In this case, if you want the filter node to receive the client's IP address as a request source address, you need to perform an additional configuration of the proxy server or the load balancer.

Configuring Extended Logging

You can configure the filter node variables logging using NGINX which will allow much faster filter node diagnostics with the help of the NGINX log file.

Adding Wallarm Scanner Addresses to the Whitelist

The Wallarm scanner checks the resources of your company for vulnerabilities. Scanning is conducted using IP addresses from one of the following lists (depending on the type of Wallarm Cloud you are using):

If you are using the Wallarm scanner, you need to configure the whitelists on your network scope security software (such as firewalls, intrusion detection systems, etc.) to contain Wallarm scanner IP addresses.

Limiting the Single Request Processing Time

Use the wallarm_process_time_limit Wallarm directive to specify the limit of the duration for processing a single request by the filter node.

If processing the request consumes more time than specified in the directive, then the information on the error is entered into the log file and the request is marked as an overlimit_res attack.

Limiting the Server Reply Waiting Time

Use the proxy_read_timeout NGINX directive to specify the timeout for reading the proxy server reply.

If the server sends nothing during this time, the connection is closed.

Limiting the Maximum Request Size

Use the client_max_body_size NGINX directive to specify the limit for the maximum size of the body of the client's request.

If this limit is exceeded, NGINX replies to the client with the 413 (Payload Too Large) code, also known as the Request Entity Too Large message.

results matching ""

    No results matching ""