A guide to using a cloud web application to manage Nemesida WAF settings.

General information
To configure Nemesida WAF, you can use a cloud web application MyWAF, access details to which are provided upon receipt of the license key.

The cloud web application allows you to manage:

  • settings of the Nemesida WAF dynamic module;
  • Nemesida AI MLC settings;
  • behavioral models;
  • synchronization of the settings of the dynamic module Nemesida WAF and Nemesida AI MLC;
  • signature exclusion rules and extended blocking rules.

First launch

After performing the initial configuration of servers with Nemesida WAF modules installed, you can complete the configuration using a web application. The details for the first connection are used as an email (login) and a license key (one-time password). In the future, you cannot use the license key as a password, so after a successful login, you need to set a new password and enable two-factor authentication.

Nemesida WAF Settings Management
The following pages are used to manage Nemesida WAF settings.

Keys

Section is intended for adding license keys. It is presented in the form of a table, where the following are indicated:

  • description of the key;
  • plan;
  • access to the functionality of the cloud API;
  • license key expiration date;
  • number of available behavioral models;
  • WAF ID;
  • available actions on the key.

To add a new key to the list, click , where we specify the license key and its description.

Actions on the key

You can perform 3 actions with the license key:

  • create an identification token;
  • change the description;
  • delete from the list.

An identification token is used instead of a license key to manage Nemesida WAF settings using the cloud API.

Nemesida WAF dynamic module

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.

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, example.com.

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

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 .

Rules management
The cloud web application allows you to create signature exclusion rules and advanced request blocking rules. To go to the rules management section, go to the section .

Exclusion rule

an exception rule is intended to exclude request processing using a rule. Detailed instructions for creating exclusion rules are available in corresponding section.

To create a rule, click on the

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

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.

Supported parameters
Options:

  • Active – activate/deactivate the rule. The rule can be activated temporarily, for this you need to specify the period (in hours) during which the rule will be active from the moment of creation. After the time expires, the rule will be deactivated until reactivation with the specified period. To activate a permanent rule, you need to clear the action time field;
  • Send to Nemesida WAF API – send the result of the rule triggering to the Nemesida WAF API module;
  • Do not affect the ban – if the parameter is not active, the request will be blocked when the rule is triggered, but the counter rate of the parameter nwaf_limit required to block the IP address of the request source will not increase;
  • Monitoring mode – processing of the rule in the LM mode (the rule is triggered, but the request is not blocked);

Conditions:

  • Virtual host – domain. It is allowed to use strict compliance and wildcard values: *, example.com, .example.com, *.example.com .;
  • URL – the occurrence of a string in the contents of the zone URL;
  • Country – country (for the functionality of determining geographical location based on IP address, you need to connect a file with the base GeoIP2 to /etc/nginx/nwaf/conf/global/nwaf.conf);
  • IP – the attacker’s IP address;
  • ARGS – occurrence of a string in the contents of the zone ARGS;
  • BODY – the occurrence of a string in the contents of the zone BODY;
  • User-Agent – the occurrence of a string in the contents of the zone User-Agent;
  • Cookie – the occurrence of a string in the contents of the zone Cookie;
  • No Cookie – applying the rule only to a request with an empty zone Cookie;
  • Referer – occurrence of a string in the contents of the zone Referer;
  • 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.

Rules created

To create a 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 “and”, “or”, “not” (available only for the first value in the block), “and not”, “or not”. Operators do not have priority.

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.

Other headers

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.

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.

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.

Creating Users
To share the Nemesida WAF settings management functionality, the administrator (the owner of the license key) can create additional users. Users inherit administrator rights, except for creating/deleting users.

To create a user, you need to send an invitation to an email and send a one-time activation code. An account that has not been activated will be grayed out.

After successful activation of the account, at the first login, the user needs to enable two-factor authentication. The following actions are available to the administrator for an activated account: reset the two-factor authentication setting, reset the password, or delete the user.

If the activation code is entered incorrectly more than 15 times, the registration process is interrupted, and the account is colored red. The administrator can delete the account signature , resend the invitation letter or generate a new activation code .

Action log
To view the log of user actions, go to the section .

Personal settings
In the section the user’s personal settings are presented, where he can change the password and enable two-factor authentication.