On the page The Nemesida WAF local settings management web interface is available. To use the functionality, several conditions must be met:
- added a license key to user settings;
- the functionality is activated by the administrator;
- the address of the connection to the Nemesida WAF API is specified in the parameter
Local settings management means that all settings set when using the Nemesida WAF Cabinet are stored locally, are not transmitted outside the network perimeter and do not depend on the availability of the server
After clicking on the Nemesida WAF dynamic module settings management section opens.
To complete the configuration of this module, it is enough to set a condition for temporary automatic blocking of the IP address (ban). Using the parameter will allow the functionality of detecting DDoS attacks, brute force attacks and flood attacks to block the source of the attack.
By clicking on you can add a new set of values for the parameter, a dialog box will appear for this.
For example, we added a request blocking condition separately for the domain
example.com and blocking conditions for all other domains. To edit the current settings, click on .
After saving, the settings are applied automatically to all installed copies of the Nemesida WAF dynamic module, the settings of which can be controlled using a web application.
Nemesida AI MLC
When clicking on opens the settings management section of the Nemesida AI MLC machine learning module. To activate additional features (detection of DDoS attacks, brute force attacks and flood), it is necessary to activate the corresponding sections.
For Light plan available only detection of DDoS attacks, brute-force and flood attacks settings.
Behavioral Model Management ¶
To start the process of building behavioral models, you need to add a virtual host corresponding to the domain of the protected web application, for example,
Behavioral models whose training has been completed are displayed in the section «Behavioral models of Nemesida AI». Next to the name of each behavioral model there is a status indicator, where:
- – the behavioral model is being retrained;
- – training is completed, the behavioral model is applied to the virtual host.
If you need to retrain the model, then you need to click and select the retraining mode. If the retraining of the model should be performed during the standard period (4 days), then to start the retraining process, just click .
Increasing the learning time of Nemesida AI behavioral models
The correct construction of models requires about 400.000-800.000 unique requests. By default, the training period is 4 days. To change the training period, click and an additional field will appear where you need to specify the training period in days.
Additional training of models using a backup copy of the training sample
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
[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
# mv /opt/mlc/ml/backup/example.com.d_1613587613 /opt/mlc/ml/example.com.d
3. Start the training.
4. Launch the Nemesida AI MLC service:
# service mlc_main start
Copying a behavioral model
To copy the behavioral model to another virtual host, click and select the virtual host for which the behavioral model will be copied.
Removing a behavioral model
In case of incorrect training of behavioral models or significant changes in the web application that lead to a lot of false positives, it is recommended to delete the models. To delete a model, select the desired model and click .
The Personal account allows you to create signature exclusion rules and advanced request blocking rules. To go to the rules management section, go to the section .
An exception rule is intended to exclude a request from processing using a rule.
To create a rule, click on the
When drawing up an exception rule, you must specify:
ID of the signature to be excluded from triggering. The value can be set either as a number (for example,
2728) or with the symbol
* to exclude the triggering of all signatures that match the specified criteria;
- virtual host (domain name);
- signature occurrence zone (for example,
HEADERS, etc.). Multiple zones can be selected at once, then the signature will be excluded when detected in any of the listed zones.
Rashly adding signature exclusion rules is unsafe and can lead to missed attacks. Therefore, it is recommended to specify the conditions for triggering the rule as much as possible using clarifications.
The clarification is applied as an occurrence of the specified template. Several clarifications interact with each other according to the principle of logical
& (for the rule to work, the main condition and all added clarifications must be met). Regular expressions are allowed to be used during clarification. For example, the regular expression
id=[a-z0-9]+, used in the refinement zone
Cookie, 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.
Additional conditions can be combined by adding new ones when creating/editing an exclusion rule. The rule is edited by clicking on .
Extended request blocking rules
The functionality of the extended request blocking rules is similar to the functionality of creating personal signatures. It allows you to create a request blocking rule with a combination of different parameters, but without the support of regular expressions.
The mechanism of extended request blocking rules allows you to use additional conditions 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,
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.
Unlike the functionality of creating personal signatures, the extended request blocking mechanism allows you to create a rule with a combination of various parameters, but without the support of regular expressions.
Creating a request blocking rule
To create a request blocking rule, go to the «Personal Blocking Rules (
ERL)» tab and click . After selecting the necessary options, you need to add one or more conditions by clicking on .
For all condition parameters (except
No Cookie), it is allowed to use multiple values in one parameter block using the logical condition operators «
not» (available only for the first value in the block), «and not», «or not». Operators do not have priority.
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.
Values for parameters can be entered in a list, for this you need to use the «multiline input» function. The values entered in the field will be combined with each other by the logical operator used for this field.
To add a new condition, select it from the list and repeat the process.
The parameters for the «Other headers» block are used in the key/value format and interact with each other according to the following principle:
- if there is a header, the content of only this header will be checked;
- if there is a header without content, any content of this header will be checked;
- if there is only the header content, the specified content in any header will be checked.
The rule is edited by clicking on .
Creating a list of blocked IP addresses
Allows you to create a list of IP addresses from which requests will be blocked for certain (or all) domains. To create a list, it is enough to specify the IP address(s) and the domain for which it is necessary to block access from these addresses. When adding data, a table will be displayed on the page, in which the following values will be specified:
- Domain – the domain for which requests from the specified IP address will be blocked;
- Number – the number of IP addresses added to the list.
Summary table of domains and the number of added IP addresses
IP addresses added without specifying the domain will be applied to all domains. IPv4/IPv6 addresses are allowed, including the use of CIDR (for example, x.x.x.x/24) and a range of IP addresses.
Information about requests from IP addresses from the blocked list is not sent to the Nemesida WAF API by default and is not displayed on the attacks page. To send information about a blocked IP address to the Nemesida WAF API, you must activate «Send to API» when adding it by clicking on .
Editing the list of blocked IP addresses
Clicking on the number of IP addresses will display a list of all the IP addresses added for the domain. When you click on an IP address, it will be automatically removed from the list.
List of added IP addresses for the domain example.com
IP addresses are displayed in two formats:
- – IP address added for this domain;
- – the IP address added for all domains, including the current one.
* near to the IP address means that incidents involving blocked requests from an IP address from the Blocked IP list will be sent to the Nemesida WAF API. To change the sending settings in the Nemesida WAF API for an IP address, you need to:
- click on an IP address;
- activate/deactivate «Send to Nemesida WAF API»;
- save changes.
To delete an IP address, click on it or enter a list using the input field. Green IP addresses refer to all domains and to delete them, you need to go to the appropriate list.
When you click on you can sort IP addresses by the «Send to Nemesida WAF API» option activated.
Managing the list of automatically blocked IP addresses
When you click on the interface for managing the list of automatically blocked IP addresses will be available. All addresses displayed on this page were automatically blocked when the allowed number of locks from one IP address was exceeded, which was set by the «Conditions for automatic IP address blocking» parameter. The following information is displayed on the page:
- The IP of the request source that was blocked;
- Remaining blocking time (in seconds).
When an IP address is removed from the list, it is automatically unblocked on the filtering node. To unlock the IP address, click on next to it. When you click on «Delete all» button all IP addresses will be removed from the list and unblocked on the all filtering node.
List of automatically blocked IP addresses