Manage Nemesida WAF settings using the API | Nemesida WAF

Защита сайта от хакерских атак
Manage Nemesida WAF settings using the API

A guide to managing Nemesida WAF settings using the API.

Content

General information

The settings management functionality is not available for Light plan.

Using API calls, you can manage Nemesida WAF settings:

  • Nemesida WAF dynamic module settings;
  • Nemesida AI MLC settings;
  • behavioral models;
  • synchronization of the settings of the dynamic module 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 or an identification token.
For the Business plan, Nemesida WAF settings can be managed by accessing the cloud API.
For the Enterprise plan, Nemesida WAF settings are managed by accessing the Nemesida WAF API server installed within the client’s network perimeter.

Managing Nemesida WAF settings using the Cloud API

Action log

Get action log contents:

Business

The identification token is available in the Cloud WebApp.

# curl https://nemesida-security.com/nw/agent/get_event_log --data 'token=%Identification token%'

If an invalid identification token is used, the response will be returned with the code 401.

Nemesida WAF dynamic module

Allows managing the settings of the Nemesida WAF dynamic module. Supports the following control commands:

BusinessEnterprise

The identification token is available in the Cloud WebApp.

Get settings:

# curl https://nemesida-security.com/nw/agent/get_dyn_settings?format=json --data 'token=%Identification token%'

Set settings:

# curl https://nemesida-security.com/nw/agent/public/set_dyn_settings --header 'Content-type: application/json' --data '{"token": "%Identification token%", "set": {"nwaf_ip_wl": "127.0.0.1, 127.0.0.2", "nwaf_ai_extra_host_lm": "example.com", "active": "true"}}'

set – settings parameters in JSON format.

Delete settings:

# curl https://nemesida-security.com/nw/agent/public/set_dyn_settings --header 'Content-type: application/json' --data '{"token": "%Identification token%", "del": "nwaf_ip_wl"}'

del – settings parameter in JSON format.

Get a list of IP addresses to block:

# curl https://nemesida-security.com/nw/agent/get_dyn_bl --data 'token=%Identification token%'

Set a list of IP addresses to block:

# curl https://nemesida-security.com/nw/agent/public/set_dyn_bl --header 'Content-type: application/json' --data '{"token": "%Identification token%", "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"]}}'

set – settings parameters in JSON format.

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.

Delete all IP addresses:

# curl https://nemesida-security.com/nw/agent/public/set_dyn_bl --header 'Content-type: application/json' --data '{"token": "%Identification token%", "del": ""}'

del – settings parameter in JSON format.

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

Get settings:

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

Set settings:

# curl http://api.example.com:8080/nw-api/set_dyn_settings --header 'Content-type: application/json' --data '{"key": "%License key%", "set": {"nwaf_ip_wl": "127.0.0.1, 127.0.0.2", "nwaf_ai_extra_host_lm": "example.com", "active": "true"}}'

set – settings parameters in JSON format.

Delete settings:

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

del – settings parameter in JSON format.

Get a list of IP addresses to block:

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

Set a list of IP addresses to block:

# curl http://api.example.com:8080/nw-api/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"]}}'

set – settings parameters in JSON format.

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.

Delete all IP addresses:

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

del – settings parameter in JSON format.

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.

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 requests per minute for the domainexample.com (followed by blocking the attacker’s IP address for 300 seconds), as well as limits on 10 requests per minute for all other domains (followed by blocking the attacker’s IP address for 600 seconds).

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" ...}
{... "nwaf_ip_wl": "127.0.0.1, 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, 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, passed 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 actual blocking (passive mode).

Example:

{... "nwaf_ip_lm": "127.0.0.1, 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, 192.168.61.1-192.168.61.255" ...}
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 actual blocking (passive 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_mla_host_lm

The parameter that activates the LM mode (passive 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 (passive 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 passed 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

The parameter that excludes the analysis of the BODY zone by the signature method, as well as sending its contents in 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_exclude": "*" ...}

or

{... "nwaf_body_exclude": "example.com/uploads.php" ...}

or

{... "nwaf_body_exclude": "example.com/uploads" ...}

When applying the parameter, the exact match of the path (vhost/path).

For example, with the value: example.com/uploads the BODY zone analysis exception will be applied for requests to example.com/uploads, but for example.com/uploads.php and example.com/uploads/index.php the parameter will not be applied. With the value *, the BODY zone analysis exception will be applied to any address.

nwaf_put_body_exclude

The parameter that excludes the signature method from analyzing the contents of the BODY zone for INPUT 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" ...}

Nemesida AI MLC

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

BusinessEnterprise

The identification token is available in the Cloud WebApp.

Get Settings:

# curl https://nemesida-security.com/nw/agent/get_mlc_settings?format=json --data 'token=%Identification token%'

Get virtual hosts list:

# curl https://nemesida-security.com/nw/agent/get_vhosts_list --data 'token=%Identification token%'

Set a list of virtual hosts for which models will be created and applied:

# curl https://nemesida-security.com/nw/agent/public/set_vhosts_list --header 'Content-type: application/json' --data '{"token": "%Identification token%", "vhosts_list": "example.com, example.org"}'

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

Set settings:

# curl https://nemesida-security.com/nw/agent/public/set_mlc_settings --header 'Content-type: application/json' --data '{"token": "%Identification token%", set": {"main__ai_extra": "false", "brute__interval": "11", "brute__brute_detect": ["example.com/a1", "example.com/b1"], "active": "true"}}'

set – settings parameters in JSON format.

Delete settings:

# curl https://nemesida-security.com/nw/agent/public/set_mlc_settings --header 'Content-type: application/json' --data '{"token": "%Identification token%", "del": "brute_detect"}'

del – settings parameters in JSON format.

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

Get Settings:

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

Get virtual hosts list:

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

Set a list of virtual hosts for which models will be created and applied:

# curl http://api.example.com:8080/nw-api/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.

Set settings:

# curl http://api.example.com:8080/nw-api/set_mlc_settings --header 'Content-type: application/json' --data '{"key": "%License key%", set": {"main__ai_extra": "false", "brute__interval": "11", "brute__brute_detect": ["example.com/a1", "example.com/b1"], "active": "true"}}'

set – settings parameters in JSON format.

Delete settings:

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

del – settings parameters in JSON format.

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" ...}
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). Each subsequent value is separated by a space.

Example:

{... "ddos__wl_ip": ["127.0.0.1", "192.168.1.0/24"] ...}
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 query analysis is performed.

Example:

{... "ddos__interval": "10" ...}
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__interval
The time interval (in seconds) during which the query analysis is performed.

Example:

{... "brute__interval": "10" ...}
brute__max_val
The number of requests, upon reaching the value of which the IP address of the source(s) of the attack is blocked.

Example:

{... "brute__mav_val": "15" ...}
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.

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

Signature exclusion rules management

Allows configuring signature exclusion rules. The following control commands are supported:

BusinessEnterprise

The identification token is available in the Cloud WebApp.

Get a list of rules:

# curl https://nemesida-security.com/nw/agent/get_dyn_wl --data 'token=%Identification token%'

Get extended information about the rule:

# curl https://nemesida-security.com/nw/agent/get_dyn_wl?extended=yes --data 'token=%Identification token%'

Create rule:

# curl https://nemesida-security.com/nw/agent/public/set_dyn_wl --header 'Content-type: application/json' --data '{"token": "%Identification token%", "add": {"rl_id": "50001", "domain": "example.com", "mz": "URL", "extension": "$URL_X:/test"}}'

add – settings parameters in JSON format;
rl_id – ID of the signature (blocking rule) to which the exclusion rule applies. When using the value * the exclusion rule will apply to all signatures.

More detailed information on creating rules is available in the corresponding section of the documentation.

Update rule:

# curl https://nemesida-security.com/nw/agent/public/set_dyn_wl --header 'Content-type: application/json' --data '{"token": "%Identification token%", "upd": {"rid": "50001", "pattern": "ABC"}}'

upd – settings parameters in JSON format.

Delete rule:

# curl https://nemesida-security.com/nw/agent/public/set_dyn_wl --header 'Content-type: application/json' --data '{"token": "%Identification token%", "del": {"rid": "50001"}}'

del – settings parameters in JSON format.

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

Get a list of rules:

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

Get extended information about the rule:

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

Create rule:

# curl http://api.example.com:8080/nw-api/set_dyn_wl --header 'Content-type: application/json' --data '{"key": "%License key%", "add": {"rl_id": "50001", "domain": "example.com", "mz": "URL", "extension": "$URL_X:/test"}}'

add – settings parameters in JSON format;
rl_id – ID of the signature (blocking rule) to which the exclusion rule applies. When using the value * the exclusion rule will apply to all signatures.

More detailed information on creating rules is available in the corresponding section of the documentation.

Update rule:

# curl http://api.example.com:8080/nw-api/set_dyn_wl --header 'Content-type: application/json' --data '{"key": "%License key%", "upd": {"rid": "50001", "pattern": "ABC"}}'

upd – settings parameters in JSON format.

Delete rule:

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

del – settings parameters in JSON format.

Extended request 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 a 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, Referrer, 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.

The principle of operation
Supported the following parameters:

  • ip – Attacker’s IP address;
  • api – send the result of the rule triggering to the Nemesida WAF API module;
  • lm – processing of the rule in the LM mode (the rule is triggered, but the request is not blocked);
  • noban – with the value false, when the rule is triggered, the request will be blocked, but the counter rate of the parameter nwaf_limit required to block the IP address of the request source will not increase;
  • no_cookie – with the value true the rule applies only to a request with an empty Cookie zone;
  • country – country (for the functionality of determining the geographical location based on the IP address, you need to connect a file with the GeoIP2 database in /etc/nginx/nwaf/conf/global/nwaf.conf);
  • domain – domain;
  • url – the occurrence of a string in the contents of the URL zone;
  • args – the occurrence of a string in the contents of the ARGS zone;
  • body – the occurrence of a string in the contents of the BODY zone;
  • cookies – the occurrence of a string in the contents of the Cookie zone;
  • ua – the occurrence of a string in the contents of the User-Agent zone;
  • referer – the occurrence of a string in the contents of the Referer zone;
  • 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.

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

Example:

{... "domain": "base64(*.example.com)" ...}

With this value, the rule will apply to all subdomains (a.example.com, b.example.com, etc.), excluding the main domain example.com. If the value of the domain field is empty, the rule will be applied to all requests.

The prefix base64 before the parameter means that the parameter value must be passed in the format base64 when composing the rule. For example: "domain": "base64(*.example.com )" will look like "domain": "Ki5leGFtcGxlLmNvbQ=="

For all parameters (except api,lm, noban and no_cookie), it is allowed to use multiple values in one parameter using the logical operators of the conditions “not” (!), “and” (&), “or” (|). Operators have no priority and are executed in turn, from left to right.

Example:

{... "ip": "192.168.61.0/24|192.168.62.0/24" ...}

With this value, the rule will apply to all IP addresses from the ranges 192.168.61.1-192.168.61.255 or 192.168.62.1-192.168.62.255.

Example:

{... "country": "!base64(RU)&!base64(US)" ...}

With this value, the rule will apply to all requests in which the IP address of the request source is not from Russia and not from the USA.

Example:

{... "cookie": "!base64(abc)&!base64(def)" ...}

With this value, the rule will apply to all requests that do not contain abc and def in the Cookie.

When the extended request blocking rule is checked, all fields except ip, country, api, lm and noban are checked for the contents of the field from the blocking rule to be checked in the request field. For example, with "url": "base64(/abc)", a request with the occurrence of /abcd in the URL will be blocked.

other_headers

field 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_header field, the contents of the base64(header_name) and the base64(header_value) sections 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.

Example:

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

With this value, the abcd content will be searched in the example_header header.

Example:

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

With this value, the contents of abcd will be searched 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.

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.

The logical operation is allowed 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.

If it is not possible to get any field specified in the extended blocking rule in the request, the request will be skipped.

The following control commands are supported:

BusinessEnterprise

The identification token is available in the Cloud WebApp.

Get a list of rules:

# curl https://nemesida-security.com/nw/agent/get_dyn_erl --data 'token=%Identification token%'

Get extended information about the rule:

# curl https://nemesida-security.com/nw/agent/get_dyn_erl?extended=yes --data 'token=%Identification token%'

Create rule:

# curl https://nemesida-security.com/nw/agent/public/set_dyn_erl --header 'Content-type: application/json' --data '{"token": "%Identification token%", "add": {"ip": "1.1.1.1|2.2.2.2", "active": "true"}}'

add – settings parameters in JSON format.

# curl https://nemesida-security.com/nw/agent/public/set_dyn_erl --header 'Content-type: application/json' --data '{"token": "%Identification token%", "add": {"ip": "!1.1.1.0/24", "domain": "ZXhhbXBsZS5jb20=" "active": "true"}}'

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.

# curl https://nemesida-security.com/nw/agent/public/set_dyn_erl --header 'Content-type: application/json' --data '{"token": "%Identification token%", "add": {"ip": "1.1.1.1", "domain": "ZXhhbXBsZS5jb20=", "other_headers": ["dGVzdC1oZWFkZXI=:YWJj"], "active": "true"}}'

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 https://nemesida-security.com/nw/agent/public/set_dyn_erl --header 'Content-type: application/json' --data '{"token": "%Identification token", "add": {"сountry": "Q0g=|UlU=", "domain": "ZXhhbXBsZS5jb20=", "other_headers": ["dGVzdC1oZWFkZXI=:YWJj"], "cookie": "!dGVzdF9jb29raWU=", "referer": "!aHR0cDovL2V4YW1wbGUuY29t" "active": "true"}}'

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 https://nemesida-security.com/nw/agent/public/set_dyn_erl --header 'Content-type: application/json' --data '{"token": "%Identification token%", "add": {"ip": "1.1.1.1", "other_headers": ["VGVzdC1GaWVsZA==:"], "referer": "aHR0cDovL2V4YW1wbGUuY29tLw==", "ua": "TW96aWxsYS81LjA=", "cookie": "dGVzdF9jb29raWU=", "body": "YmM9MyZjYz0x", "args": "P3BhZ2U9Mw==", "url": "aW50ZXJuYWx0ZXN0", "domain": "ZXhhbXBsZS5jb20=", "api": false, "country": "Q0g=|VFc=", "active": true}}'

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.

Update rule:

# curl https://nemesida-security.com/nw/agent/public/set_dyn_erl --header 'Content-type: application/json' --data '{"token": "%Identification token%", "upd": {"id": "1", "ip": "1.1.1.1", "active": "true"}}'

upd – settings parameters in JSON format.

Delete rule:

# curl https://nemesida-security.com/nw/agent/public/set_dyn_erl --header 'Content-type: application/json' --data '{"token": "%Identification token%", "del": {"id": "1"}}'

del – settings parameters in JSON format.

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

Get a list of rules:

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

Get extended information about the rule:

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

Create rule:

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

add – settings parameters in JSON format.

# curl http://api.example.com:8080/nw-api/set_dyn_erl --header 'Content-type: application/json' --data '{"key": "%License key%", "add": {"ip": "!1.1.1.0/24", "domain": "ZXhhbXBsZS5jb20=" "active": "true"}}'

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.

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

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/set_dyn_erl --header 'Content-type: application/json' --data '{"key": "%License key%", "add": {"сountry": "Q0g=|UlU=", "domain": "ZXhhbXBsZS5jb20=", "other_headers": ["dGVzdC1oZWFkZXI=:YWJj"], "cookie": "!dGVzdF9jb29raWU=", "referer": "!aHR0cDovL2V4YW1wbGUuY29t" "active": "true"}}'

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/set_dyn_erl --header 'Content-type: application/json' --data '{"key": "%License key%", "add": {"ip": "1.1.1.1", "other_headers": ["VGVzdC1GaWVsZA==:"], "referer": "aHR0cDovL2V4YW1wbGUuY29tLw==", "ua": "TW96aWxsYS81LjA=", "cookie": "dGVzdF9jb29raWU=", "body": "YmM9MyZjYz0x", "args": "P3BhZ2U9Mw==", "url": "aW50ZXJuYWx0ZXN0", "domain": "ZXhhbXBsZS5jb20=", "api": false, "country": "Q0g=|VFc=", "active": true}}'

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.

Update rule:

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

upd – settings parameters in JSON format.

Delete rule:

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

del – settings parameters in JSON format.

The identification token is available in the Cloud WebApp.

Behavioral models management

Action log

Business

The identification token is available in the Cloud WebApp.

# curl https://nemesida-security.com/nw/ml/mgmt/get_event_log --data 'token=%Identification token%'

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

BusinessEnterprise

The identification token is available in the Cloud WebApp.

Get a virtual hosts list with models:

# curl https://nemesida-security.com/nw/ml/mgmt/get_models_list_uri --data 'token=%Identification token%'

Delete a model for a virtual host example.com:

# curl 'https://nemesida-security.com/nw/ml/mgmt/del_models_uri' --data 'token=%Identification token%&vhost=example.com'

vhost – the name of the virtual host for which you want to delete the behavioral model.

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 'https://nemesida-security.com/nw/ml/mgmt/set_training_uri' --data 'token=%Identification token%&vhost=*.example.com&complete=no'

4. Launch the Nemesida AI MLC service:

# service mlc_main start

Copy a behavioral model for a virtual host:

# curl 'https://nemesida-security.com/nw/ml/mgmt/rep_models_uri' --data 'token=%Identification token%&src=example.com&dst=example.ru'

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

Copying behavioral models between virtual hosts is performed only within one WAF ID.

Get the model training status for a virtual host:

# curl 'https://nemesida-security.com/nw/ml/mgmt/get_training_uri' --data 'token=%Identification token%&vhost=example.com'

Set for a virtual host example.com the training period is 4 days:

# curl 'https://nemesida-security.com/nw/ml/mgmt/set_training_uri' --data 'token=%Identification token%&vhosts=example.com&duration=4'

duration – training period in days.

Activate model training for a virtual host *.example.com:

# curl 'https://nemesida-security.com/nw/ml/mgmt/set_training_uri' --data 'token=%Identification token%&vhosts=*.example.com&complete=no'

complete – the training status of the model.

Set the training period and activate model training for the virtual host .example.com:

# curl 'https://nemesida-security.com/nw/ml/mgmt/set_training_uri' --data 'token=%Identification token%&vhosts=.example.com&duration=4&complete=no'

Executing a command with the value of the parameter complete=no allows you to start the process of retraining the model, and complete=yes 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.

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

Get a virtual hosts list with models:

# curl http://api.example.com:8080/nw-api/get_models_list_uri --data 'token=%Identification token%'

Delete a model for a virtual host example.com:

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

vhost – the name of the virtual host for which you want to delete the behavioral model.

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 'https://nemesida-security.com/nw/ml/mgmt/set_training_uri' --data 'token=%Identification token%&vhost=*.example.com&complete=no'

4. Launch the Nemesida AI MLC service:

# service mlc_main start

Copy a behavioral model for a virtual host:

# curl http://api.example.com:8080/nw-api/rep_models_uri --data 'key=%License key%&src=example.com&dst=example.ru'

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

Copying behavioral models between virtual hosts is performed only within one WAF ID.

Get the model training status for a virtual host:

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

Set for a virtual host example.com the training period is 4 days:

# curl http://api.example.com:8080/nw-api/set_training_uri --data 'key=%License key%&vhosts=example.com&duration=4'

duration – training period in days.

Activate model training for a virtual host *.example.com:

# curl http://api.example.com:8080/nw-api/set_training_uri --data 'key=%License key%&vhosts=*.example.com&complete=no'

complete – the training status of the model.

Set the training period and activate model training for the virtual host .example.com:

# curl http://api.example.com:8080/nw-api/set_training_uri --data 'key=%License key%&vhosts=.example.com&duration=4&complete=no'

Executing a command with the value of the parameter complete=no allows you to start the process of retraining the model, and complete=yes 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.