Installation, configuration and operation guide for the Nemesida WAF API module designed for:

  • receiving information about attacks and identified vulnerabilities;
  • receiving attack statistics and centralized collection and processing of logs of all components of Nemesida WAF;
  • manage the settings of the Nemesida WAF and Nginx web server;
  • manage the settings of the Nemesida WAF Scanner vulnerability scanner.

Domain name api.example.com is used as an example of naming a server with the Nemesida WAF API module installed.

Nemesida WAF API installation and setup

Nemesida WAF API is intended to transfer information from the Nemesida WAF modules (blocked requests, detected vulnerabilities, operation status of machine learning module) to the PostgreSQL database for subsequent integration with different services, such as Nemesida WAF Cabinet, SIEM class systems, etc.

To install Nemesida WAF API, you must perform the following steps:

1.Install and configure the PostgreSQL DBMS:

Automatic installationDebian, UbuntuRHEL
To deploy a PostgreSQL DBMS, you can use a script for automatic installation and initialization of the database:

1. Upload script.

2. Run the installation script with the command:

# /bin/bash ./1-postgresql-deploy.sh 'pg_api_pwd=%Password%' 'pg_cabinet_pwd=%Password%' 'api_srv_ip=%Nemesida WAF API server address%'

where:

  • pg_api_pwd – password for creating a user nw_api for the database waf;
  • pg_cabinet_pwd – password for creating a user nw_cabinet for the database cabinet (required for the operation of the Nemesida WAF Cabinet component);
  • api_srv_ip – IP address of the server from which component will be accessed after its configuration.
Install the packages:

# apt update && apt upgrade
# apt install postgresql

Create a database, user and password to connect the Nemesida WAF API module:

# su - postgres -c "psql -c \"CREATE DATABASE waf;\""
# su - postgres -c "psql -c \"CREATE ROLE nw_api PASSWORD 'YOUR_PASSWORD';\""
# su - postgres -c "psql -c \"GRANT ALL ON DATABASE waf TO nw_api;\""
# su - postgres -c "psql -c \"ALTER ROLE nw_api WITH LOGIN;\""
# su - postgres -c "psql waf -c \"GRANT ALL ON ALL TABLES IN SCHEMA public TO nw_api;\""
# su - postgres -c "psql waf -c \"GRANT ALL ON ALL SEQUENCES IN SCHEMA public TO nw_api;\""
# su - postgres -c "psql waf -c \"GRANT CREATE ON SCHEMA public TO nw_api;\""

If the database is used on a separate server, then it is necessary to provide access to it. To do this, you need to make changes to the PostgreSQL configuration file pg_hba.conf.

Example:

# IPv4 local connections:
host    all             all             10.1.1.1/32            md5
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

Install and configure the PostgreSQL DBMS:

# dnf update
# dnf install postgresql-devel postgresql-server
# postgresql-setup initdb
# sed -i "s|host    all             all             127.0.0.1/32            ident|host    all             all             127.0.0.1/32            md5|" /var/lib/pgsql/data/pg_hba.conf
# sed -i "s|host    all             all             ::1/128                 ident|host    all             all             ::1/128                 md5|" /var/lib/pgsql/data/pg_hba.conf
# systemctl start postgresql
# systemctl enable postgresql

Create a database, user and password to connect the Nemesida WAF API module:

# su - postgres -c "psql -c \"CREATE DATABASE waf;\""
# su - postgres -c "psql -c \"CREATE ROLE nw_api PASSWORD 'YOUR_PASSWORD';\""
# su - postgres -c "psql -c \"GRANT ALL ON DATABASE waf TO nw_api;\""
# su - postgres -c "psql -c \"ALTER ROLE nw_api WITH LOGIN;\""
# su - postgres -c "psql waf -c \"GRANT ALL ON ALL TABLES IN SCHEMA public TO nw_api;\""
# su - postgres -c "psql waf -c \"GRANT ALL ON ALL SEQUENCES IN SCHEMA public TO nw_api;\""
# su - postgres -c "psql waf -c \"GRANT CREATE ON SCHEMA public TO nw_api;\""

If the database is used on a separate server, then it is necessary to provide access to it. To do this, you need to make changes to the PostgreSQL configuration file pg_hba.conf.

Example:

# IPv4 local connections:
host    all             all             10.1.1.1/32            md5

2. Install the module:

Before installing the module, be sure to check access to the created database by connecting to it with the command: psql -h <server_ip> -U nw_api waf. When connecting, enter the user’s password nw_api.

Automatic installationDebianUbuntuRHELDocker

1. Download script;

2. Run the installation script with the command:

# /bin/bash ./2-api-deploy.sh 'pg_srv_ip=%PostgreSQL server address%' 'pg_srv_port=%PostgreSQL port%' 'pg_api_pwd=%Password%' 'api_proxy=%Proxy server address%'

where:

  • pg_srv_ip – IP address of the database server waf;
  • pg_srv_port – the server port with the database waf;
  • pg_api_pwd – user password nw_api for DB waf;
  • api_proxy – (Optional) IP address of the proxy server for component access to external resources (e.g http://proxy.example.com:3128).
Install the packages:

# apt install apt-transport-https gnupg2 curl

Add the Nemesida WAF repository:

Debian 11
# echo "deb https://nemesida-security.com/repo/nw/debian bullseye 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
Debian 12
# echo "deb https://nemesida-security.com/repo/nw/debian bookworm nwaf" > /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

Install the packages:

# apt install nginx python3-pip python3-dev postgresql-server-dev-all python3-venv memcached
# apt install nwaf-api

During the installation of the module, the following pip packages are additionally installed:
flask func-timeout netaddr psycopg2-binary pymemcache pyopenssl cryptography python-decouple requests validators pandas pyarrow jsonref

Install the packages:

# apt install apt-transport-https gnupg2 curl

Add the Nemesida WAF repository and install packages:

Ubuntu 20.04
# echo "deb [arch=amd64] https://nemesida-security.com/repo/nw/ubuntu focal 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 install nginx python3.9 python3-pip python3.9-dev postgresql-server-dev-all python3.9-venv build-essential memcached
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 install nginx python3 python3-pip python3-dev postgresql-server-dev-all python3-venv build-essential memcached
Ubuntu 24.04
# echo "deb [arch=amd64] https://nemesida-security.com/repo/nw/ubuntu noble nwaf" > /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 install nginx python3 python3-pip python3-dev postgresql-server-dev-all python3-venv build-essential memcached

Install the packages:

# apt install nwaf-api

During the installation of the module, the following pip packages are additionally installed:
flask func-timeout netaddr psycopg2-binary pymemcache pyopenssl cryptography python-decouple requests validators pandas pyarrow jsonref

Add the Nemesida WAF repository by bringing the file /etc/yum.repos.d/NemesidaWAF.repo to the form:

[NemesidaWAF]
name=Nemesida WAF Packages for RHEL
baseurl=https://nemesida-security.com/repo/nw/rhel/$releasever/$basearch/
gpgkey=https://nemesida-security.com/repo/nw/gpg.key
enabled=1
gpgcheck=1

Install the packages:

RHEL 8 and derivatives
# dnf install epel-release
# dnf update
# dnf install nginx python39 python39-devel python39-setuptools python39-pip postgresql-devel gcc memcached
RHEL 9 and derivatives
# dnf install epel-release
# dnf update
# dnf install nginx python3 python3-devel python3-setuptools python3-pip postgresql-devel gcc memcached

Install the packages:

# dnf install nwaf-api

During the installation of the module, the following pip packages are additionally installed:
flask func-timeout netaddr psycopg2-binary pymemcache pyopenssl cryptography python-decouple requests validators pandas pyarrow jsonref

Information about using Nemesida WAF in a Docker container is available in the corresponding section.

3. Allow access:
When deploying the database locally:
– to external servers;
– to the Memcached server 127.0.0.1:11211;
– to the PostgreSQL DBMS server 127.0.0.1:5432.
When deploying the database on a separate server:
– to external servers;
– to the Memcached server 127.0.0.1:11211;
– to the PostgreSQL DBMS server <server_ip>:5432.

4. Make the necessary changes to the /var/www/nw-api/settings.py file to connect to the PostgreSQL DBMS.

settings.py

When using the automatic installation script, file editing is not required.

Parameter
Description
PROXY
Proxy address (optional).

For example:

PROXY = 'http://proxy.example.com:3128'

It is allowed to use authentication parameters when using a proxy server.

Example:

PROXY = 'http://<user>:<password>@proxy.example.com:3128'

DB_HOST
DB_PORT
DB_NAME
DB_USER
DB_PASS
Parameters for connecting to the database of the Nemesida WAF API module.
RO_MODE
The mode of interaction with the database in the “read-only” mode.

The parameter is activated on one of the servers with the Nemesida WAF API module installed to increase fault tolerance in cases when another server with the Nemesida WAF API module installed becomes unavailable.

Parameter activation includes PostgreSQL replication.


MEMCACHED_HOST
MEMCACHED_PORT
Parameters for connecting to the Memcached server.

5. Activate virtual host:

# mv /etc/nginx/conf.d/nwaf-api.conf.disabled /etc/nginx/conf.d/nwaf-api.conf
# nginx -t && service nginx reload

6. Restart the services and test the module:

# systemctl restart nw-api rldscupd nginx memcached
# systemctl status nw-api rldscupd nginx memcached

The rldscupd service is designed to get additional data about events (description of anomalies, GeoIP data, etc.).

During the Nemesida WAF API operation the information about errors is contained in the run-time journals of the module /var/log/uwsgi/nw-api/*.log.

For security reasons, it is necessary to restrict access to the Nemesida WAF API:

  • allow access only from trusted IP addresses;
  • allow access to http://api.example.com:8080/nw-api/attack only for filtering node and Nemesida AI MLC servers.

Nemesida WAF API integration
To integrate the Nemesida WAF API with the Nemesida WAF software, follow these steps:

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

nwaf_sys_proxy http://proxy.example.com:3128;
nwaf_api_proxy http://proxy.example.com:3128;
nwaf_api_conf host=http://api.example.com:8080/nw-api/;

where api.example.com:8080/nw-api/ is the address and port of the server where the Nemesida WAF API module is installed, and http://proxy.example.com:3128 is the proxy server address for accessing Nemesida WAF API.

2. On the server with the Nemesida AI MLC module installed, change the configuration file /opt/mlc/mlc.conf, bring the parameters to the form:

api_uri = http://api.example.com:8080/nw-api/
api_proxy = http://proxy.example.com:3128

3. On the server with the Nemesida WAF Scanner module installed, change the configuration file /opt/nws/main.conf, bring the parameters to the form:

api_host = http://api.example.com:8080/nw-api/
api_proxy = http://proxy.example.com:3128

4. After making changes, you must restart the services or restart the server.

Managing Nemesida WAF settings

🔗 General information

Using API calls, you can manage Nemesida WAF settings:

  • filtering node settings;
  • Nemesida AI MLC settings;
  • API Firewall Settings;
  • behavioral models;
  • synchronization of the settings of the filtering node Nemesida WAF, Nemesida AI MLC between servers;
  • signature exclusion rules and extended blocking rules.

Settings are managed using specially compiled queries. Each request must contain a license key of the installed copy of Nemesida WAF.

🔗 Configuring the filtering node

Allows managing the settings of the filtering node. Supports the following control commands:

Get settings
Request example:

# curl http://api.example.com:8080/nw-api/v2/get_dyn_settings --data 'key=%License key%'

Response format:

{
  "status": "success",
  "active": boolean,
  "nwaf_limit": [string, ...],
  "nwaf_ip_wl": [string, ...],
  "nwaf_ip_lm": [string, ...],
  "nwaf_geoip_mla_disable": [string, ...],
  "nwaf_host_wl": [string, ...],
  "nwaf_host_lm": [string, ...],
  "nwaf_url_wl": [string, ...],
  "nwaf_rfc_violation_wl": [string, ...],
  "nwaf_rfc_violation_lm": [string, ...],
  "nwaf_b64_decode_disable": [string, ...],
  "nwaf_mla_host_lm": [string, ...],
  "nwaf_ai_extra_host_wl": [string, ...],
  "nwaf_ai_extra_host_lm": [string, ...]
  "nwaf_bf_detect_host_lm": [string, ...],
  "nwaf_ddos_detect_host_lm": [string, ...],
  "nwaf_rmq_host_exclude": [string, ...],
  "nwaf_body_exclude": [string, ...],
  "nwaf_body_bin_exclude": [string, ...],
  "nwaf_post_body_exclude": [string, ...],
  "nwaf_put_body_exclude": [string, ...],
  "nwaf_openapi_ip_wl": [string, ...],
  "nwaf_openapi_ip_lm": [string, ...],
  "nwaf_openapi_url_wl": [string, ...],
  "nwaf_openapi_url_lm": [string, ...]
}

or

{"status": "fail", "description": "%description%"}

Response example:

{
  "status": "success",
  "active": true,
  "nwaf_limit": ["domain=example.com rate=5r/m block_time=600", ...],
  "nwaf_ip_wl": ["127.0.0.1", ...],
  "nwaf_ip_lm": ["127.0.0.1", ...],
  "nwaf_geoip_mla_disable": ["example.com", ...],
  "nwaf_host_wl": ["example.com", ...],
  "nwaf_host_lm": ["example.com", ...],
  "nwaf_url_wl": ["example.com/uploads.php", ...],
  "nwaf_rfc_violation_wl": ["*.example.com/login/index.php", ...],
  "nwaf_rfc_violation_lm": ["*.example.com/login/index.php", ...],
  "nwaf_b64_decode_disable": ["example.com/uploads/ z:BODY|URL", ...],
  "nwaf_mla_host_lm": ["example.com", ...],
  "nwaf_ai_extra_host_wl": ["example.com", ...],
  "nwaf_ai_extra_host_lm": ["example.com", ...]
  "nwaf_bf_detect_host_lm": ["example.com", ...],
  "nwaf_ddos_detect_host_lm": ["example.com", ...],
  "nwaf_rmq_host_exclude": ["example.com", ...],
  "nwaf_body_exclude": ["example.com/uploads.php", ...],
  "nwaf_body_bin_exclude": ["example.com/uploads.php", ...],
  "nwaf_post_body_exclude": ["example.com", ...],
  "nwaf_put_body_exclude": ["example.com", ...],
  "nwaf_openapi_ip_wl": ["127.0.0.1", ...],
  "nwaf_openapi_ip_lm": ["127.0.0.1", ...],
  "nwaf_openapi_url_wl": ["example.com/uploads.php", ...],
  "nwaf_openapi_url_lm": ["example.com/uploads.php", ...]
}
Set settings
Request example:
# curl http://api.example.com:8080/nw-api/v2/set_dyn_settings --header 'Content-type: application/json' --data '{
  "key": "%License key%",
  "set": {
    "active": true,
    "nwaf_limit": ["domain=example.com rate=5r/m block_time=600", ...],
    "nwaf_ip_wl": ["127.0.0.1", ...],
    "nwaf_ip_lm": ["127.0.0.1", ...],
    "nwaf_geoip_mla_disable": ["example.com", ...],
    "nwaf_host_wl": ["example.com", ...],
    "nwaf_host_lm": ["example.com", ...],
    "nwaf_url_wl": ["example.com/uploads.php", ...],
    "nwaf_rfc_violation_wl": ["*.example.com/login/index.php", ...],
    "nwaf_rfc_violation_lm": ["*.example.com/login/index.php", ...],
    "nwaf_b64_decode_disable": ["example.com/uploads/ z:BODY|URL", ...],
    "nwaf_mla_host_lm": ["example.com", ...],
    "nwaf_ai_extra_host_wl": ["example.com", ...],
    "nwaf_ai_extra_host_lm": ["example.com", ...]
    "nwaf_bf_detect_host_lm": ["example.com", ...],
    "nwaf_ddos_detect_host_lm": ["example.com", ...],
    "nwaf_rmq_host_exclude": ["example.com", ...],
    "nwaf_body_exclude": ["example.com/uploads.php", ...],
    "nwaf_body_bin_exclude": ["example.com/uploads.php", ...],
    "nwaf_post_body_exclude": ["example.com", ...],
    "nwaf_put_body_exclude": ["example.com", ...],
    "nwaf_openapi_ip_wl": ["127.0.0.1", ...],
    "nwaf_openapi_ip_lm": ["127.0.0.1", ...],
    "nwaf_openapi_url_wl": ["example.com/uploads.php", ...],
    "nwaf_openapi_url_lm": ["example.com/uploads.php", ...]
  }
}'

Response example:

{"status": "success"}

or

{"status": "fail", "description": "%description%"}

The following parameters are available for control:

Supported parameters
Parameter
Parameter description
nwaf_limit

Sets 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"] ...}

The domain parameter is optional and is only required to set the limit of blocked requests for a specific domain. To do this, need to bring the parameter to the form: nwaf_limit rate=... block_time=... domain=.... Strict matching and wildcard values are allowed: *, example.com, .example.com, *.example.com.

For the domain parameter, strict matching and wildcard values are allowed: *, example.com, .example.com, *.example.com.

The conditions for triggering the option are selected based on the following order of priority of the values of the domain parameter from the highest to the lowest:

  • example.com — activation of the domain option;
  • .example.com — triggering the option for the example.com domain and its subdomains;
  • *.example.com — the option is triggered only for subdomains of the example.com domain, excluding the main domain;
  • * — the option is triggered for all domains.

If you set several options:

{... "nwaf_limit": ["domain=.example.com rate=5r/m block_time=600", "nwaf_limit rate=15r/m block_time=600 domain=*.example.com"] ...}

then when requesting web.example.com to block an IP address, it will be enough to block 5 requests per minute, instead 15 because .example.com has a higher priority.

Example:

{... "nwaf_limit": ["domain=example.com rate=5r/m block_time=600"] ...}

To set different limits for different domains, specify parameters for each of them.

Example:

{... "nwaf_limit": ["domain=a.example.com rate=5r/m block_time=300", "domain=example.com rate=5r/m block_time=300"] ...}

or

{... "nwaf_limit": ["rate=10r/m block_time=600", "domain=example.com rate=5r/m block_time=300"] ...}

In the last example, limits will be set for 5 blocks per minute for the example.com domain (followed by blocking the attacker’s IP address for 300 seconds), as well as limits on 10 blocks per minute for all other domains (followed by blocking the attacker’s IP address for 600 seconds).

When brute force (BT 7), flood (BT 9) and DDoS attacks (BT 10) are detected, the rate parameter is not taken, blocking will be performed at the first trigger.

The following options are not allowed for the correct application of the option:

1. Using the option for the same domain with different values rate and block_time.

Example:

{... "nwaf_limit": ["domain=example.com rate=50r/m block_time=600", "domain=example.com rate=15r/s block_time=1500"] ...}

2. Simultaneous addition of option values with and without the domain=* parameter.

Example:

{... "nwaf_limit": ["domain=* rate=5r/m block_time=300", "rate=5r/m block_time=300"] ...}
nwaf_ip_wl

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

Example:

{... "nwaf_ip_wl": ["127.0.0.1", "192.168.0.1"] ...}

or

{... "nwaf_ip_wl": ["127.0.0.1", "domain=example.com 192.168.0.1"] ...}

When using "nwaf_ip_wl": "domain=example.com 127.0.0.1" the analysis mechanism will be deactivated only when accessing from a specific IP address to a specific domain. The domain option is optional. It is allowed to use strict compliance and wildcard values: *, example.com, .example.com, *.example.com.

IPv4/IPv6 addresses are allowed, including the use of CIDR (for example, x.x.x.x/24) and a range of IP addresses.

Example:

{... "nwaf_ip_wl": ["127.0.0.1", "192.168.61.0/24", "domain=example.com 192.168.61.1-192.168.61.255"] ...}

To reduce the number of false positives, it is recommended to specify the static IP address of users (administrators, content managers, editors) in the parameter nwaf_ip_wl. Requests that fall under the action of the parameter will not be blocked, sent to RabbitMQ, and, as a result, analyzed by the Nemesida AI module. Be extremely careful when using the parameter.

nwaf_ip_lm

Configuring request processing for a specific IP address or subnet with fixation in the DBMS, but without blocking (monitoring mode).

Example:

{... "nwaf_ip_lm": ["127.0.0.1", "192.168.0.1"] ...}

or

{... "nwaf_ip_lm": ["127.0.0.1", "domain=example.com 192.168.0.1"] ...}

When using "nwaf_ip_lm": "domain=example.com 127.0.0.1" the pass will be made only when accessing from a specific IP address to a specific domain. The domain option is optional. Strict matching and wild card values are allowed: *, example.com, .example.com, *.example.com.

IPv4/IPv6 addresses are allowed, including the use of CIDR (for example, x.x.x.x/24) and a range of IP addresses.

Example:

{... "nwaf_ip_lm": ["127.0.0.1", "192.168.61.0/24", "domain=example.com 192.168.61.1-192.168.61.255"] ...}
nwaf_geoip_mla_disable

The geographical location based on the IP address is determined using the connected GeoIP database, if the IP address information was not recieved from the file /etc/nginx/nwaf/conf/global/cc.json. In case of an error or inability to use it, the definition request is transferred to the Nemesida AI MLA module. For requests that fall under the parameter, determining the geographical location using Nemesida AI MLA will be deactivated.

Example:

{... "nwaf_geoip_mla_disable": ["example.com"] ...}

It is allowed to use strict matching and wildcard values to register a domain: *, example.com, .example.com, *.example.com.

Example of using multiple values:

{... "nwaf_geoip_mla_disable": ["example.com", "*.example.com"] ...}
nwaf_host_wl

Deactivation of the request analysis mechanism by Nemesida WAF for a virtual host. With the parameter nwaf_host_wl *, skipping will be performed for all virtual hosts.

Example of using a single value:

{... "nwaf_host_wl": ["*"] ...}

or

{... "nwaf_host_wl": ["example.com"] ...}

or

{... "nwaf_host_wl": ["*.example.com"] ...}

Example of using multiple values:

{... "nwaf_host_wl": ["example.com", "a.example.com"] ...}

or

{... "nwaf_host_wl": ["example.com", "*.example.com"] ...}
nwaf_host_lm

Configuring request processing for a specific virtual host with a commit in the DBMS, but without blocking (monitoring mode). With the parameter nwaf_host_lm *, skipping will be performed for all virtual hosts.

Example of using a single value:

{... "nwaf_host_lm": ["*"] ...}

or

{... "nwaf_host_lm": ["example.com"] ...}

or

{... "nwaf_host_lm": ["*.example.com"] ...}

Example of using multiple values:

{... "nwaf_host_lm": ["example.com", "a.example.com"] ...}

or

{... "nwaf_host_lm": ["example.com", "*.example.com"] ...}
nwaf_url_wl

Deactivation of the request analysis mechanism using Nemesida WAF for the URL. With the value of the * parameter, deactivation will be performed when accessing any URL.

Example:

{... "nwaf_url_wl": ["*"] ...}

or

{... "nwaf_url_wl": ["example.com/login/*"] ...}

or

{... "nwaf_url_wl": ["*.example.com/login/index.php"] ...}

With the value example.com/login/* the occurrence of the URL will be taken, for example, example.com/login/aaaa or example.com/login/bbbbb.

Example of using multiple values:

{... "nwaf_url_wl": ["example.com/login/*", "*.example.com/login/index.php"] ...}

If you need to use the * sign as a common character when writing a URL, then you need to escape it, for example, writing example.com/admin/uploads/aa\\*a will match example.com/uploads/aa*a.

nwaf_rfc_violation_wl

Deactivation of the request blocking mechanism by Nemesida WAF for the URL in case of RFC violation.

Example:

{... "nwaf_rfc_violation_wl": ["*"] ...}

or

{... "nwaf_rfc_violation_wl": ["example.com"] ...}

or

{... "nwaf_rfc_violation_wl": ["example.com/login/*"] ...}

or

{... "nwaf_rfc_violation_wl": ["*.example.com/login/index.php"] ...}

With the value nwaf_rfc_violation_wl example.com/login/*; the occurrence of the URL will be taken, for example, example.com/login/aaaa or example.com/login/bbbbb.

With the value example.com deactivation will be performed for all URLs of the virtual host example.com.

With the * value, deactivation will be performed for all virtual hosts.

Example of using multiple values:

{... "nwaf_rfc_violation_wl": ["example.com", "*.example.com/login/index.php"] ...}

If you need to use the * sign as a common character when writing a URL, then you need to escape it, for example, writing example.com/admin/uploads/aa \\*a will match example.com/admin/uploads/aa*a.

nwaf_rfc_violation_lm

Configuring request processing for a specific virtual host with fixation in the DBMS, but without blocking (monitoring mode) in case of RFC violation.

Example:

{... "nwaf_rfc_violation_lm": ["*"] ...}

or

{... "nwaf_rfc_violation_lm": ["example.com"] ...}

or

{... "nwaf_rfc_violation_lm": ["example.com/login/*"] ...}

or

{... "nwaf_rfc_violation_lm": ["*.example.com/login/index.php"] ...}

With the value nwaf_rfc_violation_wl example.com/login/*; the occurrence of the URL will be taken, for example, example.com/login/aaaa or example.com/login/bbbbb.

With the value example.com deactivation will be performed for all URLs of the virtual host example.com.

With the * value, deactivation will be performed for all virtual hosts.

Example of using multiple values:

{... "nwaf_rfc_violation_lm": ["example.com", "*.example.com/login/index.php"] ...}

If you need to use the * sign as a common character when writing a URL, then you need to escape it, for example, writing example.com/admin/uploads/aa \\*a will match example.com/admin/uploads/aa*a.

nwaf_b64_decode_disable

The parameter deactivates the additional Base64-decoding of the contents of the zones ARGS, BODY, URL, HEADERS during the signature analysis of requests before passing it to the Nemesida AI MLA module for additional analysis. If the request contains signatures explicitly, it will be transferred to Nemesida AI MLA. If the request contains signatures encoded in Base64 in one of the selected zones, the request will not be transferred to Nemesida AI MLA.

Example:

{... "nwaf_b64_decode_disable": ["*.example.com z:BODY|URL|ARGS|HEADERS"] ...}

or

{... "nwaf_b64_decode_disable": ["example.com/uploads/ z:BODY|URL"] ...}

or

{... "nwaf_b64_decode_disable": ["z:HEADERS"] ...}

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

It is allowed to use strict matching and wildcard values to register a domain: *, example.com, .example.com, *.example.com.

Example of using multiple values:

{... "nwaf_b64_decode_disable": ["*.example.com z:BODY|URL|ARGS|HEADERS", "example.com z:BODY|URL"] ...}

For the URL zone, it is recommended to disable Base64-decoding to eliminate excessive sending of requests to Nemesida AI MLA, which leads to increased consumption of server hardware resources.

nwaf_mla_host_lm

The parameter that activates the LM mode (monitoring mode) for requests defined by the Nemesida AI MLA module as illegitimate.

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

Example of using a single value:

{... "nwaf_mla_host_lm": ["*"] ...}

or

{... "nwaf_mla_host_lm": ["example.com"] ...}

or

{... "nwaf_mla_host_lm": ["*.example.com"] ...}

Example of using multiple values:

{... "nwaf_mla_host_lm": ["example.com", "a.example.com"] ...}

or

{... "nwaf_mla_host_lm": ["example.com", "*.example.com"] ...}
nwaf_ai_extra_host_wl

A parameter that activates the WL mode for requests defined by the Nemesida AI MLC module as illegitimate.

If the name of the virtual host from the request falls under the action of the parameter, then such a request is not recorded in the DBMS and is not blocked.

Example of using a single value:

{... "nwaf_ai_extra_host_wl": ["*"] ...}

or

{... "nwaf_ai_extra_host_wl": ["example.com"] ...}

or

{... "nwaf_ai_extra_host_wl": ["*.example.com"] ...}

Example of using multiple values:

{... "nwaf_ai_extra_host_wl": ["example.com", "a.example.com"] ...}

or

{... "nwaf_ai_extra_host_wl": ["example.com", "*.example.com"] ...}
nwaf_ai_extra_host_lm

A parameter that activates LM mode (monitoring mode) for requests defined by the Nemesida AI MLC module as illegitimate.

If the name of the virtual host from the request falls under the action of the parameter, then such a request is not recorded in the DBMS and is not blocked.

Example of using a single value:

{... "nwaf_ai_extra_host_lm": ["*"] ...}

or

{... "nwaf_ai_extra_host_lm": ["example.com"] ...}

or

{... "nwaf_ai_extra_host_lm": ["*.example.com"] ...}

Example of using multiple values:

{... "nwaf_ai_extra_host_lm": ["example.com", "a.example.com"] ...}

or

{... "nwaf_ai_extra_host_lm": ["example.com", "*.example.com"] ...}
nwaf_bf_detect_host_lm

A parameter that activates the LM mode for requests defined by the Nemesida AI MLC module as brute force attacks (BT 7) and flood (BT 9).

If the name of the virtual host from the request falls under the action of the parameter, then such a request is not recorded in the DBMS and is not blocked.

Example of using a single value:

{... "nwaf_bf_detect_host_lm": ["*"] ...}

or

{... "nwaf_bf_detect_host_lm": [".example.com"] ...}

or

{... "nwaf_bf_detect_host_lm": ["*.example.com"] ...}

Example of using multiple values:

{... "nwaf_bf_detect_host_lm": ["example.com", "*.example.org"] ...}
nwaf_ddos_detect_host_lm

A parameter that activates LM mode for requests defined by the Nemesida AI MLC module as DDoS attacks (BT 10).

If the name of the virtual host from the request falls under the action of the parameter, then such a request is not recorded in the DBMS and is not blocked.

Example of using a single value:

{... "nwaf_ddos_detect_host_lm": ["*"] ...}

or

{... "nwaf_ddos_detect_host_lm": [".example.com"] ...}

or

{... "nwaf_ddos_detect_host_lm": ["*.example.com"] ...}

Example of using multiple values:

{... "nwaf_ddos_detect_host_lm": ["example.com", "example.org"] ...}
nwaf_rmq_host_exclude

A parameter that excludes sending some requests to the RabbitMQ server (the nwaf queue).

If the name of the virtual host from the request falls under the action of the parameter, then such a request is not sent to the nwaf queue, and, accordingly, is not processed by the Nemesida AI MLC module (it is not analyzed for anomalies and brute force attacks, does not participate in the construction of behavioral models).

Example of using a single value:

{... "nwaf_rmq_host_exclude": ["*"] ...}

or

{... "nwaf_rmq_host_exclude": ["example.com"] ...}

or

{... "nwaf_rmq_host_exclude": ["*.example.com"] ...}

Example of using multiple values:

{... "nwaf_rmq_host_exclude": ["example.com", "a.example.com"] ...}

or

{... "nwaf_rmq_host_exclude": ["example.com", "*.example.com"] ...}
nwaf_body_exclude

A parameter that excludes the analysis of the BODY zone by the signature method, as well as sending its contents to the Nemesida AI MLA, Nemesida AI MLC and ClamAV modules. This option is useful if it is not possible to change the value of the client_body_buffer_size parameter in the /etc/nginx/nginx.conf file.

Example:

{... "nwaf_body_exclude": ["*"] ...}

or

{... "nwaf_body_exclude": ["*.example.com/uploads.php"] ...}

or

{... "nwaf_body_exclude": ["example.com/admin/*"] ...}

With the value example.com/uploads/* the occurrence of the URL will be taken, for example, example.com/uploads/aaaa or example.com/uploads/bbbbb.

Example of using multiple values:

{... "nwaf_body_exclude": ["*", "*.example.com/admin/*"] ...}

If you need to use the * sign as a common character when writing a URL, then you need to escape it, for example, writing example.com/admin/uploads/aa\*a will match example.com/admin/uploads/aa*a.

With the value *, the exclusion of the BODY zone analysis will be applied to any address.

nwaf_body_bin_exclude

A parameter that excludes the analysis of the BODY zone by the signature method, as well as sending its contents to the Nemesida AI MLA and Nemesida AI MLC modules. This option is useful if it is not possible to change the value of the client_body_buffer_size parameter in the /etc/nginx/nginx.conf file.

Example:

{... "nwaf_body_bin_exclude": ["*"] ...}

or

{... "nwaf_body_bin_exclude": ["*.example.com/uploads.php"] ...}

or

{... "nwaf_body_bin_exclude": ["example.com/admin/*"] ...}

With the value example.com/uploads/* the occurrence of the URL will be taken, for example, example.com/uploads/aaaa or example.com/uploads/bbbbb.

Example of using multiple values:

{... "nwaf_body_bin_exclude": ["*", "*.example.com/uploads.php"] ...}

If you need to use the * sign as a common character when writing a URL, then you need to escape it, for example, writing example.com/admin/uploads/aa\*a will match example.com/admin/uploads/aa*a.

With the value *, the exclusion of the BODY zone analysis will be applied to any address.

nwaf_post_body_exclude

The parameter that excludes the signature method from analyzing the contents of the BODY zone for POST requests, as well as sending the contents of the zone to the Nemesida AI MLA and Nemesida AI MLC modules. This option is useful when interacting with ownCloud web applications or similar ones that allow the client to upload a file to the server over the HTTP protocol.

Example of using a single value:

{... "nwaf_post_body_exclude": ["*"] ...}

or

{... "nwaf_post_body_exclude": ["example.com"] ...}

or

{... "nwaf_post_body_exclude": ["*.example.com"] ...}

Example of using multiple values:

{... "nwaf_post_body_exclude": ["example.com", "a.example.com"] ...}

or

{... "nwaf_post_body_exclude": ["example.com", "*.example.com"] ...}
nwaf_put_body_exclude

The parameter that excludes the signature method from analyzing the contents of the BODY zone for PUT requests, as well as sending the contents of the zone to the Nemesida AI MLA and Nemesida AI MLC modules. This option is useful when interacting with ownCloud web applications or similar ones that allow the client to upload a file to the server over the HTTP protocol.

Example of using a single value:

{... "nwaf_put_body_exclude": ["*"] ...}

or

{... "nwaf_put_body_exclude": ["example.com"] ...}

or

{... "nwaf_put_body_exclude": ["*.example.com"] ...}

Example of using multiple values:

{... "nwaf_put_body_exclude": ["example.com", "a.example.com"] ...}

or

{... "nwaf_put_body_exclude": ["example.com", "*.example.com"] ...}
nwaf_openapi_ip_wl

Illegitimate requests coming from a specific IP address and falling under the action of the parameter are not recorded in logs and are not blocked when analyzing a request for compliance with its specification in the OpenAPI format.

IPv4/IPv6 addresses are allowed, including the use of CIDR (for example, x.x.x.x/24) and a range of IP addresses.

Example:

{... "nwaf_openapi_ip_wl": ["10.0.0.1"] ...}

or

{... "nwaf_openapi_ip_wl": ["domain=*.example.com 10.0.0.1"] ...}

The domain value is optional.

Example of using multiple values:

{... "nwaf_openapi_ip_wl": ["10.0.0.1", "domain=*.example.com 10.0.0.1"] ...}

It is allowed to use strict matching and wildcard values: *, example.com, .example.com, *.example.com.

nwaf_openapi_ip_lm

Illegitimate requests coming from a specific IP address and falling under the action of the parameter are recorded in the logs, but are not blocked when analyzing the request for compliance with its specification in the OpenAPI format.

IPv4/IPv6 addresses are allowed, including the use of CIDR (for example, x.x.x.x/24) and a range of IP addresses.

Example:

{... "nwaf_openapi_ip_lm": ["10.0.0.1"] ...}

or

{... "nwaf_openapi_ip_lm": ["domain=*.example.com 10.0.0.1"] ...}

The domain value is optional.

Example of using multiple values:

{... "nwaf_openapi_ip_lm": ["10.0.0.1", "domain=*.example.com 10.0.0.1"] ...}

It is allowed to use strict matching and wildcard values: *, example.com, .example.com, *.example.com.

nwaf_openapi_url_wl

Illegitimate requests that arrive at a specific URL and fall under the action of the parameter are not recorded in logs and are not blocked when analyzing the request for compliance with its specification in the OpenAPI format.

Example:

{... "nwaf_openapi_url_wl": ["*"] ...}

or

{... "nwaf_openapi_url_wl": ["example.com/admin/*"] ...}

or

{... "nwaf_openapi_url_wl": ["example.com/admin/admin.php"] ...}

It is allowed to use strict matching and wildcard values to records a domain: *, example.com, .example.com, *.example.com.

With the value example.com/uploads/* the occurrence of the URL will be taken, for example, example.com/uploads/aaaa or example.com/uploads/bbbbb.

Example of using multiple values:

{... "nwaf_openapi_url_wl": ["*.example.com/admin/*", "example.com/admin/admin.php"] ...}

If you need to use the * sign as a common character when writing a URL, then you need to escape it, for example, writing example.com/admin/uploads/aa\*a will match example.com/admin/uploads/aa*a.

With the value *, the parameter will be applied to any URL.

nwaf_openapi_url_lm

Illegitimate requests that arrive at a specific URL and fall under the action of the parameter are recorded in logs, but are not blocked when analyzing the request for compliance with its specification in the OpenAPI format.

Example:

{... "nwaf_openapi_url_lm": ["*"] ...}

or

{... "nwaf_openapi_url_lm": ["example.com/admin/*"] ...}

or

{... "nwaf_openapi_url_lm": ["example.com/admin/admin.php"] ...}

It is allowed to use strict matching and wildcard values to records a domain: *, example.com, .example.com, *.example.com.

With the value example.com/uploads/* the occurrence of the URL will be taken, for example, example.com/uploads/aaaa or example.com/uploads/bbbbb.

Example of using multiple values:

{... "nwaf_openapi_url_lm": ["*.example.com/admin/*", "example.com/admin/admin.php"] ...}

If you need to use the * sign as a common character when writing a URL, then you need to escape it, for example, writing example.com/admin/uploads/aa\*a will match example.com/admin/uploads/aa*a.

With the value *, the parameter will be applied to any URL.

Get the hash sum of the current settings
Verification of the hash amount is required to confirm the relevance of the configuration. Changing the value means that the settings have been changed.

Request example:

# curl http://api.example.com:8080/nw-api/get_dyn_settings_hash --data 'key=%License key%'

Response example:

{'status': 'success', 'hash': '8ddd2b342d3190a866ee35afb249919a'}
Delete settings
Request example:

# curl http://api.example.com:8080/nw-api/v2/set_dyn_settings --header 'Content-type: application/json' --data '{
  "key": "%License key%",
  "del": ""
}'

Response example:

{"status": "success"}

or

{"status": "fail", "description": "%description%"}

🔗 Managing the list of blocked IP addresses

The functionality allows you to create lists for blocking requests based on the IP address of the request source.

Get a list of IP addresses to block
Request example:

# curl http://api.example.com:8080/nw-api/v2/get_dyn_bl --data 'key=%License key%'

Response format:

{
  "status": "success",
  "active": boolean,
  "modify": integer,
  "bl": [string, ...]
}

or

{"status": "fail", "description": "%description%"}

Response example:

{
  "status": "success",
  "active": true,
  "modify": 1719335019,
  "bl": ["domain=example.com 1.1.1.1 api=yes", ...]
}

Set a list of IP addresses to block
Request example:

# curl http://api.example.com:8080/nw-api/v2/set_dyn_bl --header 'Content-type: application/json' --data '{
  "key": "%License key%",
  "set": {
    "active": true,
    "bl": [
      "domain=example.com 1.1.1.1",
      "2.2.2.2",
      "3.3.3.0/24",
      "4.4.4.4-5.5.5.5 api=yes"
    ]
  }
}'

api=yes -parameter to send blocking events when accessed from the specified IP address to the Nemesida WAF API.

Requests from the IP address 1.1.1.1 will be blocked only for the domain example.com. Requests from IP addresses 2.2.2.2, 3.3.3.0/24 and 4.4.4.4-5.5.5.5 will be blocked for all domains, including example.com.

Response example:

{"status": "success"}

or

{"status": "fail", "description": "%description%"}
Get the hash sum of the current settings
Verification of the hash amount is required to confirm the relevance of the configuration. Changing the value means that the settings have been changed.

Request example:

# curl http://api.example.com:8080/nw-api/get_dyn_bl_hash --data 'key=%License key%'

Response example:

{'status': 'success', 'hash': '8ddd2b342d3190a866ee35afb249919a'}
Delete all IP addresses
Request example:

# curl http://api.example.com:8080/nw-api/v2/set_dyn_bl --header 'Content-type: application/json' --data '{
  "key": "%License key%",
  "del": ""
}'

Response example:

{"status": "success"}

or

{"status": "fail", "description": "%description%"}

🔗 Managing a list of automatically blocked IP addresses

The functionality allows you to manage a list of automatically blocked IP addresses for all filtering nodes.

Get a list of blocked IP addresses
Request example:

# curl http://api.example.com:8080/nw-api/get_dyn_sync_ban --data 'key=%License key%'

Response format:

{
  "status": "success",
  "ban_data": [
    {
      "ip-address": string,
      "ttl": integer,
      "is_banned": boolean,
      "domain": string,
      "timestamp": integer
    },
    ...
  ]
}

or

{"status": "fail", "description": "%description%"}

ip-address – ip address;
ttl – remaining blocking time in seconds;
is_banned – the parameter indicates whether the IP address is blocked;
domain is a virtual host (domain name), access to which is blocked for the IP address. DEFAULT means that requests to any virtual host are blocked for an IP address;
timestamp – the date the IP address was added to the list in the format Unix Timestamp.

Response example:

{
  "status": "success",
  "ban_data": [
    {
      "ip-address": "127.0.0.1",
      "ttl": 30,
      "is_banned": true,
      "domain": "example.com",
      "timestamp": 1730871907
    },
    ...
  ]
}
Delete an IP address from the list
Request example:

# curl http://api.example.com:8080/nw-api/del_dyn_sync_ban --header 'Content-type: application/json' --data '{
  "key": "%License key%",
  "ip-address": "127.0.0.1"
}'

ip-address – The IP address to delete in IPv4/IPv6 format. It is allowed to use * to delete all IP addresses.

Response example:

{"status": "success"}

or

{"status": "fail", "description": "%description%"}

🔗 Signature exclusion rules management

Allows configuring signature exclusion rules. Using the created exclusion rule, it is impossible to exclude the triggering of the extended request blocking rule. The following control commands are supported:

Get a list of the rules
Request example:

# curl http://api.example.com:8080/nw-api/v2/get_dyn_wl --data 'key=%License key%'

Response format:

{
  "status": "success",
  "wl": [
    {
      "active": boolean,
      "modify": integer,
      "id": integer,
      "mz": string,
      "rl_id": string,
      "domain": string,
      "extension": string
    }
  ]
}

or

{"status": "fail", "description": "%description%"}

Response example:

{
  "status": "success",
  "wl": [
    {
      "active": true,
      "modify": 1719335019,
      "id": 1,
      "mz": "ARGS",
      "rl_id": "1",
      "domain": "example.com",
      "extension": "$URL:/api/users/index.php|$BODY_X:id=[a-z0-9]+"
    }
  ]
}
Create the rule
Request example:

# curl http://api.example.com:8080/nw-api/v2/set_dyn_wl --header 'Content-type: application/json' --data '{
  "key": "%License key%",
  "add": {
    "active": true,
    "rl_id": "1",
    "domain": "example.com",
    "mz": ["url", "args"],
    "extension": ["$URL:/api/users/index.php", "$BODY_X:id=[a-zA-Z0-9]+"]
  }
}'

Response example:

{"status": "success", "id": 20}

or

{"status": "fail", "description": "%description%"}

The following parameters are available for management:

Supported parameters
Parameter
Description

active

The parameter activates/deactivates the exclusion rule.

Example:

{... "active": true ...}

rl_id

ID of the signature to which the exclusion rule applies. When using the value *, the exclusion rule will apply to all signatures. Required parameter.

Example:

{... "rl_id": "1" ...}

or

{... "rl_id": "*" ...}

domain
Setting the rule’s domain affiliation. For the domain option, strict matching and wildcard values are allowed: *, example.com, .example.com, *.example.com. Required parameter.

Example:

{... "domain": "example.com" ...}

or

{... "domain": "*" ...}

mz

The zone of application of the rule. Required parameter.

To apply a signature to multiple zones, use the separator: «mz:URL|BODY».

When using the value of NoMLA in the zone of application of the rules («mz:NoMLA»), the signature will not affect sending a request to the Nemesida AI MLA machine learning module for processing.

Example:

{... "mz": ["URL", "ARGS", "BODY", "HEADERS", "cookie", "user-agent", "content-type", "x-forward-for", "range", "referer", "NoMLA"] ...}

extension

Additional condition (clarification) of the application of the rule.

The clarification is applied as an occurrence of the specified template. Several clarifications interact with each other according to the principle of logical “and” (&) (for the rule to work, the main condition and all added clarifications must be met). Regular expressions can be used in clarifications using the _X postfix. For example, the regular expression $Cookie_X:id=[a-z0-9]+ is used in the refinement zone Cookie and will mean that the additional condition for triggering the exclusion rule will be the presence of a string (for example, id=abcd07dj45rff) in the Cookie zone, according to the regular expression pattern.

Example:

{... "extension": ["$BODY:abc|$Cookie_X:id=[a-z0-9]+"] ...}

Rashly adding signature exclusion rules is unsafe and can lead to omissions as well. Therefore, it is recommended to specify the conditions for triggering the rule as much as possible using clarifications.

Update the rule
Request example:

# curl http://api.example.com:8080/nw-api/v2/set_dyn_wl --header 'Content-type: application/json' --data '{
  "key": "%License key%",
  "upd": {
    "id": 20,
    "mz": ["URL"]
  }
}'

id – The ID of the rule that is generated when creating an excluson rule.

Response example:

{"status": "success"}

or

{"status": "fail", "description": "%description%"}
Get the hash sum of the current settings
Verification of the hash amount is required to confirm the relevance of the configuration. Changing the value means that the settings have been changed.

Request example:

# curl http://api.example.com:8080/nw-api/get_dyn_wl_hash --data 'key=%License key%'

Response example:

{'status': 'success', 'hash': '8ddd2b342d3190a866ee35afb249919a'}
Delete the rule
Request example:

# curl http://api.example.com:8080/nw-api/v2/set_dyn_wl --header 'Content-type: application/json' --data '{
  "key": "%License key%",
  "del": {
    "id": 8
  }
}'

id – The ID of the rule that is generated when creating an excluson rule.

Response example:

{"status": "success"}

or

{"status": "fail", "description": "%description%"}

🔗 Extended blocking rules

The mechanism of extended request blocking rules allows you to use additional conditions for a more accurate result when drawing up personal rules. For example, you can create the rule by which the request will be blocked if:

  • corresponds to a geographical location based on an IP address (determining the country by the attacker's IP address);
  • there is an appeal to a specific domain or URL;
  • contains a specific header (for example, User-Agent, Cookie, Referer, etc.) and/or the contents of these headers.

For a more accurate result, the parameters can be combined with each other. In this case, the rule will only work if all the conditions are met.

Supports the following control commands:

Get a list of the rules
Request example:

# curl http://api.example.com:8080/nw-api/v2/get_dyn_erl --data 'key=%License key%'

Response format:

{
  "status": "success",
  "erl": [
    {
      "active": boolean
      "id": integer,
      "ip": string,
      "lm": boolean,
      "ua": string,
      "api": boolean,
      "url": string,
      "args": string,
      "body": string,
      "noban": boolean,
      "cookie": string,
      "domain": string,
      "modify": integer,
      "country": string,
      "referer": string,
      "block_tor": boolean,
      "no_cookie": boolean,
      "block_proxy": boolean,
      "other_headers": string
    }
  ]
}

or

{"status": "fail", "description": "%description%"}

Response example:

{
  "status": "success",
  "erl": [
    {
      "active": true,
      "modify": 1730973337,
      "id": 100048,
      "ip": "127.0.0.1",
      "lm": true,
      "ua": "TW96aWxsYSA1LzA=",
      "api": true,
      "url": "L3VzZXJzL2xvZ2luLnBocA==",
      "args": "VVJM",
      "body": "c29tZV90ZXh0",
      "noban": true,
      "cookie": "aWQ9YW5ubWszNDU0R2Fmbmo2",
      "domain": "ZXhhbXBsZS5jb20=",
      "country": "UlU=|VVM=",
      "referer": "aHR0cDovL2V4YW1wbGUuY29t",
      "block_tor": true,
      "no_cookie": false,
      "block_proxy": true,
      "other_headers": "dXNlcl9JRA==:|YWRtaW4=|YWRtaW5pc3RyYXRvcg=="
    }
  ]
}
Create the rule
Request example:

# curl http://api.example.com:8080/nw-api/v2/set_dyn_erl --header 'Content-type: application/json' --data '{
  "key": "%License key%",
  "add": {
    "active": true,
    "ip": ["|1.1.1.1"],
    "lm": true,
    "ua": ["|TW96aWxsYSA1LzA="],
    "api": true,
    "url": ["L3VzZXJzL2xvZ2luLnBocA=="],
    "args": ["VVJM"],
    "body": ["|dGVzdF9ib2R5"],
    "noban": true,
    "cookie": ["|aWQ9YW5ubWszNDU0R2Fmbmo2"],
    "domain": ["|example.com"],
    "country": ["|RU", "|US"],
    "referer": ["|aHR0cDovL2V4YW1wbGUuY29t"],
    "block_tor": true,
    "no_cookie": false,
    "block_proxy": true,
    "other_headers": ["dXNlcl9JRA==:|YWRtaW4=|YWRtaW5pc3RyYXRvcg=="]
  }
}'
# curl http://api.example.com:8080/nw-api/v2/set_dyn_erl --header 'Content-type: application/json' --data '{
  "key": "%License key%",
  "add": {
    "active": true,
    "ip": ["|!1.1.1.0/24"],
    "domain": ["&example.com"]
  }
}'

The request will be blocked if on example.com a request will be received from any IP address except 1.1.1.1-1.1.1.255.

Due to the peculiarities of request processing, the functionality is not designed to work with a large number of IP addresses. If you need to block requests for a list of IP addresses, use the “Blocked IPs” functionality.

# curl http://api.example.com:8080/nw-api/v2/set_dyn_erl --header 'Content-type: application/json' --data '{
  "key": "%License key%",
  "add": {
    "active": true,
    "ip": ["|1.1.1.1"],
    "domain": ["|example.com"],
    "other_headers": [
      "dGVzdC1oZWFkZXI=:YWJj"
    ]
  }
}'

The request will be blocked by the rule if example.com a request will be received from the IP address 1.1.1.1 and the header test-header contains the string abc.

# curl http://api.example.com:8080/nw-api/v2/set_dyn_erl --header 'Content-type: application/json' --data '{
  "key": "%License key%",
  "add": {
    "active": true,
    "country": ["|RU", "|CH"],
    "domain": ["|example.com"],
    "other_headers": [
      "dGVzdC1oZWFkZXI=:YWJj"
    ],
    "cookie": ["|!dGVzdF9jb29raWU="],
    "referer": ["|!aHR0cDovL2V4YW1wbGUuY29t"]
  }
}'

The request will be blocked by the rule if a request for example.com will be received from an IP address, from the region RU or CH, the header test-header contains the string abc, the header Cookie does not contain the string test_cookie and the header Referer does not contain http://example.com.

# curl http://api.example.com:8080/nw-api/v2/set_dyn_erl --header 'Content-type: application/json' --data '{
  "key": "%License key%",
  "add": {
    "active": true
    "ip": ["|1.1.1.1"],
    "other_headers": [
      "VGVzdC1GaWVsZA==:"
    ],
    "referer": ["|aHR0cDovL2V4YW1wbGUuY29tLw=="],
    "ua": ["|TW96aWxsYS81LjA="],
    "cookie": ["|dGVzdF9jb29raWU="],
    "body": ["|YmM9MyZjYz0x"],
    "args": ["|P3BhZ2U9Mw=="],
    "url": ["|aW50ZXJuYWx0ZXN0"],
    "domain": ["|example.com"],
    "api": false,
    "country": ["|RU", "|CH"]
  }
}'

The request will be blocked by the rule if a request for example.com will be received from the IP address 1.1.1.1, from the region RU or CH, which will contain:

  • header Referer with http://example.com/ content;
  • header Test-Field with any content;
  • header User-Agent with Mozilla/5.0 content;
  • header Cookie with test_cookie content;
  • request body content bc=3&cc=1;
  • request argument ?page=3.

Response example:

{"status": "success", "id": 100053}

or

{"status": "fail", "description": "%description%"}

The following parameters are available for control:

Supported parameters
Parameter
Parameter description

active

The parameter activates/deactivates the rule.

Example:

{... "active": true ...}

ip

The IP address of the attacker from which the rule will be applied to the request.

IPv4/IPv6 addresses are allowed, including the use of CIDR (for example, x.x.x.x/24) and a range of IP addresses.

Example:

{... "ip": ["|1.1.1.1"] ...}

or

{... "ip": ["|1.1.1.1", "|2.2.2.2-3.3.3.3", "|10.0.0.0/24"] ...}

country

The country, determined based on GeoIP data, from which the request is received in the format of a two-letter country code. When using the value, RU, the rule based on GeoIP IP address data will be applied to requests from a Russian IP address.

Example:

{... "country": ["|RU", "|US"] ...}

domain

The name of the virtual host that the rule will be applied to when accessing.

Strict matching and wildcard values are allowed: *, example.com, .example.com, *.example.com.

Example:

{... "domain": ["|example.com", "|*.example.ru"] ...}

url

The occurrence of a string in the contents of the URL zone, at which the rule will be applied to the request.

The value for the parameter is sent in the Base64 format.

Example:

{... "url": ["|aW50ZXJuYWx0ZXN0", "|YWRtaW4vdXBsb2FkLnBocA==" ] ...}

args

The occurrence of a string in the contents of the ARGS zone, at which the rule will be applied to the request.

The value for the parameter is sent in the Base64 format.

Example:

{... "args": ["|P3BhZ2U9Mw==", "|dXNlcj1hZG1pbg=="] ...}

body

The occurrence of a string in the contents of the BODY zone, at which the rule will be applied to the request.

The value for the parameter is sent in the Base64 format.

Example:

{... "body": ["|dGVzdF9ib2R5", "|dXNlcj1hZG1pbg=="] ...}

cookie

The occurrence of a string in the contents of the Cookie zone, at which the rule will be applied to the request.

The value for the parameter is sent in the Base64 format.

Example:

{... "cookie": ["|UEhQU0VTU0lE", "|dGVzdF9jb29raWU="] ...}

To apply the rule correctly, it is forbidden to use the cookie and no_cookie options at the same time.


no_cookie

With the true value, the rule applies only to a request with an empty zone Cookie.

Example:

{... "no_cookie": true ...}

To apply the rule correctly, it is forbidden to use the cookie and no_cookie options at the same time.


ua

The occurrence of a string in the contents of the User-Agent zone, at which the rule will be applied to the request.

The value for the parameter is sent in the Base64 format.

Example:

{... "ua": ["|TW96aWxsYS81LjA=", "|TW96aWxsYS81LjQ="] ...}

referer

The occurrence of a string in the contents of the Referer zone, at which the rule will be applied to the request.

The value for the parameter is sent in the Base64 format.

Example:

{... "referer": ["|aHR0cDovL2V4YW1wbGUuY29t", "|aHR0cDovL3dlYi5leGFtcGxlLmNvbQ=="] ...}

other_headers

The occurrence of a string in the contents of the HEADERS zone, with the exception of the Cookie, User-Agent and Referer zones, in which the rule will be applied to the request.

The values of the header name and header content are sent in the Base64 format.

Example:

{... "other_headers": ["aGVhZGVyX25hbWU=:YWJj", "dGVzdC1oZWFkZXI=:YWJj"] ...}

For the other_headers field, the contents of the header_name and header_value sections are optional, but at least one of the sections must be specified. For example, if there is a header header_name, the contents of header_value will be checked only for the header header_name, and if not, the contents of all headers.

All elements of the list interact with each other according to the principle of logical “and” (&).

If header_name is set without header_value, then the rule will be applied at any value of the header header_name (blocking by the presence of the header).

Example:

{... "other_headers": ["aGVhZGVyX25hbWU=:"] ...}

More detailed information is available in the corresponding section of the manual.


block_tor

This parameter activates the rule for IP addresses that are the output node of the Tor network.

It is allowed to use the option without other parameters.

Example:

{... "block_tor": true ...}

block_proxy

The parameter activates the rule for IP addresses that are Proxy/VPN-service or exit node of the Tor network exit node of the Tor network.

It is allowed to use the option without other parameters.

Example:

{... "block_proxy": true ...}

api

With the value true, the rule trigger will be added to the attack report.

Example:

{... "api": true ...}

lm

With the value true, the triggering of the rule is recorded in the logs, but not blocked (monitoring mode).

Example:

{... "lm": true ...}

noban

With the true value, triggering the rule will not increase the rate counter of the IP address automatic blocking condition.

Example:

{... "noban": true ...}

For all parameters (except for parameters that support the values true/false), it is allowed to use multiple values in one parameter using the logical operators of the conditions “not” (!), “and” (&), “or” (|). The operators have no priority and are executed in turn, from left to right.

When checking whether the extended request blocking rule is triggered, all fields except ip, country, api, lm, noban, block_tor and block_proxy are checked for the contents of the field from the blocking rule to be included in the checked request field.

For example, with "url": ["base64(/abc)"], the request with the occurrence of /abcd in the URL will be blocked.

The rule is triggered only if all the conditions specified in the rule are met, otherwise the request will be skipped.

Other_headers working principle
The other_headers option allows you to set the header and its contents to verify compliance in the request (with the exception of the headers Cookie, User-Agent and Referer).

Format:

{... "other_headers": ["base64(header_name):base64(header_value)", "base64(header_name):base64(header_value)" ...] ...}

base64(header_name) – header name in base64;
base64(header_value) – header value in base64.

For the other_headers field, the contents of the base64(header_name) sections and base64(header_value) are optional, but you must specify at least one of the sections. For example, if there is a header header_name, the contents of header_value of only this header will be checked, and if there is no header, the contents of all headers will be checked.

All elements of the list interact with each other according to the principle of logical “and” (&).

Example:

{... "other_headers": ["base64(example1_header):", "base64(example2_header):"] ...}

With this value, the request will be blocked if there are headers example1_header and example1_header with any values.

Each list item cannot contain more than 1 headers name, but each headers name can have several values, which are separated by logical operators of the conditions “not” (!), “and” (&), “or” (|).

Example:

{... "other_headers": ["base64(example_header):base64(abcd)"] ...}

With this value, the request will be blocked if there is abcd in the example_header header.


Example:

{... "other_headers": [":base64(abcd)"] ...}

With this value, the request will be blocked if there is abcd in any header.


If base64(header_name) is specified without a subsequent value, then the request will be blocked at any value of the header header_name (blocking by the presence of the header).

Example:

{... "other_headers": ["base64(example_header):"] ...}

Example:

{... "other_headers": ["base64(example1_header):base64(abc)", "base64(example2_header):base64(def)"] ...}

With this value, the request will be blocked if there are headers example1_header, which contains abc and example2_header, which contains def.


The logical operator can be used for the header name!!, which means that there is no header with that name in the request. Blocking the request will work if there is no header with the specified name among all the request headers. At the same time, the header value is ignored, even if it is present in the rule.

Example:

{... "other_headers": ["!!base64(example_header):"] ...}

Example:

{... "other_headers": ["base64(example_header):base64(abc)&base64(def)"] ...}

With this value, the request will be blocked if there is a example_header header that contains abc and def.


Example:

{... "other_headers": ["base64(example_header):!base64(abc)"] ...}

With this value, the request will be blocked if there is a example_header header that does not contain abc.


Example:

{... "other_headers": ["base64(example_header):!base64(a)&!base64(b)&!base64(c)"] ...}

With this value, the request will be blocked if there is a example_header header that does not contain a, b and c.


Example:

{... "other_headers": ["base64(example_header):!base64(a)|base64(b)"] ...}

With this value, the request will be blocked if there is a example_header header that does not contain a or contains b.

Update the rule
Request example:

# curl http://api.example.com:8080/nw-api/v2/set_dyn_erl --header 'Content-type: application/json' --data '{
  "key": "%License key%",
  "upd": {
    "active": true
    "id": 1,
    "ip": ["|1.1.1.1"]
  }
}'

Response example:

{"status": "success"}

or

{"status": "fail", "description": "%description%"}
Get the hash sum of the current settings
Verification of the hash amount is required to confirm the relevance of the configuration. Changing the value means that the settings have been changed.

Request example:

# curl http://api.example.com:8080/nw-api/get_dyn_erl_hash --data 'key=%License key%'

Response example:

{'status': 'success', 'hash': '8ddd2b342d3190a866ee35afb249919a'}
Delete the rule
Request example:

# curl http://api.example.com:8080/nw-api/v2/set_dyn_erl --header 'Content-type: application/json' --data '{
  "key": "%License key%",
  "del": {
    "id": 1
  }
}'

Response example:

{"status": "success"}

or

{"status": "fail", "description": "%description%"}

🔗 Configuring Nemesida AI MLC

Allows managing the settings of the Nemesida AI MLC module. The following control commands are supported:

Get settings
Request example:

# curl http://api.example.com:8080/nw-api/v2/get_mlc_settings --data 'key=%License key%'

Response format:

{
  "status": "success",
  "active": boolean,
  "modify": integer,
  "main__ai_extra": boolean,
  "openapi__vhosts_list": [string, ...],
  "ddos__enable": boolean,
  "ddos__wl_ip": [string, ...],
  "ddos__wl_url": [string, ...],
  "ddos__interval": integer,
  "ddos__latest_only": boolean,
  "ddos__send_possible": boolean,
  "brute__enable": boolean,
  "brute__wl_ip": [string, ...],
  "brute__wl_host": [string, ...],
  "brute__brute_detect": [string, ...],
  "brute__flood_detect": [string, ...],
  "brute__bf_detect": [object, ...], 
  "brute__interval": integer,
  "brute__max_val": integer,
  "brute__latest_only": boolean,
  "brute__send_possible": boolean
}

or

{"status": "fail", "description": "%description%"}

Response example:

{
  "status": "success",
  "active": true,
  "modify": 1719335019,
  "main__ai_extra": true,
  "openapi__vhosts_list": ["example.com", ...],
  "ddos__enable": true,
  "ddos__wl_ip": ["127.0.0.1", ...],
  "ddos__wl_url": ["example.com/feed", ...],
  "ddos__interval": 120,
  "ddos__latest_only": true,
  "ddos__send_possible": true,
  "brute__enable": true,
  "brute__wl_ip": ["127.0.0.1", ...],
  "brute__wl_host": ["example.com", ...],
  "brute__brute_detect": ["example.com/auth", ...],
  "brute__flood_detect": ["example.com/auth", ...],
  "brute__bf_detect": [{"url": "*", "brute": true, "flood": false, "zone": ["args", "body"], "condition": {"body": ["auth_form", "user_login"]}}, ...], 
  "brute__interval": 30,
  "brute__max_val": 10,
  "brute__latest_only": true,
  "brute__send_possible": true
}
Set settings
Request example:

# curl http://api.example.com:8080/nw-api/v2/set_mlc_settings --header 'Content-type: application/json' --data '{
  "key": "%License key%",
  "set": {
    "active": true,
    "main__ai_extra": true,
    "openapi__vhosts_list": ["example.com", ...],
    "ddos__enable": true,
    "ddos__wl_ip": ["127.0.0.1", ...],
    "ddos__wl_url": ["example.com/feed", ...],
    "ddos__interval": 120,
    "ddos__latest_only": true,
    "ddos__send_possible": true,
    "brute__enable": true,
    "brute__wl_ip": ["127.0.0.1", ...],
    "brute__wl_host": ["example.com", ...],
    "brute__brute_detect": ["example.com/auth", ...],
    "brute__flood_detect": ["example.com/auth", ...],
    "brute__bf_detect": [{"url": "*", "brute": true, "flood": false, "zone": ["args", "body"], "condition": {"body": ["auth_form", "user_login"]}}, ...], 
    "brute__interval": 30,
    "brute__max_val": 10,
    "brute__latest_only": true,
    "brute__send_possible": true
  }
}'

Response example:

{"status": "success"}

or

{"status": "fail", "description": "%description%"}

The following parameters are available for control:

Supported parameters
Parameter
Parameter description

main__ai_extra

Activate/deactivate the additional request analysis functionality, which allows detecting missed attacks and temporarily blocking their source by IP address. If the additional analysis functionality is inactive, all unblocked requests will be included in the training sample (with the exception of requests that fall under the WL mode, or illegitimate requests that fall under the LM mode).

Example:

{... "main__ai_extra": true ...}

openapi__vhosts_list

The parameter specifies a list of virtual hosts for which specifications will be created in the OpenAPI format.

Example:

{... "openapi__vhosts_list": ["example.com", "example.ru"] ...}

Strict matching and wildcard values are allowed: *, example.com, .example.com, *.example.com.


ddos__enable
Activate/deactivatie of the DDoS attack detection.

Example:

{... "ddos__enable": true ...}
ddos__wl_ip
A parameter that defines the list of IP addresses for which the functionality will be disabled. IPv4/IPv6 addresses are allowed, including the use of CIDR (for example, x.x.x.x/24).

Example:

{... "ddos__wl_ip": ["1.1.1.1", "1.1.1.0/24", "1.1.1.0-1.1.2.254"] ...}
ddos__wl_url
The parameter that defines addresses both in the format vhost and vhost/path, where:

vhost – virtual host for which the DDoS detection will be disabled.
path – resource address occurrence.

Strict matching and wildcard values are allowed: example.com, .example.com, *.example.com.

Example:

{... "ddos__wl_url": ["example.com/feed", ".example.com"/feed, "*.example.com/feed", "*/feed"] ...}
ddos__interval
The time interval (in seconds) during which the request analysis is performed.

Example:

{... "ddos__interval": 120 ...}

An empty parameter will be set to the default value of 120 seconds.

ddos__latest_only
Activation of transmission to Nemesida WAF API of only the last blocked request for each IP address. If the value false, all blocked requests for each IP address are transmitted to the Nemesida WAF API.

Example:

{... "ddos__latest_only": true ...}
ddos__send_possible
Activation of the transmission mechanism in Nemesida WAF API requests with the type Possible DDoS. If the value false, requests to the Nemesida WAF API will not be transmitted.

Example:

{... "ddos__send_possible": true ...}

The prefix Possible is added to the name of the attack if its type has not been reliably established.


brute__enable
Activate/deactivate the brute force attacks detection.

Example:

{... "brute__enable": true ...}
brute__wl_host
Deactivation of the brute force attacks detection for specific virtual hosts. Strict matching and wildcard values are allowed: example.com, .example.com, *.example.com.

Example:

{... "brute__wl_host": ["example.com", ".example.org", "*.example.us"] ...}
brute__wl_ip
A parameter that defines the list of IP addresses for which the functionality will be disabled. IPv4/IPv6 addresses are allowed, including the use of CIDR (for example, x.x.x.x/24).
Example:

{... "brute__wl_ip": ["1.1.1.1", "1.1.1.0/24", "1.1.1.0-1.1.2.254"] ...}
brute__interval
The time interval (in seconds) during which the request analysis is performed.

Example:

{... "brute__interval": 30 ...}

An empty parameter will be set to the default value of 30 seconds.

brute__max_val
The number of requests from each specific IP address, when the value of which is reached, an analysis is performed for signs of an attack.

Example:

{... "brute__max_val": 10 ...}

An empty parameter will be set to the default value of 10 requests.

brute__brute_detect
A parameter that defines a list of addresses for detecting brute force attacks in the format host/path, where path is the occurrence of the resource address on the web server. Strict matching and wildcard values are allowed: example.com, .example.com, *.example.com.

Example:

{... "brute__brute_detect": ["example.com/auth", ".example.com/auth"] ...}

or

{... "brute__brute_detect": ["*.example.com/auth"] ...}

Thus, with the set value example.com/auth, brute force attacks will be monitored as for example.com/auth, and for example.com/auth/reset_password.

The parameter is used to detect brute force attacks, but does not block duplicate requests with the same content in the ARGS or BODY zones.

Use values without specifying the URL of a specific resource (for example, example.com or example.com/) is prohibited in order to ensure the correct operation of the option.

brute__flood_detect
The parameter has a similar functionality to the brute_detect parameter, but is designed to detect flood attempts or similar attacks with repeated requests. The only difference is that during the analysis of requests that fall under the action of the flood_detect parameter, duplicates are not deleted.

Thus, in case of repeated sending of identical requests (for example, multiple attempts to recover a password by SMS), requests with similar content and falling under the action of the flood_detect parameter will not be deleted, unlike requests with similar content, but falling under the action of the brute_detect parameter.
Example:

{... "brute__flood_detect": ["example.com/auth", ".example.com/auth"] ...}

or

{... "brute__flood_detect": ["*.example.com/auth"] ...}

Use values without specifying the URL of a specific resource (for example, example.com or example.com/) is prohibited in order to ensure the correct operation of the option.

brute__bf_detect
A parameter that defines a list of URLs for detecting brute force and flood attacks in the format vhost/path, where path is the occurrence of the resource address on the web server. Strict matching and wildcard values are allowed for the virtual host: example.com, .example.com, *.example.com.

Additional options are also supported for more flexible configuration of the launch condition of the analysis engine.

zone – allows you to set the analysis zone (ARGS, BODY). The analysis mechanism will be started only if the values from the condition option list are present in the selected zone.

Example:

"zone": ["args", "body"]

If the value is empty, the analysis will be activated for both zones.

condition – allows you to set a list of fields that must be present in the selected HTTP request zone (according to the value of the zone option) to get the request into the sample used by the analysis mechanism. The values of the option are combined according to the principle of logical “and” (&).

Example:

{..."zone": ["body"], "condition": ["auth_form", "user_login"]...}

this means that the request analysis mechanism will be activated only for queries where the auth_form and user_login fields with any values will be present in the BODY zone.

Example:

{...  "brute__bf_detect" :[{"url": "*", "brute": true, "flood": false, "zone": ["args", "body"], "condition": {"body": ["auth_form", "user_login"]}} ...}

Example of use with multiple values:

{..."brute__bf_detect" :[{"url": "*", "brute": true, "flood": false, "zone": ["body"], "condition": {"body": ["auth_form", "user_login"]}}, {"url": "example.com/abc", "brute": false, "flood": true, "zone": ["args", "body"], "condition": {"body": ["auth_form", "user_login"]}}]...}
brute__latest_only
Activation of transmission to Nemesida WAF API of only the last blocked request for each IP address. If the value false, all blocked requests for each IP address are transmitted to the Nemesida WAF API.

Example:

{... "brute__latest_only": true ...}
brute__send_possible
Activation of the transmission mechanism in Nemesida WAF API requests with the type Possible DDoS. If the value false, requests to the Nemesida WAF API will not be transmitted.

Example:

{... "brute__send_possible": true ...}

The prefix Possible is added to the name of the attack if its type has not been reliably established.


Get the hash sum of the current settings
Verification of the hash amount is required to confirm the relevance of the configuration. Changing the value means that the settings have been changed.

Request example:

# curl http://api.example.com:8080/nw-api/get_mlc_settings_hash --data 'key=%License key%'

Response example:

{'status': 'success', 'hash': '8ddd2b342d3190a866ee35afb249919a'}
Delete settings
Request example:

# curl http://api.example.com:8080/nw-api/v2/set_mlc_settings --header 'Content-type: application/json' --data '{
  "key": "%License key%",
  "del": ""
}'

Response example:

{"status": "success"}

or

{"status": "fail", "description": "%description%"}

🔗 Managing behavioral models

Incorrect training of behavioral models or significant changes in the web application can lead to a lot of false positives. To improve the accuracy of detecting attacks, it is recommended to retrain models once a week. The commands below allow you to perform actions on models.

Get virtual hosts list
Request example:

# curl http://api.example.com:8080/nw-api/v2/get_vhosts_list --data 'key=%License key%'

Response format:

{
  "status": "success",
  "vhosts_list": [string, ...]
}

Response example:

{
  "status": "success",
  "vhosts_list": ["example.com", ...]
}
Set virtual hosts list
Request example:

# curl http://api.example.com:8080/nw-api/v2/set_vhosts_list --header 'Content-type: application/json' --data '{
  "key": "%License key%",
  "vhosts_list": ["example.com", "example.org"]
}'

vhosts_list – list of virtual hosts for which models will be created and applied.

Response example:

{"status": "success"}

or

{"status": "fail", "description": "%description%"}

When creating a list of virtual hosts, wildcard values are allowed. The model is applied in the following order of priority from highest to lowest:

  • example.com — building and applying a domain model;
  • .example.com — building and applying a model for the example.com domain and its subdomains;
  • *.example.com — building and applying the model only for subdomains of the example.com domain, excluding the main domain;
  • * — building and applying a model for all domains.
Get a list of virtual hosts for which behavioral models are available
Request example:

# curl http://api.example.com:8080/nw-api/v2/get_models_list_uri --data 'key=%License key%'

Response format:

{
  "status": "success",
  "models": [string, ...]
}

Response example:

{
  "status": "success",
  "models": ["example.com", ...]
}
Delete a model for a virtual host example.com
Request example:

# curl http://api.example.com:8080/nw-api/v2/del_models_uri --header "Content-type: application/json" --data '{
  "key": "%License key%",
  "model": "example.com"
}'

model – the name of the behavioral model which you want to delete.

Response example:

{"status": "success"}

or

{"status": "fail", "description": "%description%"}
Additional training of models using a backup copy of the training sample
The correct construction of models requires about 400,000-800,000 unique requests. If the number of requests was insufficient during the training, then you can restart it and use the requests from the previous sample. To do this, follow these steps:

1. Stop the Nemesida AI MLC service:

# service mlc_main stop

2. Move the file /opt/mlc/ml/backup/[vhost].d_[timestamp], where [timestamp] is the date of creation of a backup copy of the training sample created by Nemesida AI MLC before starting the model construction, in /opt/mlc/ml/[vhost].d. For example, for the model example.com:

# mv /opt/mlc/ml/backup/example.com.d_1613587613 /opt/mlc/ml/example.com.d

3. Start the training:

# curl http://api.example.com:8080/nw-api/v2/set_training_uri --header "Content-type: application/json" --data '{
  "key": "%License key%",
  "vhost": "example.com",
  "duration": 4,
  "complete": false
}'

4. Launch the Nemesida AI MLC service:

# service mlc_main start
Copy a behavioral model for a virtual host
Request example:

# curl http://api.example.com:8080/nw-api/v2/rep_models_uri --header "Content-type: application/json" --data '{
  "key": "%License key%",
  "src_model": "example.com",
  "dst_model": "example.org"
}'

src_model is a virtual host whose behavioral model is being copied;
dst_model is a virtual host for which the model needs to be copied.

Response example:

{"status": "success"}

or

{"status": "fail", "description": "%description%"}
Get the model training status for a virtual host
Request example:

# curl http://api.example.com:8080/nw-api/v2/get_training_uri --data 'key=%License key%'

Response format:

{
  "status": "success",
  "training": [
    {
      "vhost": string,
      "duration": integer,
      "complete": boolean,
      "progress": integer
    },
    ...
  ]
}

Response example:

{
  "status": "success",
  "training": [
    {
      "vhost": "example.com",
      "duration": 4,
      "complete": false,
      "progress": 95
    },
    ...
  ]
}
Set for a virtual host example.com the training period is 4 days
Request example:

# curl http://api.example.com:8080/nw-api/v2/set_training_uri --header "Content-type: application/json" --data '{
  "key": "%License key%",
  "vhost": "example.com",
  "duration": 4,
  "complete": false
}'

duration – the training period in days.
complete – the training status of the model.

or

# curl http://api.example.com:8080/nw-api/v2/set_training_uri --header "Content-type: application/json" --data '{
  "key": "%License key%",
  "vhost": "example.com",
  "duration": 4
}'

or

# curl http://api.example.com:8080/nw-api/v2/set_training_uri --header "Content-type: application/json" --data '{
  "key": "%License key%",
  "vhost": "example.com",
  "complete": false
}'

Response example:

{"status": "success"}

or

{"status": "fail", "description": "%description%"}
Activate model training for a virtual host *.example.com
Request example:

# curl http://api.example.com:8080/nw-api/v2/set_training_uri --header "Content-type: application/json" --data '{
  "key": "%License key%",
  "vhost": "*.example.com",
  "duration": 4,
  "complete": false
}'

Response example:

{"status": "success"}

or

{"status": "fail", "description": "%description%"}
Set the training period and activate model training for the virtual host .example.com
Request example:

# curl http://api.example.com:8080/nw-api/v2/set_training_uri --header "Content-type: application/json" --data '{
  "key": "%License key%",
  "vhost": ".example.com",
  "duration": 2,
  "complete": false
}'

Executing a command with the value of the parameter complete: false allows you to start the process of retraining the model if it has been completed, and complete: true interrupts the learning process.

Before starting the model learning process, the virtual host must be added to the list of virtual hosts. The command that allows you to set a list of virtual hosts is given in the Nemesida AI MLC (Management commands) section.

Response example:

{"status": "success"}

or

{"status": "fail", "description": "%description%"}

Correcting the behavioral model
When processing requests by the machine learning module, false positives can rarely occur (blocking a legitimate request by the machine learning module). If they occur, you need to export requests to correct the application of the behavioral model.

Get a list of requests
Request example:

# curl http://api.example.com:8080/nw-api/get_mt_attack --header 'Content-type: application/json' --data '{
  "key": "%License key%",
  "startTime": 1730986421,
  "endTime": 1730987421,
  "limit": 100,
  "bt": [12, ...],
  "ip": ["127.0.0.1", ...],
  "cc": ["RU", ...],
  "vhost": ["example.com", ...],
  "method": ["GET", ...],
  "agent": ["MLA", ...],
  "mz": ["args", ...],
  "request_id": ["e19699c37b4c26f53a9fab3a24f573c8", ...],
  "bodyLimit": 1024,
  "url": ["example.com/index.php", ...],
  "args": ["abc", ...],
  "body": ["some_text", ...],
  "cookie": ["id=123jmci5", ...],
  "other_headers": ["user_ID=admin", ...],
  "referer": ["http://example.com", ...],
  "ua": ["Mozilla/5.0", ...],
  "search": ["abc", ...]
}'

Optional parameters:

  • startTime and endTime – the start and end date in Unix Timestamp format for which information will be requested;
  • limit – maximum number of displayed records;
  • bt – blocking identifier. The search is carried out according to the strict correspondence of each element of the list;
  • ip – IP address. The search is carried out according to the strict correspondence of each element of the list;
  • cc – country code. The search is carried out according to the strict correspondence of each element of the list;
  • vhost – virtual host, domain name. The search is carried out according to the strict correspondence of each element of the list;
  • method – method of sending the HTTP request. The search is carried out according to the strict correspondence of each element of the list;
  • agent – the name of the component that processed the request. The search is carried out according to the strict correspondence of each element of the list;
  • mz – anomaly detection zone. The search is carried out according to the strict correspondence of each element of the list;
  • request_id – the unique identifier of the request. The search is carried out according to the strict correspondence of each element of the list;
  • bodyLimit – the size of the output request body;
  • url – search for the occurrence of a string in the URL address. The search is performed by the occurrence of each item in the list;
  • args – search for the occurrence of a string in the query arguments. The search is performed by the occurrence of each item in the list;
  • body – search for the occurrence of a string in the request body. The search is performed by the occurrence of each item in the list;
  • cookie – search for the occurrence of a string in the Cookie header. The search is performed by the occurrence of each item in the list;
  • other_headers – search for the occurrence of a string in the headers (except for Cookie, User-Agent and Referer). The search is performed by the occurrence of each item in the list;
  • referer – search for the occurrence of a string in the Referer header. The search is performed by the occurrence of each item in the list;
  • ua – search for the occurrence of a string in the User-Agent header. The search is performed by the occurrence of each item in the list;
  • search – search for the occurrence of a string for each element from the list among the request zones (url, args, body, cookie, other_headers, referer, ua). The search is performed by the occurrence of each item in the list.

The search for values transmitted in the form of a list is performed according to the principle of logical OR.

Response format:

{
  "status": "success",
  "count": integer,
  "waf_id": string,
  "attacks": [
    {
      "id": integer,
      "timestamp": integer,
      "request_id": string,
      "agent": string,
      "mz": array,
      "bt": integer,
      "ip": string,
      "cc": string,
      "vhost": string,
      "method": string,
      "url": string,
      "args": string,
      "body": string,
      "cookie": string,
      "other_headers": string,
      "ua": string,
      "referer": string,
      "mz_origin": string
    },
    ...
  ]
}

or

{"status": "fail", "description": "%description%"}

Response example:

{
  "status": "success",
  "count": 104,
  "waf_id": 119835378,
  "attacks": [
    {
      "id": 1,
      "timestamp": 1730986421,
      "request_id": "e19699c37b4c26f53a9fab3a24f573c8",
      "agent": "MLA",
      "mz": ["args", ...],
      "bt": 12,
      "ip": "127.0.0.1",
      "cc": "RU",
      "vhost": "example.com",
      "method": "POST",
      "url": "/index.php",
      "args": "abc",
      "body": "some_text",
      "cookie": "id=123jmci5",
      "other_headers": "user_ID=admin",
      "ua": "Mozilla/5.0",
      "referer": "http://example.com",
      "mz_origin": "{'body': 'dW5pb24vKmFhYWFhKi9zZWxlY3Q='}"
    },
    ...
  ]
}
  • id – ID of the database record;
  • mz_origin – the original contents of the zones where the anomaly was detected.
Export the request
Request example:

# curl http://api.example.com:8080/nw-api/set_mt_fp --header 'Content-type: application/json' --data '{
  "key": "%License key%",
  "vhost": "example.com",
  "mz": "args",
  "mz_data": "abc"
}'

Required parameters:

  • vhost – virtual host, domain name;
  • mz – the area where the anomaly was detected;
  • mz_data – the contents of the zone where the anomaly was detected. Exporting with an empty field value is not allowed.

Response example:

{"status": "success", "id": %ID of the created record%}

or

{"status": "fail", "description": "%description%"}
Delete a request
Request example:

# curl http://api.example.com:8080/nw-api/del_mt_attack --header 'Content-type: application/json' --data '{
  "key": "%License key%",
  "id": [1, ...]
}'

Response example:

{"status": "success", "deleted": integer}

or

{"status": "fail", "description": "%description%"}

Required parameters:

  • id – ID of the database record.

The values passed as a list are applied according to the principle of logical OR.

Get a list of exported requests
Request example:

# curl http://api.example.com:8080/nw-api/get_mt_fp --header 'Content-type: application/json' --data '{
  "key": "%License key%",
  "limit": 100,
  "id": [1, ...],
  "vhost": ["example.com", ...]
}'

Optional parameters:

  • limit – maximum number of output records;
  • id – request ID. The search is carried out according to the strict correspondence of each element of the list;
  • vhost – virtual host, domain name.The search is carried out according to the strict correspondence of each element of the list.

The search for values transmitted in the form of a list is performed according to the principle of logical OR.

Response format:

{
  "status": "success",
  "count": integer,
  "waf_id": string,
  "fp": [
    {
      "id": integer,
      "timestamp": integer,
      "vhost": string,
      "mz": string,
      "mz_data": string
    },
    ...
  ]
}

or

{"status": "fail", "description": "%description%"}

Response example:

{
  "status": "success",
  "count": 25,
  "waf_id": 119835378,
  "fp": [
    {
      "id": 1,
      "timestamp": 173096451,
      "vhost": "example.com",
      "mz": "args",
      "mz_data": "abc"
    },
    ...
  ]
}
  • id – ID of the database record;
  • mz_data – the contents of the exported request zone.
Delete the exported request
Request example:

# curl http://api.example.com:8080/nw-api/del_mt_fp --header 'Content-type: application/json' --data '{
  "key": "%License key%",
  "id": [1, ...]
}'

Response example:

{"status": "success", "deleted": 3}

or

{"status": "fail", "description": "%description%"}

Required parameters:

  • id – ID of the database record.

The values passed as a list are applied according to the principle of logical OR.

Managing API Firewall settings
The functionality allows using API calls to manage API Firewall settings (create, edit, delete, view specifications, etc.).

Get the contents of all applied specifications
Request example:

# curl http://api.example.com:8080/nw-api/get_openapi_schemas --header 'Content-type: application/json' --data '{"key": "%License key%"}'

Response format:

{
  "schemas": [
    {
      "schema_name": string,
      "schema": string
    },
    ...
  ]
}

or

{"status": "fail", "description": "%description%"}

Response example:

{
  "schemas": [
    {
      "schema_name": "example.com",
      "schema": "b3BlbmFwaSBzY2hlbWEgaW4gYmFzZTY0"
    },
    ...
  ]
}
Get the hash sum of the current settings
Verification of the hash amount is required to confirm the relevance of the configuration. Changing the value means that the settings have been changed.

Request example:

# curl http://api.example.com:8080/nw-api/get_openapi_schemas_hash --header 'Content-type: application/json' --data '{"key": "%License key%"}'

Response example:

{'status': 'success', 'hash': '8ddd2b342d3190a866ee35afb249919a'}
Create or edit a specification
Request example:

# curl http://api.example.com:8080/nw-api/set_openapi_schema --header 'Content-type: application/json' --data '{
  "key": "%License key%",
  "set": {
    "schema_name": "example.com",
    "schema": "b3BlbmFwaSBzY2hlbWEgaW4gYmFzZTY0"
  }
}'

To work correctly, the domain name specified in the specification must be used as the name of the specification. For example, if the specification specifies the servers parameter with the value:

"servers": [
  {
    "url": "http://example.com"
  }
]

then the name of the specification must be example.com.

Strict matching and wildcard values are allowed: *, example.com, .example.com, *.example.com.

Response example:

{"status": "success"}

or

{"status": "fail", "description": "%description%"}
Set a list of URLs to check
Request example:

# curl http://api.example.com:8080/nw-api/set_openapi_url --header 'Content-type: application/json' --data '{
  "key": "%License key%",
  "url": [
    "example.com/admin",
    "example.com/admin/info",
    "example.com/v1/client/info"
  ]
}'

Response example:

{"status": "success"}

or

{"status": "fail", "description": "%description%"}
Get the hash sum of the current settings
Verification of the hash amount is required to confirm the relevance of the configuration. Changing the value means that the settings have been changed.

Request example:

# curl http://api.example.com:8080/nw-api/get_openapi_url_hash --header 'Content-type: application/json' --data '{"key": "%License key%"}'

Response example:

{'status': 'success', 'hash': '8ddd2b342d3190a866ee35afb249919a'}
Change specification name
Request example:

# curl http://api.example.com:8080/nw-api/set_openapi_schema --header 'Content-type: application/json' --data '{
  "key": "%License key%",
  "set": {
    "schema_name": "example.com",
    "old_name": "example.ru"
  }
}'

To work correctly, the domain name specified in the specification must be used as the name of the specification. For example, if the specification specifies the servers parameter with the value:

"servers": [
  {
    "url": "http://example.com"
  }
]

then the name of the specification must be example.com.

Strict matching and wildcard values are allowed: *, example.com, .example.com, *.example.com.

Response example:

{"status": "success"}

or

{"status": "fail", "description": "%description%"}
Delete a specification
Request example:

# curl http://api.example.com:8080/nw-api/set_openapi_schema --header 'Content-type: application/json' --data '{
  "key": "%License key%",
  "del": {
    "schema_name": "example.com"
  }
}'

Response example:

{"status": "success"}

or

{"status": "fail", "description": "%description%"}
Get a list of specifications created by Nemesida AI MLC
Request example:

# curl http://api.example.com:8080/nw-api/get_openapi_schema_paths --header 'Content-type: application/json' --data '{"key": "%License key%"}'

Nemesida AI MLC analyzes requests and automatically generates specifications for each request paths based on the corresponding list of virtual hosts.

Response format:

{
  "paths": [
    {
      "schema_name": string,
      "url": string,
      "schema": string
    },
    ...
  ]
}

or

{"paths": []}

Response example:

{
  "paths": [
    {
      "schema_name": "example.com",
      "url": "/index/",
      "schema": "b3BlbmFwaSBzY2hlbWEgaW4gYmFzZTY0"
    },
    ...
  ]
}

An example of a response with the decoded content of the specification:

{
  "paths": [
    {
      "schema_name": "example.com",
      "url": "/url_1/",
      "schema": {
        "example.com": {
          "/url_1/": {
            "post": {
              "requestBody": {
                "content": {
                  "*/*": {
                    "schema": {
                      "type": "object",
                      "properties": {
                        "id": {
                          "type": "integer"
                        },
                        "order": {
                          "type": "string"
                        }
                      },
                      "required": [
                        "id",
                        "order"
                      ]
                    }
                  }
                }
              }
            }
          }
        }
      }
    },
    ...
  ]
}
Exclude the URL when drawing up the specification
Request example:

# curl http://api.example.com:8080/nw-api/set_openapi_exclude_paths --header 'Content-type: application/json' --data '{
  "key": "%License key%",
  "set": {
    "exclude_paths": ["/url_1/", "/url_2/"]
  }
}'

Response example:

{"status": "success"}

or

{"status": "fail", "description": "%description%"}
Get a list of excluded URL
Request example:

# curl http://api.example.com:8080/nw-api/get_openapi_exclude_paths --header 'Content-type: application/json' --data '{"key": "%License key%"}'

Response format:

{
  "exclude_paths": [string, ...]
}

Response example:

{
  "exclude_paths": ["/url_1/", ...]
}
Get the hash sum of the current settings
Verification of the hash amount is required to confirm the relevance of the configuration. Changing the value means that the settings have been changed.

Request example:

# curl http://api.example.com:8080/nw-api/get_openapi_exclude_paths_hash --header 'Content-type: application/json' --data '{"key": "%License key%"}'

Response example:

{'status': 'success', 'hash': '8ddd2b342d3190a866ee35afb249919a'}

Managing Nginx Web Server settings
Using API calls, you can control Nginx settings. Each request must contain the License key of the installed copy of Nemesida WAF.

🔗 Nginx global settings

The section allows you to set global Nginx settings, which will be located in /etc/nginx/nwaf/conf/nginx/nginx.conf. Supports the following control commands:

Get settings
Request example:

# curl http://api.example.com:8080/nw-api/nginx/get_nginx --data 'key=%License key%'

Response format:

{
  "status": "success",
  "configuration": [
    {
      "active": boolean,
      "resolver": string,
      "limit_req_zone": [string, ...],
      "real_ip_header": string,
      "resolver_timeout": string,
      "set_real_ip_from": [string, ...],
      "client_max_body_size": string
    }
  ]
}

or

{"status": "fail", "description": "%description%"}

Response example:

{
  "status": "success",
  "configuration": [
    {
      "active": true,
      "resolver": "127.0.0.1 [::1]:5353 valid=30s",
      "limit_req_zone": ["$binary_remote_addr zone=mylimit_1:10m rate=10r/s", ...],
      "real_ip_header": "X-Forwarded-For",
      "resolver_timeout": "30s",
      "set_real_ip_from": ["192.168.1.0/24", ...],
      "client_max_body_size": "100m"
    }
  ]
}
Set settings
Request example:

# curl http://api.example.com:8080/nw-api/nginx/set_nginx --header 'Content-type: application/json' --data '{
  "key": "%License key%",
  "set": {
    "active": true,
    "resolver": "127.0.0.1 [::1]:5353 valid=30s",
    "resolver_timeout": "30s",
    "set_real_ip_from": [
      "192.168.1.0/24",
      "192.168.2.1"
    ],
    "real_ip_header": "X-Forwarded-For",
    "client_max_body_size": "100m",
    "limit_req_zone": [
      "$binary_remote_addr zone=mylimit_1:10m rate=10r/s",
      "$binary_remote_addr zone=mylimit_2:10m rate=10r/s"
    ]
  }
}'

Response example:

{"status": "success"}

or

{"status": "fail", "description": "%description%"}

The following parameters are available for management:

Supported parameters
Parameter
Description

The DNS server address. The value valid (in seconds) means how long the DNS server response will be considered valid.

Example:

{... "resolver": "127.0.0.1 [::1]:5353 valid=30s" ...}

The parameter sets the value during which Nginx will wait for a response from the DNS server.

Example:

{... "resolver_timeout": 30 ...}

The parameter specifies trusted addresses that transmit the correct replacement address. Trusted addresses can also be set using the hostname.

Example:

{... "set_real_ip_from": ["192.168.1.0/24", "192.168.2.1", "2001:0db8::/32", "unix:/tmp/app.sock"] ...}

IPv6 and IPv4 addresses are allowed.

Specifies the request header field whose value will be used to replace the client’s address.

Example:

{... "real_ip_header": "X-Forwarded-For" ...}

The parameter specifies the maximum allowed size of the client request body. If the size is larger than the specified one, error 413 (Request Entity Too Large) is returned to the client. Setting the parameter with the value 0 disables checking the size of the client request body.

Example:

{... "client_max_body_size": 100 ...}

Specifies the parameters of the shared memory zone that stores the state for different key values. Text, variables and their combinations can be used as a key. Requests with an empty key value are ignored.

Example:

{... "limit_req_zone": ["$binary_remote_addr zone=mylimit_1:10m rate=10r/s", "$binary_remote_addr zone=mylimit_2:10m rate=10r/s"] ...}
Get the hash sum of the current settings
Verification of the hash amount is required to confirm the relevance of the configuration. Changing the value means that the settings have been changed.

Request example:

# curl http://api.example.com:8080/nw-api/nginx/get_nginx_hash --data 'key=%License key%'

Response example:

{"status": "success", "hash": "8ddd2b342d3190a866ee35afb249919a"}
Reset settings
Request example:

# curl http://api.example.com:8080/nw-api/nginx/set_nginx --header 'Content-type: application/json' --data '{
  "key": "%License key%",
  "set": {
    "resolver": null,
    "resolver_timeout": null,
    "set_real_ip_from": null,
    "real_ip_header": null,
    "client_max_body_size": null,
    "limit_req_zone": null
  }
}'

Response example:

{"status": "success"}

or

{"status": "fail", "description": "%description%"}

🔗 Virtual host settings

The name parameter is the name of the configuration that will be located in /etc/nginx/nwaf/conf/nginx/%name%.conf.

The section is intended for configuring the virtual host file. Supports the following control commands:

Get settings
Request example:

# curl http://api.example.com:8080/nw-api/nginx/get_vhost --data 'key=%License key%'

Response format:

{
  "status": "success",
  "configuration": [
    {
      "active": boolean,
      "name": string,
      "root": string,
      "index": string,
      "listen": [string, ...],
      "add_header": {string, ...},
      "error_page": {string, ...},
      "locations": [
        {
          "location": string,
          "pass_type": string,
          "path": string,
          "index": string,
          "add_header": {string, ...},
          "error_page": {string, ...},
          "limit_req": string,
          "limit_req_status": integer
        },
        ...
      ],
      "server_name": string,
      "ssl_ciphers": string,
      "dhparam_name": string,
      "ssl_protocols": string,
      "certificate_name": string,
      "ssl_session_timeout": string
    }
  ]
}

or

{"status": "fail", "description": "%description%"}

Response example:

{
  "status": "success",
  "configuration": [
    {
      "active": true,
      "name": "example.com",
      "root": "/var/www/site",
      "index": "index index.html index.php",
      "listen": ["localhost:443 default_server ssl http2", ...],
      "add_header":{
        "Content-type": "text/html; charset=utf-8",
        ...
      },
      "error_page": {
        "404 502": "=200 /404.html",
        ...
      },
      "locations": [
        {
          "location": "/static_1",
          "pass_type": "root",
          "path": "/var/www/html",
          "index": "index index.html index.php",
          "add_header":{
            "Content-type": "text/html; charset=utf-8",
            ...
          },
          "error_page": {
            "404 502": "=200 /404.html",
            ...
          },
          "limit_req": "zone=mylimit_1 burst=20 nodelay",
          "limit_req_status": 444
        },
        ...
      ],
      "server_name": "www.example.com example.com",
      "ssl_ciphers": "AES128-SHA:AES256-SHA:RC4-SHA:DES-CBC3-SHA:RC4-MD5",
      "dhparam_name": "dhparam",
      "ssl_protocols": "TLSv1 TLSv1.1 TLSv1.2",
      "certificate_name": "SSL",
      "ssl_session_timeout": "10m"
    }
  ]
}
Set settings
Request example:

# curl http://api.example.com:8080/nw-api/nginx/set_vhost --header 'Content-type: application/json' --data '{
  "key": "%License key%",
  "set": {
    "active": true,
    "name": "%Configuration name%",
    "listen": [
      "localhost:80 default_server",
      "[::1]:443 default_server ssl http2"
    ],
    "server_name": "www.example.com example.com",
    "certificate_name": "%name%",
    "dhparam_name": "%name%",
    "ssl_session_timeout": "10m",
    "ssl_ciphers": "AES128-SHA:AES256-SHA:RC4-SHA:DES-CBC3-SHA:RC4-MD5",
    "ssl_protocols": "TLSv1 TLSv1.1 TLSv1.2",
    "root": "/var/www/site",
    "index": "index.php index.html",
    "add_header": {
      "Content-Encoding": "gzip",
      "Content-type": "text/html; charset=utf-8"
    },
    "error_page": {
      "404 502": "=200 /404.html",
      "504": "=200 @bad_gateway"
    },
    "locations": [
      {
        "location": "/static_1",
        "pass_type": "root",
        "path": "/var/www/html",
        "index": "index.php",
        "add_header": {
          "Content-Encoding": "gzip",
          "Content-type": "text/html; charset=utf-8"
        },
        "error_page": {
          "504": "=200 @bad_gateway",
          "404 502": "=200 /404.html"
        },
        "limit_req": "zone=mylimit_1 burst=20 nodelay",
        "limit_req_status": 444
      },
      {
        "location": "/static_2",
        "pass_type": "alias",
        "path": "/var/www/static_2",
        "autoindex": "on",
        "limit_req": "zone=mylimit_1 burst=20 nodelay",
        "limit_req_status": 444
      },
      {
        "location": "/abc_1",
        "pass_type": "proxy_pass",
        "proxy_pass": "http://main_proxy",
        "proxy_http_version": 1.0,
        "proxy_set_header": {
          "X-Real_IP": "$remote_address",
          "Host": "$http_host"
        },
        "proxy_connect_timeout": "60s",
        "proxy_send_timeout": "60s",
        "proxy_read_timeout": "60s",
        "proxy_intercept_errors": "on",
        "limit_req": "zone=mylimit_1 burst=20 nodelay",
        "limit_req_status": 444
      },
      {
        "location": "/abc_2",
        "pass_type": "memcached_pass",
        "memcached_pass": "memc_upstream",
        "limit_req": "zone=mylimit_1 burst=20 nodelay",
        "limit_req_status": 444
      }
    ]
  }
}'

Response example:

{"status": "success"}

or

{"status": "fail", "description": "%description%"}

The following parameters are available for management:

Supported parameters
Parameter
Description
name

Configuration name.

The parameter specifies the address which the server will accept requests.

The address can be specified as a domain name/IP address and port (optional), port only, or as a UNIX socket path.

127.0.0.1:8000
127.0.0.1
8000
*:8000
localhost:8000
[::]:8000
[::1]
unix:/var/run/nginx.sock

The value default_server, means that the server will be the default server for the specified pair address:port. If there is no default_server parameter, then the default server will be the first server that describes the address:port pair.

The ssl parameter indicates that all connections received on this port should work in SSL mode. This allows you to set a compact configuration for a server running in two modes at once — HTTP and HTTPS.

The http2 parameter allows accepting HTTP/2 connections on this port. Usually, you should also specify the ssl parameter, but Nginx can also be configured to accept HTTP/2 connections without SSL.

Example:

"listen": ["[::1]:443 default_server ssl http2"]

Server name.

It is allowed to use wildcard values to replace the first or last part of the name.

certificate_name

The canonical name of the SSL certificate and private key for the server. The name is set at creation, in the section settings SSL certificates.

The canonical name of the pem file required for the operation of the Forward Secret (if an attacker learns any session key, he will be able to access only the data protected by this key). The name is set during creation in the section settings DHParam.

The parameter specifies the time during which the client can reuse the session parameters.

The parameter specifies the allowed ciphers. Ciphers are set in a format supported by the OpenSSL library.

The parameter allows the use of the specified protocols.

The parameter specifies the root directory for requests.

The parameter defines the files to be used as an index. Variables can be used in the file name. The presence of files is checked in the order they are listed. At the end of the list there may be a file with an absolute path.

The parameter defines the list of used location for the virtual host and their parameters. Parameter setting involves the use of required and optional parameters.

Required:

location – the prefix that will be used for comparison with the URI of the request.

Example:

"location": "/"
"location": "/user/"

proxy_type – the type of request processing.
Supported are 4 types of processing: root, alias, proxy_pass, memcached_pass.

  • root – processing requests on a local web server. When using this type of request processing, you must use the path option to specify the root directory for requests.

    Example:

    "path": "/var/www/site"
    

    For path /var/www/site and location /user/ resource request /user/index.html will return the contents of the file /var/www/site/user/index.html.

    Optional:
    index – files to be used as an index. Variables can be used in the file name. The presence of files is checked in the order they are listed. At the end of the list there may be a file with an absolute path. If the parameter is not specified, the default value of the parameter from the server section will be used.

    Example:

    "index": "index index.html index.php"
    

    autoindex – permission to list the catalog.

    Example:

    "autoindex": "on"
    

    add_header – sets the callback field for the response, provided the response code is 200, 201, 204, 206, 301, 302, 303, 304, 307 or 308. If the always parameter is set, the header field will be added regardless of the response code.

    Example:

    "Content-Encoding": "gzip",
    "Content-Type": "text/html; charset=utf-8"
    

    error_page – sets the URI to be displayed for the specified errors. Variables can be used in the URI value.

    Example:

    "504": "=200 @bad_gateway",
    "404 502": "=200 /404.html"
    
  • alias – the path that will replace the specified location. When using this type of request processing, you must use the path option to specify a directory for requests.

    Example:

    "path": "/var/www/site"
    

    For alias /var/www/site and location /user/ resource request /user/index.html will return the contents of the file /var/www/site/index.html.

  • proxy_pass – the address of the proxied server to which requests will be redirected when accessing location.

    The address can be specified in the form of a domain name/IP address and port (optional), a UNIX socket or an upstream name. It is allowed to add URI to the server address.

    Example:

    "proxy_pass": "http://127.0.0.1:8080/remote/"
    "proxy_pass": "http://unix:/tmp/backend.socket:/uri/"
    "proxy_pass": "http://upstream_name"
    

    Optional:
    proxy_http_version – the version of the HTTP protocol for proxying. The default version is 1.0.

    Example:

    "proxy_http_version": 1.0
    

    proxy_connect_timeout – timeout for establishing a connection with the proxied server.

    Example:

    "proxy_connect_timeout": "60s"
    

    proxy_intercept_errors – when the parameter is activated, responses from a proxied server with a response code of 300 or higher will be intercepted and redirected for processing using the error_page.

    Example:

    "proxy_intercept_errors": "on"
    

    proxy_send_timeout – timeout when sending a request to a proxied server.

    Example:

    "proxy_send_timeout": "60s"
    

    proxy_read_timeout – timeout when reading the response of the proxied server.

    Example:

    "proxy_read_timeout": "60s"
    
  • memcached_pass – the address of the memcached server where requests will be redirected when accessing location.

    The address can be specified in the form of a domain name/IP address and port (required), a UNIX socket, or an upstream name.

    Example:

    "memcached_pass": "localhost:11211"
    "memcached_pass": "unix:/tmp/memcached.socket"
    "memcached_pass": "http://upstream_name"
    

Optional:

limit_req – the shared memory zone (zone) and the maximum size of the burst of requests (burst). If the rate of receipt of requests exceeds the one described in the zone, then their processing is delayed so that requests are processed at the specified speed.

Example:

"limit_req": "zone=mylimit_1 burst=20 nodelay"

The parameter must first be set in the Nginx global settings.

limit_req_status – the response code used when rejecting requests.

Example:

"limit_req_status": 444
Get the hash sum of the current settings
Verification of the hash amount is required to confirm the relevance of the configuration. Changing the value means that the settings have been changed.

Request example:

# curl http://api.example.com:8080/nw-api/nginx/get_vhost_hash --data 'key=%License key%'

Response example:

{"status": "success", "hash": "8ddd2b342d3190a866ee35afb249919a"}
Reset settings
Request example:

# curl http://api.example.com:8080/nw-api/nginx/set_vhost --header 'Content-type: application/json' --data '{
  "key": "%License key%",
  "set": {
    "name": "%Configuration name%",
    "listen": null,
    "server_name": null,
    "certificate_name": null,
    "dhparam_name": null,
    "ssl_session_timeout": null,
    "ssl_ciphers": null,
    "ssl_protocols": null,
    "root": null,
    "index": null,
    "add_header": null,
    "error_page": null,
    "locations": null
  }
}'

Response example:

{"status": "success"}

or

{"status": "fail", "description": "%description%"}
Delete configuration
Request example:

# curl http://api.example.com:8080/nw-api/nginx/set_vhost --header 'Content-type: application/json' --data '{
  "key": "%License key%",
  "del": {
    "name": "%Configuration name%"
  }
}'

Response example:

{"status": "success"}

or

{"status": "fail", "description": "%description%"}

🔗 Upstream settings

The name parameter is the name of the configuration with load balancing parameters that will be located in /etc/nginx/nwaf/conf/nginx/%name%.conf.

The section is intended for configuring load balancing parameters. Supports the following control commands:

Get settings
Request example:

# curl http://api.example.com:8080/nw-api/nginx/get_upstream --data 'key=%License key%'

Response format:

{
  "status": "success",
  "configuration": [
    {
      "name": string,
      "balancing_method": string
      "servers": [
        {
          "server": string,
          "weight": integer,
          "max_fails": integer,
          "fail_timeout": string,
          "backup": boolean,
          "down": boolean
        },
        ...
      ]
    }
  ]
}

or

{"status": "fail", "description": "%description%"}

Response example:

{
  "status": "success",
  "configuration": [
    {
      "name": "upstream_main",
      "balancing_method": "ip_hash"
      "servers": [
        {
          "server": "backend1.example.com",
          "weight": 3,
          "max_fails": 5,
          "fail_timeout": "60s",
          "backup": false,
          "down": true
        },
        ...
      ]
    }
  ]
}
Set settings
Request example:

# curl http://api.example.com:8080/nw-api/nginx/set_upstream --header 'Content-type: application/json' --data '{
  "key": "%License key%",
  "set": {
    "name": "%Configuration name%",
    "balancing_method": "ip_hash",
    "servers": [
      {
        "server": "backend1.example.com",
        "weight": 3
      },
      {
        "server": "127.0.0.1:8080",
        "fail_timeout": "60s"
      },
      {
        "server": "192.0.2.1",
        "max_fails": 5
      },
      {
        "server": "backend3.example.com",
        "weight": 3,
        "fail_timeout": "60s",
        "max_fails": 5
      },
      {
        "server": "backend4.example.com"
      },
      {
        "server": "backend5.example.com",
        "backup": true
      },
      {
        "server": "backend4.example.com",
        "down": true
      }
    ]
  }
}'

Response example:v

{"status": "success"}

or

{"status": "fail", "description": "%description%"}

The following parameters are available for management:

Supported parameters
Parameter
Description

The name of the server group for load balancing.

balancing_method

The method of load distribution between servers. It is allowed to use one of the values: ip_hash, least_conn or random.

A list of servers that are used to process requests, as well as their parameters:

  • server – server address. The address can be specified as a domain name/IP address and port (optional), or as a UNIX socket path. IPv6 and IPv4 addresses are allowed;
  • weight – numerical indicator of the priority of server selection when processing a request;
  • fail_timeout – the time (in seconds) during which the specified number of failed attempts to work with the server must occur in order for the server to be considered unavailable;
  • max_fails – the maximum number of failed attempts to communicate with the server during the time specified by the fail_timeout parameter;
  • down – marks the server as permanently unavailable;
  • backup – marks the server as a spare. Requests will be sent to it if the main servers are not working.
Reset settings
Request example:

# curl http://api.example.com:8080/nw-api/nginx/set_upstream --header 'Content-type: application/json' --data '{
  "key": "%License key%",
  "set": {
    "name": "%Configuration name%",
    "balancing_method": null,
    "servers": null
  }
}'

Response example:

{"status": "success"}

or

{"status": "fail", "description": "%description%"}
Get the hash sum of the current settings
Verification of the hash amount is required to confirm the relevance of the configuration. Changing the value means that the settings have been changed.

Request example:

# curl http://api.example.com:8080/nw-api/nginx/get_upstream_hash --data 'key=%License key%'

Response example:

{"status": "success", "hash": "8ddd2b342d3190a866ee35afb249919a"}
Delete configuration
Request example:

# curl http://api.example.com:8080/nw-api/nginx/set_upstream --header 'Content-type: application/json' --data '{
  "key": "%License key%",
  "del": {
    "name": "%Configuration name%"
  }
}'

Response example:

{"status": "success"}

or

{"status": "fail", "description": "%description%"}

🔗 SSL certificates settings

The name parameter is the name of the configuration for SSL certificates and their private keys, which will be located in /etc/nginx/nwaf/conf/nginx/ssl/certs/%name%.crt and /etc/nginx/nwaf/conf/nginx/ssl/private/%name%.key.

For security reasons, executing the get configuration command does not return the full contents of the certificate_key field. Full information about the private key certificate_key is requested by the Nemesida AI MLA component at the URL http://api.example.com:8080/nw-api/nginx/secure/get_certificate, access to which is recommended to be allowed only for the filtering node server.

The section is intended for configuring the parameters of SSL certificates and their private keys. Supports the following control commands:

Get settings
Request example:

# curl http://api.example.com:8080/nw-api/nginx/get_certificate --data 'key=%License_key%'

Response format:

{
  "status": "success",
  "configuration": [
    {
      "name": string,
      "certificate": string,
      "certificate_key": string
    }
  ]
}

or

{"status": "fail", "description": "%description%"}

Response example:

{
  "status": "success",
  "configuration": [
    {
      "name": "SSL",
      "certificate": "LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS...",
      "certificate_key": "LS0tLS1CRUdJTiBQUklWQVRF..."
    }
  ]
}
Set settings
Request example:

# curl http://api.example.com:8080/nw-api/nginx/set_certificate --header 'Content-type: application/json' --data '{
  "key": "%License key%",
  "set": {
    "name": "%Configuration name%",
    "certificate": "LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSURVekNDQWpzQ0ZGei9jNjhLYk9USnlYOWpibWZMbjdmK1YwdWtNQTBHQ1NxR1NJYjNEUUVCQ3dVQU1IOHgKQ3pBSkJnTlZCQVlUQWtGVk1RNHdEQVlEVlFRSURBVkJVMEZGUmpFTk1Bc0dBMVVFQnd3RVQzSmxiREVSTUE4RwpBMVVFQ2d3SVUxTlNSMEZCUldZeERqQU1CZ05WQkFzTUJYTnlaWFJuTVE0d0RBWURWUVFEREFWM1pUUm1aekVlCk1Cd0dDU3FHU0liM0RRRUpBUllQWVdSdGFXNUFZV1J0YVc0dVkyOXRNQjRYRFRJek1EY3hOekV3TlRZME0xb1gKRFRJMk1EUXhNVEV3TlRZME0xb3dUVEVMTUFrR0ExVUVCaE1DUTBFeERUQUxCZ05WQkFnTUJFNXZibVV4Q3pBSgpCZ05WQkFjTUFrNUNNUTB3Q3dZRFZRUUtEQVJPYjI1bE1STXdFUVlEVlFRRERBcGxlR0Z0Y0d4bExuSjFNSUlCCklqQU5CZ2txaGtpRzl3MEJBUUVGQUFPQ0FROEFNSUlCQ2dLQ0FRRUFySitBMkZ3cHFjMDhNVnRhVzZKeUsvbDkKQy9NWXFJRXZtRjZvdUt5V01ZRWFGMmlPK0l2VG1pN2hETkxQakR2ekhKRHJMYTZycjhJMkdMN0Nxdi9tdkN5NQpKZVBaSVZxeU9PQ0NLUEJFVXFrUkl4NUwvQ0hLMnVieHlxL1ZIWUExRysxanVqNzNINXZqUHM4anRyeFFNVG5OCkNacVBycmdoOTRlU0ViRmpER2JyZGlGSFpURmwyT01QdTlBVEJoRjF3dStwYS8yN3BJVm91S21BTnVTa0pTaUoKM29wRTkzZFJDYkUvWVhoTjJKTlNjdmdzcjBVbXBRd2t5VDJ4bGVKbHV0Sm5PZkZiK1NsdWFHVlloOUtncEwrcQorN2x3MFk0OEtYNnJGeXUzNko1RjBxNUN6T1hoMS9BZWFneStJQTdGanVSOU9tTFEvQVlwSGE1QmZMK0Fid0lECkFRQUJNQTBHQ1NxR1NJYjNEUUVCQ3dVQUE0SUJBUUNnV1VGTVZrMkVSaHF3WGpBT0YxVCt1cWZJM3pKZkVrTHAKYlZieW90d2dRMnZPU2VZdlAyU1dqdjZCMDExZEFONWNYTUIvOFhOVEdhdUNSajN1cEtTTUtvd1JaY1hjdUlKMApocUNDc01JZGw1bDFBQVFJWCtPTTJTeEpKdHVRK0dkWlhkQ294RStzN20zSHNCQ3UwbWRzY3doU0hGSnRmbXRhCit6eFJ4VmY5QkU3NDJSUE5ydXNFZmxwdVQ2Rm14QkpMUy9WYzVLOWtQMngwdjZQTjZYMUF4M09vRGhrQ3Nma2cKeXpwSFhtK3J1ZWJmcnNvcFdwUzJBM083T09CRk1lTVhZeHl3WjJUR2hmanh3R3ZGZml0ZnhFNnpTUnZnQ1A5WQphaUM5RUlMSXpodUdDNDFXNFFZYTJBUzNoaVF4Qms0eDcyeGZ1cXpmc212OE5Zd0lzY3BxCi0tLS0tRU5EIENFUlRJRklDQVRFLS0tLS0K",
    "certificate_key": "LS0tLS1CRUdJTiBQUklWQVRFIEtFWS0tLS0tCk1JSUV2QUlCQURBTkJna3Foa2lHOXcwQkFRRUZBQVNDQktZd2dnU2lBZ0VBQW9JQkFRQ3NuNERZWENtcHpUd3gKVzFwYm9uSXIrWDBMOHhpb2dTK1lYcWk0ckpZeGdSb1hhSTc0aTlPYUx1RU0wcytNTy9NY2tPc3RycXV2d2pZWQp2c0txLythOExMa2w0OWtoV3JJNDRJSW84RVJTcVJFakhrdjhJY3JhNXZIS3I5VWRnRFViN1dPNlB2Y2ZtK00rCnp5TzJ2RkF4T2MwSm1vK3V1Q0gzaDVJUnNXTU1adXQySVVkbE1XWFk0dys3MEJNR0VYWEM3NmxyL2J1a2hXaTQKcVlBMjVLUWxLSW5laWtUM2QxRUpzVDloZUUzWWsxSnkrQ3l2UlNhbERDVEpQYkdWNG1XNjBtYzU4VnY1S1c1bwpaVmlIMHFDa3Y2cjd1WERSamp3cGZxc1hLN2ZvbmtYU3JrTE01ZUhYOEI1cURMNGdEc1dPNUgwNll0RDhCaWtkCnJrRjh2NEJ2QWdNQkFBRUNnZ0VBWENKSjM3RFpIK01GeElZd3BRWUFFQTU2T24yR1pMR0cyTGwxTGhRWG1kYUIKT1lzNSs5aU5tUlo2VWFEVzI4OUhnN0NwaFZsY0UxUUNFWlVIUzhPSHdGblNmREd2TzBrd0pJRlhsMGdkLzB4egpkQjRBaWxMeTlZRWIvb1Y0cHVVOTgyanh1SDlRNE5NUUovN2czZkNHa0s5OEN5c3VreDkrS2FKM1NQQTNvRzhSCnlLNDVKckRZK1l4WktLNS9EZmtrZlRGdXF6TDkxSzdIcFdBKzkxc3FnRUM5c0hqTzJyME9KUmlEK1lFekFLZisKb0hsSHZmTjhrblBSTDZRMWFJaUgvL1o3S053YTlmOHFvK0prZmR3bExaS21KS21ScEtqQUppMWd1ckZSaklzUgpQeU5sTm43VHljQmZUKzIvS3hoNm1pR2F1UWg1ZC9saXg2QVJLMjhTdVFLQmdRRFNSQkxmQ3RiYWR2OThtWWJsCnREUS95OUZoSWo0WHJML2xPZVhJaEZEbFpKc3U4R3dpSzZZczNqWFQvOEhwUlZUbll6TkdtdUhUNk5Pb1lkakoKWk5IWDFINHlCT2xMV3oyQ3RvNk1aMWJSWkVlcHplV29GM2txMWc2TmNabmJYdk4xNmNhSXJzTG9LY0NYQ2h6UwpFQ245TytrS1FBYk1PL3d2WXVMUWJpRlU4d0tCZ1FEU0syc09WWGIrbm83MVZmR1BUSDJpQUV2bWxFRlZwVkNhClNxMmtWZE9hQkVOR3BnWnRwNmZ4Lzh5bUlPbGczWnZpQ2JQZnVhK2FGOENqVUYzaGRkcDFRdTI3RjdCaGswbGUKUXNrRGVBaEU4KzVxWWZtWEUwZUo1dE11bmtYUHM2b2o3eHRTTlR2c01CZEwwK3AwVUtia0EzaDVvLzlqdytkLwp2OHRpYytKMWxRS0JnQ1RNd1RqRUh1SlJYVm1qVFJhNnVVSkpHN1lTVmlleWxrczZITnRCUFI5SXdsZ3V2OTRqCklZeE12OE1BeWlGWGZ3cVlOQXN4WkVEQVNQcjVWUVc2WFhlV3V4ZHFBS0t0cjFCSFB4K1hubnc3UHNlYlA0eHgKdjBVZC9hSUh0ZFBOQkhNb25SU2k4WDNNZ09adVlLanJKMDRveEJxRkppdHNmRENXNy9kbXJ2SzlBb0dBZVR4OApsQmN1L25BZXpWMVhiQzlXcFpZQU1ySEJBcFBMYkVXNTV2dHZoZ0FCZ3dhUTNMNkMvZkZ1YjBLNi9acTRxbXFvCmJWMWk4OFBSNXlPY0ZFdjB5Z0hpdXpOT0Z1dHN2a2hPUm9iK1ZqQlVqdCtYcDlPQ1NBVjBPd2NvQkVtQzB4bkMKSytqemVTckF0WWc0VGdLY1V4bkJiSUh5OSt6eFpOc1JpdWlJY1FVQ2dZQUpQN3pBck5IQ0FVYWwwOUQvQVFjbAppMGVxQnkvZ2xJOXlIS1BVcDFlU1BnUnhSL3Y4ZVBPOGM2azA5YkM3bk1TeDQ5bEVWWnhvT1lkM3ZkSyszQXZCCnByZWZscnZXTk5hSWhBMHdsZTRjWXdObHlMZDVKRU5zeDZ1RTBwNUd4UVRLeEZNUE16L2JaSlU0YzZkUWsyUDIKNFdVME1SLzRLdU9KMjJOZWJObmlWUT09Ci0tLS0tRU5EIFBSSVZBVEUgS0VZLS0tLS0K"
  }
}'

Response example:

{"status": "success"}

or

{"status": "fail", "description": "%description%"}
The following parameters are available for management:

Supported parameters
Parameter
Description
name

The canonical name of the SSL certificate and its private key, which will be used as the names of the corresponding files.

SSL certificate and SSL certificate chain (optional) in Base64 format. The parameter is set together with the certificate_key parameter.

The private key of the SSL certificate in the format Base64. The parameter is set together with the certificate parameter.

Get the hash sum of the current settings
Verification of the hash amount is required to confirm the relevance of the configuration. Changing the value means that the settings have been changed.

Request example:

# curl http://api.example.com:8080/nw-api/nginx/get_certificate_hash --data 'key=%License key%'

Response example:

{"status": "success", "hash": "8ddd2b342d3190a866ee35afb249919a"}
Delete configuration
Request example:

# curl http://api.example.com:8080/nw-api/nginx/set_certificate --header 'Content-type: application/json' --data '{
  "key": "%License key%",
  "del": {
    "name": "%Configuration name%"
  }
}'

Response example:

{"status": "success"}

or

{"status": "fail", "description": "%description%"}

🔗 DHParam settings

The name parameter is the name of the configuration with the DHParam parameters, which will be located in /etc/nginx/nwaf/conf/nginx/ssl/dhparam/%name%.pem.

For security reasons, executing the get configuration command does not return the full contents of the dhparam field. Full information about dhparam is requested by the Nemesida AI MLA component at the URL http://api.example.com:8080/nw-api/nginx/secure/get_dhparam, access to which is recommended to be allowed only for the filtering node server.

The section is used to configure the DHParam parameter. Supports the following control commands:

Get settings
Request example:

# curl http://api.example.com:8080/nw-api/nginx/get_dhparam --data 'key=%License key%'

Response format:

{
  "status": "success",
  "configuration": [
    {
      "name": string,
      "dhparam": string
    }
  ]
}

or

{"status": "fail", "description": "%description%"}

Response example:

{
  "status": "success",
  "configuration": [
    {
      "name": "dhparam",
      "dhparam": "LS0tLS1CRUdJTiBESCBQQVJBTUVURVJT..."
    }
  ]
}
Set settings
Request example:

# curl http://api.example.com:8080/nw-api/nginx/set_dhparam --header 'Content-type: application/json' --data '{
  "key": "%License key%",
  "set": {
    "name": "%Configuration name%",
    "dhparam": "LS0tLS1CRUdJTiBESCBQQVJBTUVURVJTLS0tLS0KTUlHSEFvR0JBT1lpNi9OQmljaHU5UDlPS3BpZ1RLQTB4WjNUWnZKQ3pWNzMvWkxCMkgvRFFzc2xUNWgyWEltcQpiazR0SHRGc2ViNDU0S29IR3JoM2FCbzFmcXB5REJQMDcxR0M3eE12c2xUQXVBanVIRmFVckd6NVNDTWRRN3A3CnJvaWNJdExNWE5razQ1WWpzazRPZjZHVXhDZXQ1MkdqSHo3a01yemdvbUtWTldjdU5BRGJBZ0VDCi0tLS0tRU5EIERIIFBBUkFNRVRFUlMtLS0tLQo="
  }
}'

Response example:

{"status": "success"}

or

{"status": "fail", "description": "%description%"}

The following parameters are available for management:

Supported parameters
Parameter
Description
name

The canonical name of the pem file required for the operation of the Forward Secret. Forward Secrecy means that if an attacker finds out any session key, he will only be able to access data protected by this key.

The key value in the Base64 format.

Get the hash sum of the current settings
Verification of the hash amount is required to confirm the relevance of the configuration. Changing the value means that the settings have been changed.

Request example:

# curl http://api.example.com:8080/nw-api/nginx/get_dhparam_hash --data 'key=%License key%'

Response example:

{"status": "success", "hash": "8ddd2b342d3190a866ee35afb249919a"}
Delete configuration
Request example:

# curl http://api.example.com:8080/nw-api/nginx/set_dhparam --header 'Content-type: application/json' --data '{
  "key": "%License key%",
  "del": {
    "name": "%Configuration name%"
  }
}'

Response example:

{"status": "success"}

or

{"status": "fail", "description": "%description%"}

Operation event collector of Nemesida WAF components

Available only for the Enterprise Enterprise plan.

The functionality is designed for centralized reception, storage and processing of logs of all Nemesida WAF components.

Get an Nemesida WAF component operation event list
Request example:

# curl http://api.example.com:8080/nw-api/get_event --header 'Content-type: application/json' --data '{
  "key": "%License key%",
  "startTime": 1234567891,
  "endTime": 1987654321,
  "limit": 100,
  "offset": 1,
  "level": ["info", ...],
  "ip": ["1.1.1.1", ...],
  "uuid": ["198be506d69ba8a9bdbcf87b22ef5bc", ...],
  "agent": ["dyn", ...],
  "category": ["settings", ...]
}'

Optional parameters:

  • startTime – the starting date in the format Unix Timestamp for which information will be requested;
  • endTime – the end date in the format Unix Timestamp, for which information will be requested;
  • limit – maximum number of display records;
  • offset – offset for the display of subsequent records;
  • level – message severity level;
  • ip – IP address of the server where the component is installed;
  • uuid – id of the server where the component is installed;
  • agent – component name;
  • category – event category.

The added parameters are combined according to the logical “and” (&) principle, and their values are combined according to the logical “or” (|) principle.

Response format:

{
  "status": "success",
  "count": integer,
  "waf_id": string,
  "events": [
    {
      "id": integer,
      "ip": string,
      "uuid": string,
      "agent": string,
      "level": string,
      "category": string,
      "timestamp": integer,
      "description": string
    }
  ]
}

Response example:

{
  "status": "success",
  "count": 28,
  "waf_id": "1674726761",
  "events": [
    {
      "id": 2798306,
      "ip": "1.1.1.1",
      "uuid": "bd4f447720189ca3c5a42e1395fa6021",
      "agent": "dyn",
      "level": "debug",
      "category": "nginx",
      "timestamp": 1688404169,
      "description": "This is log 1"
    }
  ]
}
Supported parameters
Time interval:

  • startTime – the starting date in the format Unix Timestamp for which information will be requested;
  • endTime – the end date in the format Unix Timestamp, for which information will be requested.

Number of records:

  • limit – maximum number of display records;
  • offset – offset for the display of subsequent records. If the value is 0 and the value is limit 100, records with the sequence number 1-100 will be display, if the value is 1, records with the sequence number 101-200, etc. It is not possible to use the parameter without specifying the maximum number of display records (limit).

Ranking of events:

  • level – event severity level;
    • debug – events with debugging information;
    • info – informational messages about the status of the component;
    • warn – warnings about a potential problem in the operation of the component;
    • error – error messages in the operation of the component;
    • fatal – messages about critical errors in the operation of the component, leading to a malfunction.
  • category – event category:
    • Filtering node:
      • auth – events related to the verification of the program key, plan, etc.;
      • os – operating system interaction events (memory, disk);
      • network – network-related events (connection cannot be established, dispatches, timeouts, interruptions, socket/port start/stop);
      • api – events related to interaction with the Nemesida WAF API;
      • settings – events related to module settings;
      • nginx – events related to interaction with Nginx (inconsistency of settings required for the operation of the filtering node, violations of the RFC);
      • signature – events related to signature analysis;
      • clamav – events related to interaction with ClamAV;
      • mla – events related to interaction with Nemesida AI MLA;
      • mlc – events related to interaction with Nemesida AI MLC;
      • rabbitmq – events related to interaction with RabbitMQ;
      • autoban – events related to the automatic blocking mechanism;
      • geo – events related to the GeoIP functionality;
      • openapi – events related to the operation of OpenAPI;
      • parsing – events related to data decoding and normalization;
      • analysis – events related to request processing, but not included in any group (signature, ml, openapi, etc.);
      • misc – events that are not included in any category (for example, the display of information about UUID, WAF ID, number of signatures, etc.).
    • Nemesida AI MLA:
      • auth – events related to the verification of the program key, plan, etc.;
      • os – operating system interaction events (memory, disk);
      • network – network-related events (connection cannot be established, dispatches, timeouts, interruptions, socket/port start/stop);
      • api – events related to interaction with the Nemesida WAF API;
      • settings – events related to module settings;
      • dyn – events related to interaction with the filtering node;
      • ml – events related to the work of machine learning;
      • geo – events related to the GeoIP functionality;
      • mgmt – events related to the functionality of the service management interface;
      • openapi – events related to the operation of OpenAPI;
      • parsing – events related to data decoding and normalization;
      • analysis – events related to request processing, but not included in any group (signature, ml, openapi, etc.);
      • misc – events that are not included in any category (for example, the display of information about UUID, WAF ID, etc.).
    • Nemesida AI MLC:
      • auth – events related to the verification of the program key, plan, etc.;
      • os – operating system interaction events (memory, disk);
      • network – network-related events (connection cannot be established, dispatches, timeouts, interruptions, socket/port start/stop);
      • api – events related to interaction with the Nemesida WAF API;
      • settings – events related to module settings;
      • dyn – events related to interaction with the filtering node;
      • rabbitmq – events related to interaction with RabbitMQ;
      • ml – events related to the work of machine learning;
      • geo – events related to the GeoIP functionality;
      • bf – events related to the work of Brute-force/Flood analysis;
      • ddos – events related detection of DDoS attacks;
      • openapi – events related to the operation of OpenAPI;
      • parsing – events related to data decoding and normalization;
      • analysis – events related to request processing, but not included in any group (signature, ml, openapi, etc.);
      • misc – events that are not included in any category (for example, the display of information about UUID, WAF ID, etc.).
  • Nemesida WAF Scanner:
    • auth – events related to the verification of the program key, plan, etc.;
    • os – operating system interaction events (memory, disk);
    • network – network-related events (connection cannot be established, dispatches, timeouts, interruptions, socket/port start/stop);
    • api – events related to interaction with the Nemesida WAF API;
    • settings – events related to module settings;
    • scan – events related to the operation of the component;
    • %ModuleName% – events related to the operation of a specific scanning module;
    • parsing – events related to data decoding and normalization;
    • db – events related to database interaction;
    • misc – events that are not included in any category (for example, the display of information about UUID, WAF ID, etc.).

Components identification:

  • ip – IP address of the server where the component is installed;
  • uuid – id of the server where the component is installed;
  • agent – component name:
    • dyn – Filtering node;
    • mla – Nemesida AI MLA;
    • mlc – Nemesida AI MLC;
    • cabinet – Nemesida WAF Cabinet;
    • nws – Nemesida WAF Scanner.
Delete events
Request example:

# curl http://api.example.com:8080/nw-api/del_event --header 'Content-type: application/json' --data '{
  "key": "%License key%",
  "timestamp": 1686655813,
  "id": [1, 2, 3],
  "ip": [
    "1.1.1.1",
    "2.2.2.2"
  ],
  "uuid": [
    "198be506d69ba8a9bdbcf87b22ef5bc",
    "198be506d69ba8a9bdbcf87b22ef5bb"
  ],
  "agent": [
    "dyn",
    "mla"
  ],
  "level": [
    "info",
    "error"
  ],
  "category": [
    "os",
    "api"
  ]
}'

Optional parameters:

  • timestamp – the date in the format Unix Timestamp before which (inclusive) all events will be deleted;
  • id – ID of records to be deleted;
  • ip – IP address of the server where the component is installed;
  • uuid – id of the server where the component is installed;
  • agent – component name;
  • level – message severity level;
  • category – event category.

The added parameters are combined according to the logical “and” (&) principle, and their values are combined according to the logical “or” (|) principle.

All events older than 90 days are automatically deleted.

Response example:

{"status": "success"}

or

{"status": "fail", "description": "%description%"}

Getting information about attacks

The functionality allows you to get information about blocked requests, including statistics for the period.

Get attack list
Request example:

# curl http://api.example.com:8080/nw-api/get_attack --header 'Content-type: application/json' --data '{
  "key": "%License key%",
  "startTime": 1677211703,
  "endTime": 1677211703,
  "limit": 100,
  "offset": 1,
  "bt": [1, ...],
  "ip": ["1.1.1.1", ...],
  "cc": ["RU", ...],
  "vhost": ["example.com", ...],
  "method": ["post", ...],
  "rule_id": [1, ...],
  "signatureType": ["sqli", ...],
  "mz": ["args", ...],
  "request_id": ["b2afdac78f17e017dd2b6dfafcb5a974", ...],
  "group_id": ["b2afdac78f17e017dd2b6dfafcb5a974", ...],
  "blocked": true,
  "possible": true,
  "bodyLimit": 1024,
  "url": ["/uploads.php", ...],
  "args": ["abc", ...],
  "body": ["abc", ...],
  "cookie": ["abc", ...],
  "other_headers": ["abc", ...],
  "referer": ["http://127.0.0.1", ...],
  "ua": ["Mozilla/5.0", ...],
  "search": ["abc", ...],
}'

Optional parameters:

  • startTime and endTime – the start and end date in the format Unix Timestamp, for which information will be requested;
  • limit – maximum number of display records;
  • offset – offset for the display of subsequent records. If the value is 0 and the value is limit 100, records with the sequence number 1-100 will be display, if the value is 1, records with the sequence number 101-200, etc. It is not possible to use the parameter without specifying the maximum number of display records (limit).
  • bt – blocking identifier;
  • ip – IP address;
  • cc – country code;
  • vhost – virtual host, domain name;
  • method – HTTP request method;
  • rule_id – ID of the detected signature;
  • signatureType – type of detected signature;
  • mz – anomaly detection zone;
  • request_id – unique identifier of the request;
  • group_id – ID of the request group defined by Nemesida AI MLC as a brute-force or DDoS attack;
  • blocked – the status of the actual blocking of the request;
  • possible – the filter displays potential attacks, which have not been reliably identified as attacks;
  • bodyLimit – the size of the output request body;
  • url – search for the occurrence of a string in the URL address;
  • args – searching for the entry of a string in the request arguments;
  • body – search for the entry of a string in the request body;
  • cookie – search for the entry of a string in the header Cookie;
  • other_headers – search for the entry of a string in the headers (except Cookie, User-Agent and Referer);
  • referer – search for the entry of a string in the Referer header;
  • ua – search for the entry of a string in the header User-Agent;
  • search – search for the entry of a string for each element from the list among the request zones (url, args, body, cookie, other_headers, referer, ua).

The search for values transmitted as a list is performed according to the principle of logical OR.

Response format:

{
  "status": "success",
  "count": integer,
  "waf_id": string,
  "attacks": [
    {
      "id": integer,
      "timestamp": integer,
      "request_id": string,
      "group_id": string,
      "rule_id": integer,
      "description": string,
      "long_description": string,
      "blocked": boolean,
      "possible": boolean,
      "lm": boolean,
      "mz": array,
      "bt": integer,
      "ip": string,
      "cc": string,
      "vhost": string,
      "method": string,
      "url": string,
      "args":string,
      "body": string,
      "cookie": string,
      "other_headers": string,
      "ua": string,
      "referer": string
    },
    ...
  ]
}

or

{"status": "fail", "description": "%description%"}

Response example:

{
  "status": "success",
  "count": integer,
  "waf_id": string,
  "attacks": [
    {
      "id": 1,
      "timestamp": 173098845,
      "request_id": "b2afdac78f17e017dd2b6dfafcb5a974",
      "group_id": "b2afdac78f17e017dd2b6dfafcb5a974",
      "rule_id": 1,
      "description": "SQLi",
      "long_description": "some_text",
      "blocked": true,
      "possible": false,
      "lm": false,
      "mz": ["args", ...],
      "bt": 2,
      "ip": "1.1.1.1",
      "cc": "RU",
      "vhost": "example.com",
      "method": "POST",
      "url": "/uploads.php",
      "args": "abc",
      "body": "abc",
      "cookie": "abc",
      "other_headers": "abc",
      "ua": "Mozilla/5.0",
      "referer": "http://127.0.0.1"
    },
    ...
  ]
}

id – ID of the database record.

Request attack statistics
Request example:

# curl http://api.example.com:8080/nw-api/get_attack_stats --header 'Content-type: application/json' --data '{
  "key": "%License key%",
  "startTime": 173098845,
  "endTime": 173096645
}'

Optional parameters:
startTime and endTime – the start and end date in the format Unix Timestamp, for which information will be requested.

Response format:

{
    "status": "success",
    "bt": [
        {
            "bt": integer,
            "period": integer
        },
        ...
    ],
    "ip": [
        {
            "ip": string,
            "period": integer
        },
        ...
    ],
    "cc": [
        {
            "cc": string,
            "period": integer
        },
        ...
    ],
    "vhost": [
        {
            "vhost": string,
            "period": integer
        },
        ...
    ]
}

or

{"status": "fail", "description": "%description%"}

Response example:

{
    "status": "success",
    "bt": [
        {
            "bt": 1,
            "period": 30
        },
        ...
    ],
    "ip": [
        {
            "ip": "1.1.1.1",
            "period": 45
        },
        ...
    ],
    "cc": [
        {
            "cc": "RU",
            "period": 11
        },
        ...
    ],
    "vhost": [
        {
            "vhost": "example.com",
            "period": 123
        },
        ...
    ]
}

period – the count of events for each bt/cc/vhost/ip for the selected period;
bt – blocking identifier;
ip – IP address;
cc – country code;
vhost – virtual host, domain name.

If the period for which you need to get data is not set by the startTime and endTime parameters, then the information will be output for the last 24 hours, 7 and 30 days.

Response format:

{
  "status": "success",
  "bt": [
    {
      "bt": integer,
      "lastDay": integer,
      "last7Days": integer,
      "last30Days": integer
    },
    ...
  ],
  "ip": [
    {
      "ip": string,
      "lastDay": integer,
      "last7Days": integer,
      "last30Days": integer
    },
    ...
  ],
  "cc": [
    {
      "cc": string,
      ...
      "lastDay": integer,
      "last7Days": integer,
      "last30Days": integer
    },
    ...
  ],
  "vhost": [
    {
      "vhost": string,
      "lastDay": integer,
      "last7Days": integer,
      "last30Days": integer
    },
    ...
  ]
}

or

{"status": "fail", "description": "%description%"}

Response example:

{
  "status": "success",
  "bt": [
    {
      "bt": 1,
      "lastDay": 12,
      "last7Days": 24,
      "last30Days": 145
    },
    ...
  ],
  "ip": [
    {
      "ip": "1.1.1.1",
      "lastDay": 12,
      "last7Days": 24,
      "last30Days": 145
    },
    ...
  ],
  "cc": [
    {
      "cc": "RU",
      ...
      "lastDay": 12,
      "last7Days": 24,
      "last30Days": 145
    },
    ...
  ],
  "vhost": [
    {
      "vhost": "example.com",
      "lastDay": 12,
      "last7Days": 24,
      "last30Days": 145
    },
    ...
  ]
}


lastDay/last7Days/last30Days – the count of events for each bt/cc/vhost/ip for last 24 hour, 7 and 30 days;
bt – blocking identifier;
ip – IP address;
cc – country code;
vhost – virtual host, domain name.

Delete attacks
Request example:

# curl http://api.example.com:8080/nw-api/del_attack --header 'Content-type: application/json' --data '{
  "key": "%License key%",
  "id": [1, ...]
}'

Response example:

{"status": "success", "deleted": 15}

or

{"status": "fail", "description": "%description%"}

Required parameters:

  • id – ID of the database record.

The search for values transmitted as a list is performed according to the principle of logical OR.

Managing Nemesida WAF Scanner settings

Available only for the Enterprise Enterprise plan.

The functionality is designed to manage the scanning settings of the Nemesida WAF Scanner component.

Get settings
Request example:

# curl http://api.example.com:8080/nw-api/nws/get_target --header 'Content-type: application/json' --data '{
  "key": "%License key%"
}'

Response format:

{
  "status": "success",
  "targets": [
    {
      "active": boolean,
      "target": string,
      "scan_proxy": string,
      "auth_params": {
        "active": boolean,
        "url": string,
        "username_field": string,
        "username_value": string,
        "password_field": string,
        "password_value": string
      },
      "exclude_modules": [string, ...]
    },
    {
      "active": boolean,
      "target": string
      ...
    }
  ]
}

or

{"status": "fail", "description": "%description%"}

Response example:

{
  "status": "success",
  "targets": [
    {
      "active": true,
      "target": example.com,
      "scan_proxy": "http://proxy.example.com:3128",
      "auth_params": {
        "active": true,
        "url": "http://example.com/login.php",
        "username_field": "username",
        "username_value": "admin",
        "password_field": "password",
        "password_value": "123456"
      },
      "exclude_modules": ["sqli", ...]
    },
    ...
  ]
}
Set settings
Request example:

# curl http://api.example.com:8080/nw-api/nws/set_target --header 'Content-type: application/json' --data '{
  "key": "%License key%",
  "active": true,
  "target": "http://example.com",
  "scan_proxy": "http://example.com:3128",
  "auth_params": {
    "active": true,
    "url": "/login.php",
    "username_field": "username",
    "username_value": "admin",
    "password_field": "password",
    "password_value": "123456"
  },
  "exclude_modules": [
    "ba", "ca", "lfi", "rce", "rfi", "sde", "sqli", "ssti", "xss"
  ]
}'

Response example:

{"status": "success"}

or

{"status": "fail", "description": "%description%"}

The following parameters are available for management:

Supported parameters
Parameter
Description
target

Web application address in schema://domain[:port] format.

Example:

{... "target": "http://example.com" ...}

or

{... "target": "https://example.com:443" ...}
scan_proxy

Proxy server address (optional) for requests to the web application.

Example:

{... "scan_proxy": "http://proxy.example.com:3128" ...}
auth_params

Authentication options:

  • active – apply authentication parameters;
  • url – web application page address for the authorization;
  • username_field – name of the field for entering the user name;
  • username_value – username;
  • password_field – name for the user password input field;
  • password_value – password.

If the web application uses non-standard names of username/password fields, then they must be specified in the username_field and password_field parameters.

exclude_modules

Option to disable scanning modules.

Example:

{... "exclude_modules": ["sqli", "xss", "rce", "lfi", "rfi"] ...}
Reset settings
Request example:

# curl http://api.example.com:8080/nw-api/nws/set_target --header 'Content-type: application/json' --data '{
  "key": "%License key%",
  "set": {
    "target": "http://example.com",
    "scan_proxy": null,
    "auth_params": {
      "active": true,
      "url": null,
      "username_field": null,
      "username_value": null,
      "password_field": null,
      "password_value": null
    },
    "exclude_modules": []
  }
}'

Response example:

{"status": "success"}

or

{"status": "fail", "description": "%description%"}
Delete settings
Request example:

# curl http://api.example.com:8080/nw-api/nws/del_target --header 'Content-type: application/json' --data '{
  "key": "%License key%",
  "target": "%Web application address%"
}'

Response example:

{"status": "success"}

or

{"status": "fail", "description": "%description%"}