A guide to installing, configuring and operating the Nemesida WAF dynamic module for Nginx and the Nemesida AI MLA machine learning agent, designed to detect and block anomalies using signature analysis and behavioral models.

Installation
Before installing Nemesida WAF components, add repository information to the system:

DebianUbuntuCentOSDockerVirtual Appliance
# apt install apt-transport-https gnupg2
Debian 9
# echo "deb https://nemesida-security.com/repo/nw/debian stretch non-free" > /etc/apt/sources.list.d/NemesidaWAF.list
Debian 10
# echo "deb https://nemesida-security.com/repo/nw/debian buster non-free" > /etc/apt/sources.list.d/NemesidaWAF.list
Debian 11
# echo "deb https://nemesida-security.com/repo/nw/debian bullseye non-free" > /etc/apt/sources.list.d/NemesidaWAF.list
# wget -O- https://nemesida-security.com/repo/nw/gpg.key | apt-key add -
# apt update && apt upgrade
# apt install apt-transport-https gnupg2
Ubuntu 18.04
# echo "deb [arch=amd64] https://nemesida-security.com/repo/nw/ubuntu bionic non-free" > /etc/apt/sources.list.d/NemesidaWAF.list
# wget -O- https://nemesida-security.com/repo/nw/gpg.key | apt-key add -
# apt update && apt upgrade
Ubuntu 20.04
# echo "deb [arch=amd64] https://nemesida-security.com/repo/nw/ubuntu focal non-free" > /etc/apt/sources.list.d/NemesidaWAF.list
# wget -O- https://nemesida-security.com/repo/nw/gpg.key | apt-key add -
# apt update && apt upgrade
Ubuntu 22.04
# echo "deb [arch=amd64] https://nemesida-security.com/repo/nw/ubuntu jammy non-free" > /etc/apt/sources.list.d/NemesidaWAF.list
# curl -s https://nemesida-security.com/repo/nw/gpg.key | gpg --no-default-keyring --keyring gnupg-ring:/etc/apt/trusted.gpg.d/trusted.gpg --import
# chmod 644 /etc/apt/trusted.gpg.d/trusted.gpg 
# apt update && apt upgrade
CentOS 7
# rpm -Uvh https://nemesida-security.com/repo/nw/centos/nwaf-release-centos-7-1-6.noarch.rpm
# yum update
# yum install epel-release
CentOS 8 Stream
# rpm -Uvh https://nemesida-security.com/repo/nw/centos/nwaf-release-centos-8-1-6.noarch.rpm
# dnf update
# dnf install epel-release
CentOS 9 Stream
# rpm -Uvh https://nemesida-security.com/repo/nw/centos/nwaf-release-centos-9-1-6.noarch.rpm
# dnf update
# dnf install epel-release
Information about using Nemesida WAF in a Docker container is available in corresponding section.
Information about using Nemesida WAF as a Virtual Appliance (virtual disk for KVM/VMware/VirtualBox) and Yandex VM is available in corresponding section.

The dynamic module Nemesida WAF is available for:

  • Nginx stable from 1.12;
  • Nginx mainline from 1.15;
  • Nginx Plus from R16.

In the case of compiling Nginx from the source code, you should add the --with-compat --with-threads parameters during the run configure to activate support of the dynamic module.

Installation

DebianUbuntuCentOSDockerVirtual Appliance

Set the operating system ID:

# rm -f /etc/machine-id
# /bin/systemd-machine-id-setup
Debian 9
Add the Nginx repositories:

# echo "deb http://nginx.org/packages/debian/ stretch nginx" > /etc/apt/sources.list.d/nginx.list
# wget -O- https://nginx.org/packages/keys/nginx_signing.key | apt-key add -

Install the packages:

# apt update && apt upgrade
# apt install nginx python3 python3-venv python3-pip python3-dev python3-setuptools librabbitmq4 libcurl3-gnutls libcurl4-openssl-dev libc6-dev gcc rabbitmq-server libmaxminddb0 g++ memcached
Debian 10
Add the Nginx repositories:

# echo "deb http://nginx.org/packages/debian/ buster nginx" > /etc/apt/sources.list.d/nginx.list
# wget -O- https://nginx.org/packages/keys/nginx_signing.key | apt-key add -

Install the packages:

# apt update && apt upgrade
# apt install nginx python3 python3-venv python3-pip python3-dev python3-setuptools librabbitmq4 libcurl3-gnutls libcurl4-openssl-dev libc6-dev gcc rabbitmq-server libmaxminddb0 g++ memcached
Debian 11
Add the Nginx repositories:

# echo "deb http://nginx.org/packages/debian/ bullseye nginx" > /etc/apt/sources.list.d/nginx.list
# wget -O- https://nginx.org/packages/keys/nginx_signing.key | apt-key add -

Install the packages:

# apt update && apt upgrade
# apt install nginx python3 python3-venv python3-pip python3-dev python3-setuptools librabbitmq4 libcurl3-gnutls libcurl4-openssl-dev libc6-dev gcc rabbitmq-server libmaxminddb0 g++ memcached
# apt install nwaf-dyn-1.18

where 1.18 is the version of the installed Nginx. For example, package of the dynamic module nwaf-dyn-1.12 is intended for work with Nginx version 1.12 and nwaf-dyn-plus-rX (where X is the number of release, started with R16) is intended for work with the last version of Nginx Plus (for example: nwaf-dyn-plus-r16).

Set the operating system ID:

# rm -f /etc/machine-id
# /bin/systemd-machine-id-setup
Ubuntu 18.04
Add the Nginx repositories:

# echo "deb http://nginx.org/packages/ubuntu/ bionic nginx" > /etc/apt/sources.list.d/nginx.list
# wget -O- https://nginx.org/packages/keys/nginx_signing.key | apt-key add -

Install the packages:

# apt update && apt upgrade
# apt install nginx python3 python3-venv python3-pip python3-dev python3-setuptools librabbitmq4 libcurl3-gnutls libcurl4-openssl-dev libc6-dev gcc rabbitmq-server libmaxminddb0 g++ memcached
Ubuntu 20.04
Add the Nginx repositories:

# echo "deb http://nginx.org/packages/ubuntu/ focal nginx"> /etc/apt/sources.list.d/nginx.list
# wget -O- https://nginx.org/packages/keys/nginx_signing.key | apt-key add -

Install the packages:

# apt update && apt upgrade
# apt install nginx python3 python3-venv python3-pip python3-dev python3-setuptools libcurl3-gnutls librabbitmq4 libcurl4-openssl-dev libc6-dev gcc rabbitmq-server libmaxminddb0 g++ memcached
Ubuntu 22.04
Подключите репозиторий Nginx:

# echo "deb http://nginx.org/packages/ubuntu/ jammy nginx" > /etc/apt/sources.list.d/nginx.list
# curl -s https://nginx.org/packages/keys/nginx_signing.key | gpg --no-default-keyring --keyring gnupg-ring:/etc/apt/trusted.gpg.d/trusted.gpg --import
# chmod 644 /etc/apt/trusted.gpg.d/trusted.gpg 

Установите пакеты:

# apt update && apt upgrade
# apt install nginx python3 python3-venv python3-pip python3-dev python3-setuptools libcurl3-gnutls librabbitmq4 libcurl4-openssl-dev libc6-dev gcc rabbitmq-server libmaxminddb0 g++ memcached
# apt install nwaf-dyn-1.18

where 1.18 is the version of the installed Nginx. For example, package of the dynamic module nwaf-dyn-1.12 is intended for work with Nginx version 1.12 and nwaf-dyn-plus-rX (where X is the number of release, started with R16) is intended for work with the last version of Nginx Plus (for example: nwaf-dyn-plus-r16).

Set the operating system ID:

# rm -f /etc/machine-id
# /bin/systemd-machine-id-setup

Configure the SELinux policy or deactivate it with the command:

# setenforce 0

then bring the file /etc/selinux/config to the form:

# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
#     enforcing - SELinux security policy is enforced.
#     permissive - SELinux prints warnings instead of enforcing.
#     disabled - No SELinux policy is loaded.
SELINUX=disabled
# SELINUXTYPE= can take one of three two values:
#     targeted - Targeted processes are protected,
#     minimum - Modification of targeted policy. Only selected processes are protected.
#     mls - Multi Level Security protection.
SELINUXTYPE=targeted
CentOS 7
Enable direct connection to nemesida-security.com:443.

Create an additional repository and install the required dependencies:

# rpm -Uvh https://nemesida-security.com/repo/nw/centos/nwaf-release-centos-7-1-6.noarch.rpm
# yum update
# yum install epel-release

Add the Nginx repository:

# rpm -Uvh https://nginx.org/packages/centos/7/noarch/RPMS/nginx-release-centos-7-0.el7.ngx.noarch.rpm

Install the packages:

# yum update
# yum install nginx python36 python36-devel python36-setuptools python36-pip openssl librabbitmq libcurl-devel rabbitmq-server gcc libmaxminddb memcached
# yum install nwaf-dyn-1.18

where 1.18 is the version of the installed Nginx. For example, package of the dynamic module nwaf-dyn-1.12 is intended for work with Nginx version 1.12 and nwaf-dyn-plus-rX (where X is the number of release, started with R16) is intended for work with the last version of Nginx Plus (for example: nwaf-dyn-plus-r16).

CentOS 8 Stream
Install the packages:

# dnf install dnf-utils

Add the RabbitMQ repositories by bringing the file /etc/yum.repos.d/RabbitMQ.rep to the form:

[rabbitmq_erlang]
name = rabbitmq_erlang
baseurl = https://packagecloud.io/rabbitmq/erlang/el/8/$basearch
repo_gpgcheck = 0
gpgcheck = 0
enabled = 1

[rabbitmq_server]
name = rabbitmq_server
baseurl = https://packagecloud.io/rabbitmq/rabbitmq-server/el/8/$basearch
repo_gpgcheck = 0
gpgcheck = 0
enabled = 1

Install the packages:

# dnf update
# dnf install rabbitmq-server

Check the correctness of the service:

# systemctl enable rabbitmq-server
# service rabbitmq-server restart
# service rabbitmq-server status

Add the Nginx repository by bringing the file /etc/yum.repos.d/nginx.repo to the form:

[nginx-stable]
name=nginx stable repo
baseurl=http://nginx.org/packages/centos/$releasever/$basearch/
gpgcheck=1
enabled=1
gpgkey=https://nginx.org/keys/nginx_signing.key
module_hotfixes=true

Install the packages:

# dnf update
# dnf install nginx python39 python39-devel python39-setuptools python39-pip openssl librabbitmq libcurl-devel gcc libmaxminddb memcached
# dnf install nwaf-dyn-1.18

where 1.18 is the version of the installed Nginx. For example, package of the dynamic module nwaf-dyn-1.12 is intended for work with Nginx version 1.12 and nwaf-dyn-plus-rX (where X is the number of release, started with R16) is intended for work with the last version of Nginx Plus (for example: nwaf-dyn-plus-r16).

CentOS 9 Stream
Install the packages:

# dnf install dnf-utils
# dnf install centos-release-rabbitmq-38
# dnf install rabbitmq-server

Check the correctness of the service:

# systemctl enable rabbitmq-server
# service rabbitmq-server restart
# service rabbitmq-server status

Add the Nginx repository by bringing the file /etc/yum.repos.d/nginx.repo to the form:

[nginx-stable]
name=nginx stable repo
baseurl=http://nginx.org/packages/centos/$releasever/$basearch/
gpgcheck=1
enabled=1
gpgkey=https://nginx.org/keys/nginx_signing.key
module_hotfixes=true

Install the packages:

# dnf update
# dnf install nginx python3 python3-devel python3-setuptools python3-pip openssl librabbitmq libcurl-devel gcc libmaxminddb memcached
# dnf install nwaf-dyn-1.18

where 1.18 is the version of the installed Nginx. For example, package of the dynamic module nwaf-dyn-1.12 is intended for work with Nginx version 1.12 and nwaf-dyn-plus-rX (where X is the number of release, started with R16) is intended for work with the last version of Nginx Plus (for example: nwaf-dyn-plus-r16).

Information about using Nemesida WAF in a Docker container is available in the corresponding section.
Information about using Nemesida WAF as a Virtual Appliance (virtual disk for KVM/VMware/VirtualBox) and Yandex VM is available in the corresponding section.

Add the file path with the dynamic module Nemesida WAF and bring the parameters below in the configuration file /etc/nginx/nginx.conf to the form:

load_module /etc/nginx/modules/ngx_http_waf_module.so;
...
worker_processes auto;
...
http {
...
    ##
    # Nemesida WAF
    ##

    ## Request body is too large fix
    client_body_buffer_size 25M;

    include /etc/nginx/nwaf/conf/global/*.conf;
...
}

Errors:

nginx: [emerg] module "/etc/nginx/modules/ngx_http_waf_module.so" version 1017010 instead of 1018000 in /etc/nginx/nginx.conf:1

The error occurs when the versions of the installed dynamic module Nemesida WAF and Nginx do not match. In this case, 1017010 is the version of Nginx 1.17.10, for which the nwaf-dyn module was compiled, and 1018000 is Nginx 1.18.0 installed on the server. The dynamic module package nwaf-dyn-1.18 is designed to work with Nginx version 1.18, and nwaf-dyn-plus-r22 is designed to work with NGINX Plus R22.

For the nwaf/conf/db directory, write/read permission must be granted for the user on whose behalf Nginx is running.

Initial setup

After installing the module, it is necessary to make the initial configuration by specifying the following parameters:

Parameters of nwaf.conf and mla.conf
Default parameter
Description of the parameter

[Nemesida WAF]
The section responsible for the general settings of the Nemesida WAF dynamic module. To configure the module, make the necessary changes to the main configuration file /etc/nginx/nwaf/conf/global/nwaf.conf.
nwaf_license_key

The parameter for installing the Nemesida WAF license key. The key is also used by the Nemesida AI module if the module is hosted on the same server. It is prohibited to use the same license key on two or more instances of the component nwaf-dyn.

With the specified invalid license key (including the default value nwaf_license_key none), Nemesida WAF will continue to work with the functionality Nemesida WAF Free.

nwaf_sys_proxy
The parameter defines the proxy server address for accessing nw-auth-extra.nemesida-security.com:443 (license key verification) and nemesida-security.com:443 (getting signatures, loading a list of virtual hosts and loading behavioral models).

Example:

nwaf_sys_proxy http://proxy.example.com:3128;

For CentOS 7, it is allowed to use a proxy server only according to the HTTP scheme.

nwaf_api_proxy
The parameter defines the proxy server address for accessing the Nemesida WAF API and Nemesida WAF Signtest.

Example:

nwaf_api_proxy http://proxy.example.com:3128;

For CentOS 7, it is allowed to use a proxy server only according to the HTTP scheme.

nwaf_api_conf

The address of the Nemesida WAF API server for sending information about detected anomalies.

host – the parameter defines the address of the Nemesida WAF API server for sending information about attacks, the results of the Nemesida WAF Scanner and Nemesida AI. With the host=none option, data will not be transmitted to the Nemesida WAF API.


[Nemesida AI MLA]
The section responsible for the general settings of the Nemesida AI MLA module. To configure the module, make the necessary changes to the main configuration file /etc/nginx/nwaf/mla.conf.
st_enable
Sending disputed requests to the Nemesida WAF Signtest server for subsequent processing.

Disputed requests are defined as follows:
– if the signature analysis determined the request as illegitimate, and the Nemesida AI MLA module determined it as legitimate;
– if the signature analysis determined the request as legitimate, and the Nemesida AI MLA module determined it as illegitimate.

st_uri
Nemesida WAF Signtest server address for processing Nemesida AI results.

If the Nemesida WAF API and Nemesida WAF Signtest modules are not configured yet, the parameters nwaf_api_conf, nwaf_api_proxy, st_enable and st_uri can be specified later.

After making changes, restart the server or restart the services and check their operation:

# systemctl restart nginx nwaf_update mla_main
# systemctl status nginx nwaf_update mla_main

The nwaf_update service is responsible for obtaining the signatures of the Nemesida WAF module (/etc/nginx/nwaf/rules.bin). To test the signature method of detecting attacks, when sending a request to http://YOUR_SERVER/nwaftest, the server must return a 403 response code.

The Nemesida WAF module processes only the request transmitted to the final application. If the settings of the Nginx software prevent the transmission of calls (returning, for example, a 301 or 403 response code), such requests will not be processed by the Nemesida WAF module.

If the signature set would be changed on the server nemesida-security.com nwaf_update service will automatically update rules.bin file and apply the changes. If the nwaf_update service is deactivated during the signature set updating on the server, the download of the new version of signature set will be after the service nwaf_update starts.

Сonfiguring

The settings management functionality is enabled by default, but it can be disabled by sending a request to email.

To avoid errors when configuring the module, we recommend using a cloud web application.

Manage settings using a cloud WebApp and a cloud API

Information about configuring a dynamic module using a cloud WebApp and a cloud API is available in the relevant sections.

Managing settings using configuration files

Nemesida WAF dynamic module

The main Nemesida WAF configuration file is available at /etc/nginx/nwaf/conf/global/nwaf.conf. The file /etc/nginx/nwaf/conf/global/nwaf-example.conf contains a complete list of available parameters.

nwaf.conf parameters
Default setting
Description of the parameter
nwaf_license_key

The installation parameter of the license key software Nemesida WAF. The key is also used by the Nemesida AI module, if it is located on the same server. The using one license key on two or more examples of nwaf-dyn is prohibited.

With the nwaf_license_key = none parameter or incorrect product key the Nemesida WAF will continue working in Nemesida WAF Free mode.

nwaf_sys_proxy
This parameter defines the proxy server address for accessing nw-auth-extra.nemesida-security.com:443 (license key verification) and nemesida-security.com:443 (getting signatures, loading a list of virtual hosts and loading behavioral models).

Example:

nwaf_sys_proxy http://proxy.example.com:3128;

For distribution CentOS 7, it is allowed to use a proxy server only from the HTTP scheme.

nwaf_api_proxy
This parameter defines the proxy server address for accessing the Nemesida WAF API and Nemesida WAF Signtest.

Example:

nwaf_api_proxy http://proxy.example.com:3128;

For distribution CentOS 7, it is allowed to use a proxy server only from the HTTP scheme.

nwaf_api_conf

Set up interaction with the Nemesida WAF API and other related parameters.

host – is parameter defines the address of the Nemesida WAF API server for sending information about attacks, the results of the Nemesida WAF Scanner and Nemesida AI. With the host=none option, data will not be transmitted to the Nemesida WAF API.

nwaf_host_enable

The parameter that activates the Nemesida WAF functionality for the listed virtual hosts. With the nwaf_host_enable *; parameter, analysis will be performed for all virtual hosts.

Example for use single value:

nwaf_host_enable *;
nwaf_host_enable example.com;
nwaf_host_enable *.example.com;

Example for use many values:

nwaf_host_enable example.com, 1.example.com;
nwaf_host_enable example.com, *.example.com;
nwaf_limit

Setting the limit of blocked requests. If the allowed number of requests specified by the rate option is exceeded, the IP address will be blocked for the time (in seconds) specified in block_time.

Example:

nwaf_limit rate=5r/m block_time=600;

To set the limit of blocked requests for a specific domain, you need to make the parameter look like: nwaf_limit rate=... block_time=... domain=...;

Example:

nwaf_limit rate=5r/m block_time=600 domain=example.com;

For the domain parameter it is allowed to use a wildcard value.

nwaf_ban_captcha_host*

A parameter that activates the mechanism for unlocking an IP address for virtual hosts using captcha for requests detected by the Nemesida AI MLC module as BT 7, BT 9 or BT 10. It is allowed to use a wildcard value.

Example:

nwaf_ban_captcha_host *;
nwaf_ban_captcha_host example.com;
nwaf_ban_captcha_host *.example.com;

More detailed information about the functionality is available in in the corresponding section.

nwaf_ban_captcha_path*
nwaf_ban_captcha_url*

A parameter that determines the location of the captcha page.

Example:

nwaf_ban_captcha_path /captcha_path;

For specify the URL of an arbitrary page with captcha on the Internet, use the nwaf_ban_captcha_url parameter.

Example:

nwaf_ban_captcha_url http://example.com/captcha_path;

The parameter takes precedence over nwaf_ban_captcha_path when used at the same time.

For the correct work of unlocking mechanism, you must activate the nwaf_captcha_unban parameter for a specific URL. Using one instance of Nemesida WAF to protect both the web application and the captcha page will lead to incorrect operation of the unlocking mechanism.

nwaf_ban_captcha_token*

A secret token that is used by the mechanism for removing an IP address from the blocked list when using a captcha.

An arbitrary sequence of characters is accepted as the parameter value.

Example:

nwaf_ban_captcha_token 01b307acba4f54f55aafc33bb06bbbf6ca803e9a;

After applying the parameter, it must also be specified in a web application with a captcha.

nwaf_sync_ban_ip_key*

Setting a secret key for syncing blocked IP addresses, which must be identical on all synced instances of Nemesida WAF.

Example:

nwaf_sync_ban_ip_key 1234567890abcdef;
nwaf_sync_ban_ip_host*

The parameter defines the URL for getting the list of blocked IP addresses and the period of its polling. The polling period must be identical on all synchronized Nemesida WAF instances.

Example:

nwaf_sync_ban_ip_host srv1.example.com/ban_ip_sync_path 15;
nwaf_sync_ban_ip_host srv2.example.com/ban_ip_sync_path 15;

After completing the settings, you need to determine the path with the set parameter nwaf_ban_ip_sync on; in the virtual host file in the location section to get a list of blocked addresses, for example:

location /ban_ip_sync_path {
         ...
         nwaf_ban_ip_sync on;
         ...
}

For security reasons, it is recommended to restrict access to URLs with the set parameter nwaf_ban_ip_sync on; to a list of allowed IP addresses.

For IP addresses with a residual blocking time of less than 60 seconds, synchronization is not performed.

nwaf_mla*

Settings of interaction with the Nemesida AI MLA module, where mla_score is the threshold option, upon reaching which the decision to block the request is transmitted to the Nemesida AI MLA module.

Signatures with threshold value is 12 are blocked without sending in Nemesida AI MLA module.

For the commercial version of Nemesida WAF, the parameter is required to control Nginx operation using the Nemesida WAF dynamic module.

nwaf_mla_host_lm*

The parameter activates LM (IDS) mode for the requests, which were detected as illegitimate by Nemesida AI MLA module.

If the name of the virtual host from the request falls under the parameter, the request is fixed in the database management system, but it is not blocked.

Example for use single value:

nwaf_mla_host_lm *;
nwaf_mla_host_lm example.com;
nwaf_mla_host_lm *.example.com;

Example for use many values:

nwaf_mla_host_lm example.com, 1.example.com;
nwaf_mla_host_lm example.com, *.example.com;
nwaf_rmq_host_exclude*

The parameter which excludes some requests sending to the RabbitMQ server (nwaf queue).

If the vitual host name from the request falls within the scope of the parameter, the request is not sent to nwaf queue and is not processed by Nemesida AI MLC module (is not analyzed on anomalies and brute force attacks, does not take part in behavioral models building).

Example for use single value:

nwaf_rmq_host_exclude *;
nwaf_rmq_host_exclude example.com;
nwaf_rmq_host_exclude *.example.com;

Example for use many values:

nwaf_rmq_host_exclude example.com 1.example.com;
nwaf_rmq_host_exclude example.com *.example.com;
nwaf_ai_extra_host_lm*

The parameter activates LM (IDS) mode for the requests, which were detected as illegitimate by Nemesida AI MLC module. If the virtual host name from the request falls within the scope of the parameter, the request is fixed in the DBMS, but is not blocked.

Example for use single value:

nwaf_ai_extra_host_lm *;
nwaf_ai_extra_host_lm example.com;
nwaf_ai_extra_host_lm *.example.com;

Example for use many values:

nwaf_ai_extra_host_lm example.com, 1.example.com;
nwaf_ai_extra_host_lm example.com, *.example.com;
nwaf_ai_extra_host_wl*

The parameter activates WL mode for the requests, that were detected by Nemesida AI MLC module as illegitimate. If the virtual host name from the request falls within the scope of the parameter, the request is not fixed in the DBMS and is not blocked.

Example for use single value:

nwaf_ai_extra_host_wl *;
nwaf_ai_extra_host_wl example.com;
nwaf_ai_extra_host_wl *.example.com;

Example for use many values:

nwaf_ai_extra_host_wl example.com, 1.example.com;
nwaf_ai_extra_host_wl example.com, *.example.com;
nwaf_bf_detect_host_lm*

The parameter activates LM mode for the requests, that were detected by Nemesida AI MLC module as brute force attacks (BT 7).

If the virtual host name from the request falls under the parameter, the request is fixed in the DBMS, but it is not blocked.

Example for use single value:

nwaf_bf_detect_host_lm *;
nwaf_bf_detect_host_lm .example.com;
nwaf_bf_detect_host_lm *.example.com;

Example for use many values:

nwaf_bf_detect_host_lm example.com, example.org;
nwaf_ddos_detect_host_lm*

The parameter activates LM mode for the requests, that were detected by Nemesida AI MLC module as DDoS attacks (BT 10).

If the virtual host name from the request falls under the parameter, the request is fixed in the DBMS, but it is not blocked.

Example for use single value:

nwaf_ddos_detect_host_lm *;
nwaf_ddos_detect_host_lm .example.com;
nwaf_ddos_detect_host_lm *.example.com;

Example for use many values:

nwaf_ddos_detect_host_lm example.com, example.org;
nwaf_rmq

Configuring the interaction subsystem with RabbitMQ software. Received by the Nemesida WAF dynamic module requests is sent for storage to the local RabbitMQ service, from where it is collected for subsequent processing by the Nemesida AI MLC module. The process of receiving data by the Nemesida AI MLC module is recommended to be performed using a secure connection.

To do this, make changes to the configuration file nginx.conf or rabbitmq.conf on each VM with the dynamic module installed.

Configuration example for nginx.conf:

...
stream {
        server {
                listen 5673 ssl;
                proxy_pass 127.0.0.1:5672;
                ssl_certificate /etc/nginx/SSL/crt/example.ru.crt;
                ssl_certificate_key /etc/nginx/SSL/private/example.ru.key;
       }
}
...

listen 5673 ssl; is the port that will be used for secure connection.

For security reasons, it is recommended to allow access to servers only from the IP addresses where the Nemesida AI MLC module is installed, and certificates used for secure connection must be trusted for them.

nwaf_clamav*

Activation of the mechanism for sending the body of POST and PUT requests to the ClamAV module.

For analyzing only file content from the request body with Content-Type: multipart/form-data, use the FILE_ONLY option.

The file content of the PUT request body is transferred regardless of the FILE_ONLY value.

nwaf_clamav_wl*

Configuring the blocking exclusion list for the contents of the request body or downloadable file by the MD5 amount (the MD5 amount is contained in the error.log of the Nginx software).

Example of a log entry:

Nemesida WAF: blocked by ClamAV, stream: Eicar-Test-Signature FOUND, md5: 44d88612fea8a8f36de82e1278a-bb02f, ...

Example of WL rule:

nwaf_clamav_wl 44d88612fea8a8f36de82e1278a-bb02f
nwaf_ip_wl

Deactivation of the request analysis mechanism by means of the Nemesida WAF software for a specific IP address or subnet.

Example:

nwaf_ip_wl x.x.x.x;

With the parameter nwaf_ip_wl x.x.x.x domain=example.com; the analysis mechanism will be deactivated only when accessing a specific IP address to a specific virtual host.
For the domain option it is allowed to use a wildcard value.
As an IP address it is possible to use address with subnet mask (for example, 192.168.0.0/24) or subnet range (for example, 192.168.0.1-192.168.255.255).

To reduce false positives, it is recommended to specify the static IP address of specialized users (administrators, content managers, editors) in nwaf_ip_wl parameter. Requests are put under the parameter will not be blocked, transfered into RabbitMQ annd analysed by Nemesida AI module. Be careful using this parameter.

It is allowed to use IPv6 and IPv4-addresses.

nwaf_host_wl

Deactivation of the request analysis mechanism, using Nemesaida WAF instruments, for the virtual host. Using parameter nwaf_host_wl *; the pass will be made for all virtual hosts.

Example for use single value:

nwaf_host_wl *;
nwaf_host_wl example.com;
nwaf_host_wl *.example.com;

Example for use many values:

nwaf_host_wl example.com, 1.example.com;
nwaf_host_wl example.com, *.example.com;
nwaf_ip_lm

Configuring the pass of all occurrences of the rules for a specific IP address or subnet with the event recorded in the DBMS (IDS mode).

Example:

nwaf_ip_lm x.x.x.x;

With the nwaf_ip_lm x.x.x.x domain=example.com; pass will be made only when contacting a specific IP address to a specific domain.
For the domain option it is allowed to use a wildcard value.
As an IP address it is allowed to use address with subnet mask (for example, 192.168.0.0/24) or subnet range (for example, 192.168.0.1-192.168.255.255).

It is allowed to use IPv6 and IPv4-addresses.

nwaf_host_lm

Configuring the pass of all occurrences of the rules for a specific virtual host with the event captured in the DBMS (IDS mode). With the parameter nwaf_host_lm *; the pass will be made for all virtual hosts.

Example for use single value:

nwaf_host_lm *;
nwaf_host_lm example.com;
nwaf_host_lm *.example.com;

Example for use many values:

nwaf_host_lm example.com, 1.example.com;
nwaf_host_lm example.com, *.example.com;
nwaf_put_body_exclude

The parameter that prevents the signature method from analyzing the content of the BODY zone for PUT requests, as well as sending the zone content to the Nemesida AI MLA and Nemesida AI MLC modules. This option is useful when using web applications such as ownCloud or similar that allow the user to upload files via the HTTP protocol.

Example for use single value:

nwaf_put_body_exclude *;
nwaf_put_body_exclude example.com;
nwaf_put_body_exclude *.example.com;

Example for use many values:

nwaf_put_body_exclude example.com, 1.example.com;
nwaf_put_body_exclude example.com, *.example.com;
nwaf_body_exclude

The parameter that prevents the signature method from analyzing the content of the BODY zone, as well as sending the zone content to the Nemesida AI MLA and Nemesida AI MLC modules. This option is useful if you can’t change the value of theclient_body_buffer_size parameter in the /etc/nginx/nginx.conf file.

Example:

nwaf_body_exclude *;
nwaf_body_exclude example.com/uploads.php;
nwaf_body_exclude example.com/uploads;

When using the parameter, the exact path match (vhost/path) is taken into account.

For example, if the value is example.com/uploads the BODY zone analysis exception will be applied for requests to example.com/uploads, but for example.com/uploads.php and example.com/uploads/index.php this parameter will not be applied.

nwaf_geoip_db_path*

The parameter defining the location of the file with the GeoIP2 base. Used by the extended locking mechanism.

Example:

nwaf_geoip_db_path /opt/geoip/GeoLite2-City.mmdb;

The file is available for download on the official site (City database). After unpacking the archive, the file with the extension .mmdb must be placed in the appropriate directory and given read access to the Nginx web server.

nwaf_log_mr_all

Activation of the parameter for recording information about all occurrences of blocking rules (attack signatures) in the Nginx software error log. By default, the parameter is deactivated (commented out). When a parameter is deactivated, only the signature is written to the error log of the Nginx software, which led to blocking the request or fixing the signature without further blocking (in the LM mode).

Using thenwaf_log_mr_all domain=example.com; parameter the record of the recorded occurrances will do only for specific domain. For the domain option, strict matching and wildcard values are allowed: example.com, .example.com and *.example.com.

nwaf_captcha_unban**

Activation/deactivation of the mechanism for unlocking an IP address using captcha.

Example:

nwaf_captcha_unban on;
nwaf_check_bot_name

This parameter is used for defining search engine robots. Blocked requests that fall under the parameter do not increase the value of the rate counter and cannot cause the IP address to be blocked. The first parameter value is defined in the User-Agent zone. The second parameter value defines the host name obtained by reverse IP address conversion. If the second value is not set, it is considered equal to the first one.

Example:

nwaf_check_bot_name "example.com" "example.net";
nwaf_check_bot_name "example.com";
nwaf_check_bot_name "bingbot" "msn.com";
nwaf_check_bot_name "yandex.ru";

* Not used in Nemesida WAF Free.
** Activated in the virtual host settings.

LM mode features
The request that falls under the action of the nwaf_ip_lm, nwaf_host_lm or LM parameters and has BT 0 (request processing status) does not blocked, but will be included in the training sample.

The request that falls under the signature with a score (digital significance indicator) equal to 12, in the LM mode, will be transmitted to the Nemesida WAF API module, as well as to other query analysis subsystems, except the Nemesida AI MLA module. To send a request to the Nemesida AI MLA module, the total score for the request must exceed the value of the mla_score parameter. Signature indicators with score equal to 12 are not summed up.

If the request with score equal to 12 does not fall under the LM mode, the request will be blocked by signature analysis with transmission to the Nemesida WAF API module, but without processing by other request analysis subsystems.

Nemesida AI MLA

To configure the module, make the necessary changes to the main configuration file /etc/nginx/nwaf/mla.conf.

Parameters of mla.conf
Default parameter
Parameter description

tcp_socket
The address of the connection to the Nemesida AI MLA module.
debug
Activate/deactivate debug mode.
st_enable
Sending disputed requests to the Nemesida WAF Signtest server for post-processing.

Disputed requests are defined as follows:
– if the signature analysis determined the request as illegitimate, and the Nemesida AI MLA module determined it as legitimate;
– if the signature analysis determined the request as legitimate, and the Nemesida AI MLA module determined it as illegitimate.

st_uri
Nemesida WAF Signtest server URI for processing Nemesida AI results.

The Nemesida AI MLA module loads models according to the list obtained from the Nemesida AI MLC module (vhosts_list parameter in the mlc.conf file).

After making changes, restart the server or restart the services and check their operation:

# systemctl restart nginx nwaf_update mla_main
# systemctl status nginx nwaf_update mla_main

Using Nemesida WAF in IDS mode
It is necessary to set up traffic mirroring from the main web server (through which calls to the web application are made)to the server with the installed Nemesida WAF software, to working Nemesida WAF in IDS mode. You must make changes to the files on every server:

1. On the main server (without the Nemesida WAF module installed), configure traffic mirroring according to the guidelines of the installed web server (Nginx, Apache2, Microsoft IIS and others).

An example of Nginx setting for traffic mirroring

If using the Nginx web server, make the necessary changes to the virtual host file:

upstream mirror_upstream {
        server nemesida_waf_server:port;
        server 127.0.0.1:88 backup;

}

server {
        listen  127.0.0.1:88 default_server;
        return 200 "Response code: 200";
        add_header Content-Type text/plain;
        access_log off;
}
server {
        ...
        location / {
                mirror /mirror;
                root /var/www/html;
                proxy_pass      http://mirror_upstream;
                include         proxy_params;
        }

        location = /mirror {
                   internal;
                   proxy_pass http://mirror_upstream$request_uri;
                   proxy_connect_timeout 10s;
                   proxy_send_timeout 10s;
                   proxy_read_timeout 15s;
    }

}

nemesida_waf_server is the address of the server with the Nemesida WAF module installed, to which duplicate traffic will be transmitted.

2. On the server with the installed Nemesida WAF module, bring the configuration file of the virtual host Nginx to the form:

server {
        ...
        
        location / {
                proxy_pass http://127.0.0.1:86/;
        }
}

server {
        listen  86;
        index   index.html;
        root    /var/www/html;

        location / {
                 return 200;
                 add_header Content-Type text/plain;
        }
}

3. On the server with the Nemesida WAF module installed, bring the /etc/nginx/nwaf/conf/global/nwaf.conf file to the form:

...
nwaf_limit rate=5r/m block_time=0;
...

4. To get information from the main web server about the source IP address of the client, on the server with the Nemesida WAF module installed, bring the file /etc/nginx/nginx.conf to the form:

server {
...
set_real_ip_from x.x.x.x;
real_ip_header X-Real-IP;
real_ip_recursive on;
}

x.x.x.x is the address of the main web server that duplicates traffic to the server with the Nemesida WAF module installed. The source IP address of the client is transmitted by the main web server in the header X-Real-IP.

To use the Nginx functionality, it must contain the ngx_http_realip_module module. Nginx installed from the official repository contains the specified module by default.

More information is available on the official page of the Nginx documentation.

5. After changing restart the Nginx on every server.

Using Nemesida WAF in reverse proxy mode

To use a web server with installed Nginx and Nemesida WAF as an intermediate server, you should create corresponding file of the virtual host (for example /etc/nginx/conf.d/example.com.conf).

Example of the virtual host file
server {
        server_name  site.example.com;
        listen 80;

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

where x.x.x.x is the address of destination server with the web application.

More information is available on the official page of the Nginx documentation.

Signature management and virtual patching

There is a support of custom set of signatures rules (signature, RL) and signature exception rules (exclusion rule, WL) in Nemesida WAF and Nemesida WAF Free.

Zones and additional conditions

During the creation of RL or WL rules special parameters can be used:

  • zones: URL, ARGS, BODY, HEADERS, Cookie, User-Agent, Content-Type, etc.;
  • conditions of using the rule (additional condition, specification of the zone): $URL, $ARGS, $BODY, $HEADERS, $Cookie, $User-Agent, etc.

Using zones and additional conditions allows to concretize maximally the creating rule. Additional conditions are set by adding prefix $ (for example: "Z:...|$URL:...").

An example of using the rule with zone and additional condition: WL ... "Z:ARGS|$URL:/123"; – the rule will work, if the entry zone of the RL rule will be ARGS zone and URL will contain an entry /123.

Several parameters (zones, additional conditions) in one rule must be separated with the character |, the following principle of interaction will be used:

  • zones interact using the logical principle OR, for example: Z:URL|ARGS;
  • zones interact with additional conditions using the logical principle AND, for example: Z:URL|$ARGS:123;
  • additional conditions interact using the logical principle AND, for example: Z:...|$ARGS:123|$BODY:123".

When used in the additional conditions | as a regular character, it is necessary to make its single shielding. For example: $URL:abc\|d – search for the occurrence of abc|d.

Regular expressions in the additional conditions

It is possible to use regular expressions in the additional conditions. This requires to add to the additional condition postfix _X (for example: "Z:...|$URL_X:\w+").

For use regular expression operators in a rule as regular characters (/, ., *, ?, !, {, }, [, ], (, ), ^, $, :, \, etc.), they must be double shielding. For example:

  • $BODY_X:block\\|page – search of an entry block|page;
  • $BODY_X:data=\\(block-\\\a\\\-in-the-main\\) – search of an entry data=(block-\a\-in-the-main);
  • $ACCEPT_X:image\\/webp\\\\\* – search of an entry image/webp\* in Accept headers.

For use in additional conditions the separator as a metacharacter of a regular expression it is necessary to shield it double. For example: the rule WL ... "Z:...|$URL_X:/(a\\|b)/"; will bring to URL which contains /a/ or /b/.

User-defined signature creation

The user-defined rules of detecting attack signs must be placed in the main configuration file Nemesida WAF (/etc/nginx/nwaf/conf/global/nwaf.conf). They must be determined by the RL parameter, must have ID ranging from 50000 to 99999 and take the following form:

RL ID:50000 "P:select from" "SC:SQL:12" "Z:ARGS";
RL ID:50001 domain=example.com "P:select from" "SC:SQL:12" "Z:ARGS";
RL ID:50002 domain=.example.com "P:select from" "SC:SQL:12" "Z:ARGS";
RL ID:50003 domain=*.example.com "P:select from" "SC:SQL:12" "Z:ARGS";
RL ID:50004 "PX:select\s+from" "SC:SQL:12" "Z:ARGS|$URL:/admin";
RL ID:50005 "P:select from" "SC:SQL:12" "Z:ARGS|$URL:/(admin\\|dev)";

For signatures in the zone it is allowed to use the MLA value to force request sending into Nemesida AI MLA, that falls within the scope of the created signature if the score < 12 (by default requests with a score equal or greater than the value of the mla_score parameter are sent into Nemesida AI MLA).

Signature force sending into Nemesida AI MLA examples

Request contains an entry select from in any of four zones will be sent into Nemesida AI MLA:

RL ID:50005 "P:select from" "SC:SQL:1" "Z:MLA";

Request contains an entry select from in ARGS zone will be sent into Nemesida AI MLA:

RL ID:50006 "P:select from" "SC:SQL:1" "Z:ARGS|MLA";
Signature options
ID
The unique identifier for the rule. A range from 50000 to 99999 is available for creating your own rules. Required.
domain
Set the ownership of the rule to the domain. For the domain option it is allowed to use a wildcard value.
P/PX
Option defining the entry pattern (option P is used to denote a simple entry, option PX is a regular expression). Required.
SC
Setting the rule tag (Injection, XSS, UWA, Scanner, Evasion, Other or another) and the numerical value indicator (from 1 to 12). Required.

Requests that fall within the scope of the rules with an indicator value of 12 are blocked without being sent to other analysis subsystems. More information is available in the corresponding section. Summation of digital indicators for decision-making is performed in each separate zone by identical tags.

Z

Zone application of the rule. To apply a signature to all zones, use the empty "Z:" parameter. Required.

To apply a signature to multiple zones, use the delimiter "Z:URL|BODY".

To force the request to the Nemesida AI MLA module use MLA value in rules application zone ("Z:MLA") while digital significance indicator (SC) must be less than 12.

To disable sending a request to the Nemesida AI MLA module, use the NoMLA value in the rule application area ("Z: NoMLA").

To disable IP address blocking due to the occurrence of a signature that has score = 12, use the value NoBan in the rule area ("Z:NoBan"). Entering a signature with such a zone does not reduce the nwaf_limit counter, meaning it does not block the IP address.

To clarify the zone, you can use additional options. For "Z:ARGS|$URL:/templates" the rule will work only in the ARGS zone with /templates parameter in URL.

For signatures in zone area, you can use the NoAPI value to disable sending a message to the Nemesida WAF API that falls under the action of the created signature. For all triggers of this signature, the message will not be sent to the Nemesida WAF API, but it will be blocked and written to the log file. This value is only used for signatures that have score = 12. For signatures with a different score, this value is ignored.

RL ID:50001 "P:select from" "SC:SQL:12" "Z:ARGS|URL|BODY|NoAPI";

For zone area you can use the LM value, which activates the LM mode for a request that falls under the action of the created signature. Each request that falls under the signature will not be blocked, but a corresponding message will be sent to the Nemesida WAF API about it, which is also recorded in the log file. The LM value is only used for signatures that have score = 12. For signatures with a different score, this value is ignored.

RL ID:50002 "P:select from" "SC:SQL:12" "Z:ARGS|URL|BODY|LM";

To reduce the number of false positives during the creation signature rules it is neсessary to specificate them maximally.

Creating a signature exclusion rule

In case the inquiry falls under action of a signature, in addition to sending the incident to the Nemesida WAF API, the following line will be displayed in the error log of the Nginx software:

Nemesida WAF: the request ххх contains a rule id 1 in zone HEADERS, ...

or, if the request contains a signature with a maximum allowable digital indicator of significance (score = 12):

Nemesida WAF: the request ххх blocked by rule id 1 in zone HEADERS, ...

where:

  • 1 – attack signature ID;
  • HEADERS – signature entry zone.

To display absolutely all occurrences of signatures in the request (if there are occurrences), including those occurrences that did not lead to the subsequent blocking of the request, activate the nwaf_log_mr_all; parameter, in the nwaf.conf file Nemesida WAF.

The information about current signature list is on the page rlinfo.nemesida-security.com.

Examples of creating attack signature exception rules

WL ID:1 "Z:"; – using these parameters, the entry of the rule with the identifier 1 will be excluded from all zones for all virtual hosts.

WL ID:1 "Z:ARGS|HEADERS"; – using these parameters the entry of the rule with the identifier 1 will be excluded from the ARGS and HEADERS zones for all virtual hosts.

WL ID:1 "Z:ARGS|Cookie"; – using these parameters the entry of the rule with the identifier 1 will be excluded from the ARGS and Cookie for all virtual hosts.

WL ID:1 domain=.example.com "Z:URL"; – using these parameters the entry of the rule with the identifier 1 will be excluded from the URL zone for the virtual host example.com and its subdomains.

WL ID:1 domain=example.com "Z:URL|$URL:/index/index.php"; – using these parameters the entry of the rule with the identifier 1 will be excluded from the URL zone for the virtual host example.com for URI http://example.com/index/index.php.

WL ID:1 domain=example.com "Z:ARGS"; – with these parameters, the ARGS zone of all requests to the virtual host example.com will be excluded from the signature analysis processing.

WL ID:1 domain=example.com "Z:$URL:/test"; – using these parameters the entry of the rule all requests to example.com/test will be excluded from the signature analysis processing.

For security reasons, when creating exclusion rules, you need to specify them as much as possible.

Switching the blocking rules to LM mode

Requests that fall under the LM mode are recorded in the database, but are not blocked. When the rule is triggered, a message will be sent to the Nginx error log and to the Nemesida WAF API about switching the corresponding blocking rule to LM mode, but the request will not be blocked. The rules for switching to the LM mode must be defined by the LM parameter, have the ID of the corresponding blocking rule and take the following form:

Examples of creating rules for switching to LM mode
LM ID:1 "Z:URL"; — with these parameters, requests with the signature with the identifier 1 in the URL zone will be switched to LM mode;

LM ID:50001 "Z:URL"; – with these parameters, requests with the occurrence of a user-defined signature with the identifier 50001 in the URL zone will be switched to the LMmode;

LM ID:50002 domain=example.com "Z:URL"; – with these parameters, requests with the occurrence of a user-defined signature with the identifier 50002 in the URL zone will be switched to the LM mode for the domain example.com;

LM ID:50003 domain=*.example.com "Z:ARGS"; – with these parameters, requests with the occurrence of a personal signature with the identifier 50003 in the zone ARGS will be switched to the LM mode for all subdomains of the virtual host example.com, excluding the main domain;

LM ID:50004 domain=example.com "Z:BODY|$URL:/edit" – with these parameters, requests for the virtual host example.com will be switched to LM mode if a personal signature with the identifier 50004 occurs in the BODY zone and the URL zone contains /edit;

LM ID:50005 domain=example.com "Z:BODY|$URL_X:^/edit" – with these parameters, requests for the virtual host example.com will be switched to LM mode if the personal signature with the identifier 50005 occurs in the BODY zone and the URL zone starts with /edit;

LM ID:50006 domain=example.com "Z:BODY|$ARGS:test=123" – with these parameters, requests for all subdomains of the virtual host example.com , excluding the main domain, will be switched to the LM mode if the personal signature with the identifier 50006 occurs in the BODY zone and the ARGS zone contains /edit.

Virtual patching

Nemesida WAF virtual patching protects websites from existing uncorrected vulnerabilities (including “zero day”), blocking attempts to exploit them, while not disrupting the operation of the web application. The application of virtual patching rules allows developers to focus on fixing vulnerabilities without the need for urgent code changes. Virtual patching allows you to block all attempts to exploit a known vulnerability on the fly, controlling the attack zone in a special way.

Nemesida WAF uses two sources of virtual patch generation: automatically, by the module Nemesida AI, and manually, by creating signature rules.

Usage example
In the web application example.com a vulnerability has been identified in the implementation of SQL using the GET parameter id. As arguments, the parameter must accept only numeric values, which means that to block exploitation attempts, it is necessary to restrict the use of other characters. To do this, we will create a personal signature that is based on a regular expression:

RL ID:50001 domain=example.com "PX:id=[^\d+]" "Z:ARGS";

Request processing statuses (BT)

Each request processed by the Nemesida WAF module is assigned a blocking identifier (BT – blocking type).
The identifier can be assigned regardless of whether the request was blocked.

The pivot table shows the types of identifiers and their corresponding request processing status.

0 The request was not blocked.
1 The request is blocked by signature method and the request did not contain any signature with the score = 12.
2 The request is blocked by signature method and the request contained a signature which has the score = 12.
3 The request is blocked by Nemesida AI MLA.
4 The request is blocked by ClamAV module.
5 The request is blocked because of the internal error.
6 The request is blocked because of the oversubscription of blocked requests from one IP address.
7 The request is detected like the brute force attempt and blocked by Nemesida AI MLC.
8 The request is blocked by Nemesida AI MLC (additional traffic analysis of all nonblocked requests by Nemesida WAF module) and is managed by ai_extra parameter in mlc.conf file.
9 The request is detected as a flood attempt and blocked by the Nemesida AI MLC.
10 The request is detected like the DDoS attacks and blocked by Nemesida AI MLC.

For BT 1, 2, 3, 4, 8 events, the nwaf_limit parameter in the nwaf.conf file allows you to adjust the allowed number of blocked requests. If the allowed number of requests specified by the rate option is exceeded, the IP address will be blocked for the time (in seconds) specified in block_time.

For BT 7, 9, 10 events the blocking of the IP address of the request source will occur after the first blocked request, regardless of the value of the rate parameter (the allowed number of blocked requests) in nwaf_limit.

Nginx optional headers

Optional header $nwaf_block_type

Nemesida WAF allows to use special header, which determinative the result of the request processing. To activate it required to add parameter add_header NemesidaWAF-BT $nwaf_block_type always; into http, server or location area of the nginx configuration file.

Example of using the header

  • Set the header into the server area:
    server {
       ...
       add_header NemesidaWAF-BT $nwaf_block_type always;
       ...
    }
    

    and restart nginx.

  • Execute the request: curl -i localhost/nwaftest.

The server’s answer will contain the information about the status of the request processing in the NemesidaWAF-BT header:

HTTP/1.1 403 Forbidden
Server: nginx/1.16.1
Date: Wed, 12 Feb 2020 19:05:26 GMT
Content-Type: text/html
Content-Length: 153
Connection: keep-alive
NemesidaWAF-BT: 2
...

In this case the status is 2. It means that the request was blocked because of the attack’s signature entry with the score equal to 12 (nwaftest). More information about the request processing status is available in the corresponding paragraph. This header can be useful during the generation of the customized page of the server answer (for example if the request is blocked).

Optional header $nwaf_cc

Nemesida WAF allows you to use a special header that determines the result of blocking a request by country using extended request blocking rules. To activate it, you need to add the parameter add_header NemesidaWAF-CC $nwaf_cc always; to the http, server or location of the configuration file nginx.

Example of using the header

  • Set the header to the server area:
    server {
       ...
    add_header NemesidaWAF-CC $nwaf_cc always;
    ...
    }
    

    and restart nginx.

  • Execute the request: curl -i example.com

The server response in the header NemesidaWAF-CC will contain information about the blocking status:

HTTP/1.1 403 Forbidden
Server: nginx/1.16.1
Date: Wed, 12 Feb 2020 19:05:26 GMT
Content-Type: text/html
Content-Length: 153
Connection: keep-alive
NemesidaWAF-CC: 1
...

In this case, the status is 1. This means that the request was blocked by the country field. If the rule is compiled using additional fields, for example, body or headers, then the header will not be applied when blocking. The exceptions are the fields vhost and url.

Unlocking an IP address using captcha
If suspicious activity is detected, Nemesida WAF allows you to block the IP address of the source of requests for a certain time (the duration of the block is regulated by the nwaf_limit option in the nwaf.conf configuration file). Using the captcha functionality, the user can unlock their own IP address if it has been identified as a source of brute force attacks (BT 7), floods (BT 9) or denial of service attacks (BT 10).

For correct work of the IP address unlocking mechanism, you need to activate the nwaf_captcha_unban parameter by adding it in the virtual host file to the server section for a specific URL address. Example of activating the nwaf_captcha_unban parameter

server {
    listen  80;
    server_name example.com;

    location /captcha_ip_unban_path {
             ...
             nwaf_captcha_unban on;
             ...
    }
    ...
}

Also, you need to setup a web application with a captcha. Detailed instructions for integrating Nemesida WAF with reCAPTCHA functionality can be found at link.

After activating the nwaf_captcha_unban on; parameter and restarting Nginx, the IP address unblocking functionality becomes available for the target URL address with the nwaf_captcha_unban option set. For example: example.com/captcha_ip_unban_path.

If the answer is correct, the web application with captcha sends a request delete_banned_ip to the Nemesida WAF module to unlock the IP address. The user will then be redirected to the original page.

For security reasons, it is recommended to allow requests to the server URL with the Nemesida WAF dynamic module installed and the nwaf_captcha_unban IP address unlocking parameter activated only from the IP address of the server with captcha.

Configuring interaction with ClamAV software
After installing Nemesida WAF package the functionality of interaction with ClamAV software is disabled by default, since it can be a source of false blocking of some requests to the Web application (depending on the current state of the ClamAV signature analysis database). Use this functionality at your discretion.

To activate antivirus protection, install ClamAV software on the server with the configured Nemesida WAF software, if it has not done yet.

Installation example for Debian 10:

# apt install clamav-daemon

The interaction with the ClamAV software is enabled by activating the nwaf_clamav configuration parameter in the /etc/nginx/nwaf/conf/global/nwaf.conf file and reduction of the /etc/clamav/clamd.conf file to a look:

...
TCPSocket 3310
TCPAddr   127.0.0.1
...

After changing restart the Nginx software.