Ⅳ. Nemesida WAF Cabinet | Nemesida WAF

Before installing the Nemesida WAF Cabinet module, you must install and configure the Nemesida WAF API module and PostgreSQL.

Below is a brief guide to the commissioning of the local version of the Nemesida WAF Cabinet on servers running Linux. To install the module you must perform following steps:

1.Install and configure the PostgreSQL DBMS:

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

# apt update && apt upgrade
# apt install postgresql

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

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

# setenforce 0

# 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

# 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

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

# 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_cabinet cabinet. When connecting, enter the user’s password nw_cabinet.

# /bin/bash ./3-cabinet-deploy.sh 'pg_srv_ip=%PostgreSQL server address%' 'pg_srv_port=%PostgreSQL port%' 'pg_api_pwd=%Password%' 'pg_cabinet_pwd=%Password%' 'api_url=%Nemesida WAF API URL%' 'proxy=%Proxy server address%' 'api_proxy=%Proxy server address%'

# timedatectl set-timezone Europe/Moscow
# echo 'Europe/Moscow' > /etc/timezone

# apt install apt-transport-https gnupg2 curl

# 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

# 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 install nginx python3 python3-venv python3-dev python3-reportbug python3-pip memcached libmemcached-dev postgresql-server-dev-all gettext libpcre3-dev pkg-config libcairo2-dev
# apt install nwaf-cabinet

# timedatectl set-timezone Europe/Moscow
# echo 'Europe/Moscow' > /etc/timezone

# apt install apt-transport-https gnupg2 curl

# 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.9-venv build-essential python3.9-dev python3.9-reportbug python3-pip memcached libmemcached-dev libpq-dev gettext libpcre3-dev pkg-config libcairo2-dev

# 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-venv build-essential python3-dev python3-reportbug python3-pip memcached libmemcached-dev libpq-dev gettext libpcre3-dev pkg-config libcairo2-dev

# 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-venv build-essential python3-dev python3-reportbug python3-pip memcached libmemcached-dev libpq-dev gettext libpcre3-dev pkg-config libcairo2-dev

# apt install nwaf-cabinet

# timedatectl set-timezone Europe/Moscow
# echo 'Europe/Moscow' > /etc/timezone

[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

# dnf install epel-release
# dnf update
# dnf install nginx python39 python39-devel python39-setuptools python39-pip gcc memcached postgresql-devel gettext pcre-devel pkg-config cairo-devel

# dnf install epel-release
# dnf update
# dnf install nginx python3 python3-devel python3-setuptools python3-pip gcc memcached postgresql-devel gettext pcre-devel pkg-config cairo-devel

# dnf install nwaf-cabinet

3. Make the necessary changes to the /var/www/app/cabinet/settings.py file:

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

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

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

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

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

API_URI = 'http://api.example.com:8080/nw-api/'

4. Allow access:
When deploying the database locally:
– to the Memcached server 127.0.0.1:11211;
– to a PostgreSQL DBMS server 127.0.0.1:5432;
– to a server with Nemesida WAF API 127.0.0.1:8080.
When deploying the database on a separate server:
– to the Memcached server 127.0.0.1:11211;
– to the server with the PostgreSQL database <server_ip>:5432;
– to a server with Nemesida WAF API 127.0.0.1:8080.

5. In firewall settings allow the requests to 80 port (is set by default in the file /etc/nginx/conf.d/cabinet.conf).

6. Run the migration and set the administrator password:

# cd /var/www/app/ && . venv/bin/activate && python3 manage.py check_migrations && python3 manage.py migrate && python3 manage.py createsuperuser && deactivate

7. Activate the virtual host:

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

8. Restart the server and test the module:

# systemctl status nginx cabinet cabinet_ipinfo cabinet_attack_notification cabinet_cleaning_db cabinet_rule_update memcached

Information about errors in the work of the Nemesida WAF Cabinet is contained in the event logs of the module /var/log/uwsgi/cabinet/*.log.

For security reasons, it is necessary to restricted access to the web interface of the Nemesida WAF Cabinet module to a list of allowed IP addresses to prevent unauthorized users from managing the Nemesida WAF work processes.

Proxying settings

If you use an intermediate server to proxy the traffic of Nemesida WAF Cabinet, you must set the option proxy_set_header Host $http_host when configuring proxying on the intermediate server:

Example:

server {
        server_name lk.example.com;
        listen 80;

        location / {
                proxy_pass http://x.x.x.x;
                proxy_set_header        Host $http_host;

        }
}

where x.x.x.x is the address of the Nemesida WAF Cabinet server.

The Nemesida WAF Cabinet, available at YOUR_SERVER/waf/personal/, contains information on the work of the main (Nemesida WAF, Nemesida WAF Scanner, Nemesida WAF AI) and auxilary modules Nemesida WAF.

When you click on the icon a list of events is displayed.

The following icons are used as an indicator of the application of behavioral models:

• displays when machine learning module is not the reason of the request blocking (BT 2, 6, 7);
• displays when behavioral models are in the process of being retrained;
• displays when the reason of the request blocking is machine learning module (BT 3, 8).

More information about the reasons of the request blocking by Nemesida WAF module is available in corresponding section.

To limit the display of information in the search field, the logical operators «!» (exception) and «and» (association) are available.

vuln

t:bf

t:ddos

bt:1

waf_id:dd8636c32d177c0c74416c19429a8c4d

group_id:dd8636c32d177c0c74416c19429a8c4d

rule:1022

body:test

mz:cookie

url:index.php

h:example.com and possible

h:example.com and !ip:1.2.3.4

h:1.example.com and h:2.example.com !t:SQLi

h:example.com t:SQLi ip:1.2.3.4 and ip:4.3.2.1

For requests, which were blocked by signature method, the field Rule ID is available. If you will click on this field, in the pop-up window following information will display:

• the information about the signature structure;
• the exception rule (WL) for adding in Nemesida WAF configuration file.

More information about signatures and exception rules is available in the corresponding section of the guide.

When you hover the cursor over the flag of the country next to the IP address, extended information about it will be displayed based on IP geolocation data (for example, whether the IP address belongs to a hosting provider or proxy server, whether the IP address is blacklisted, etc.).

When you click on button near the IP address, a dialog box will appear that will suggest blocking the IP address for calls to the specified domain. You can manage the list of blocked IP addresses in corresponding section.

Recheck functionality

Except the main functionality Nemesida WAF Scanner allows to operate resending of the blocked request content and/or different various on the protected web application. Users are included in «Administrators» group are able to operate this check using button , which becomes available when the grouping for detected attacks XSS, SQLI, LFI, RFI types, that have BT 1 or 2, is switched off. The verification status is displayed instead of the button . In case the vulnerability detection the information will be available in the section «Scanner» in Nemesida WAF Cabinet. The administrator can exclude the request by clicking on . Then information about this request will be available in the admin panel in the «Scanner» tab. To use Recheck functionality you should set up section [recheck] in file /opt/nws/main.conf.

Using Recheck can lead to the execution of arbitrary code from the request on the web application side. Use the functionality only if you are completely confident in your actions.

Possible meanings:

• Validation — check is processing;
• – vulnerability is detected;
• – vulnerability is not detected;
• – an error occurred while processing the request by the vulnerability scanner.

Unlock Request functionality

A user of Nemesida WAF Cabinet, who considers the blocking of the request to be erroneous, can send an application to unlock it to the administrator by pressing the button . An email with a description of the order will be sent to the administrator. The list of all orders is located in the tab in the admin panel. The request can be unlocked or left locked. To unlock the request, the administrator needs to create a appropriate rule for Nemesida WAF, after which the user will receive a notification.

The table All attacks displays the quantitative indicators of anomalous requests for a specific period of time and by their categories.

The schedule Attacks intensity displays the intensity and dynamics in the context of a given period and selected categories of attacks.

The charts Last 24 h. and Top by IP display the Top-10 domains that were attacked and Top-10 IP addresses from which anomalous requests came.

To limit the display of information in the search field, the logical operators «!» (exception) and «and» (association) are available.

vuln

t:bf

t:ddos

bt:1

waf_id:dd8636c32d177c0c74416c19429a8c4d

group_id:dd8636c32d177c0c74416c19429a8c4d

rule:1022

body:test

mz:cookie

url:index.php

h:example.com and possible

h:example.com and !ip:1.2.3.4

h:1.example.com and h:2.example.com !t:SQLi

h:example.com t:SQLi ip:1.2.3.4 and ip:4.3.2.1

You can search for events both in normal mode (without specifying special parameters) and in advanced mode, using the following filters:

To limit the display of information in the search field, the logical operators «!» (exception) and «and» (association) are available.

h:example.com

!t:SQLi

u:/search.php

p:id

!h:example.com and t:SQLi

Clicking on the page opens a page with a list of detected vulnerabilities with tracking of their re-discovery/fixed for a selected period, just select the time interval for displaying records, where:

• – new vulnerability/re-discovered;
• – vulnerability is fixed/not re-discovered.

• change password;
• add a license key to manage WAF and API Firewall settings, view the event log of the operation of the Nemesida WAF components;
• configure sending notifications about attacks.

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 API_URI (file /var/www/app/cabinet/settings.py).

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 nemesida-security.com.

Filtering node

After clicking on the Nemesida WAF filtering node 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 filtering node, 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, 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 .

Managing rules

The Nemesida WAF Cabinet allows you to create signature exclusion rules and extanded request blocking rules. To go to the rules management section, go to the section .

Exclusion rules

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:

• virtual host (domain name);
• Required: 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;
• Required: signature occurrence zone (for example, ARGS, BODY, HEADERS, etc.). Multiple zones can be selected at once, then the signature will be excluded when detected in any of the listed zones;
• Recommended: clarification zone. It is allowed to add several clarifications, then the signature will be excluded if the conditions of each clarification are met. Regular expressions are allowed.

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

Creating a request blocking rule

To create a request blocking rule, go to the «Extended 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.

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.

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.

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 .

Searching for an IP address

When adding a large number of IP addresses, visually searching for the desired IP address is difficult. In this case, you need to use the IP address search functionality. There are 2 types of search:

• Global search (search for an IP address among all lists);
• Local search (search for an IP address in the list of a specific virtual host).

Global search
Since the same IP address can be blocked for different virtual hosts, when deleting an IP address, for example, for example.com requests from the IP address 1.1.1.1 will still be blocked for other virtual hosts if it was added for them as well. In order to find a complete list of virtual hosts for which an IP address has been added, you must enter the IP address in the appropriate field.

The table will contain virtual hosts whose block list contains the desired IP address.

Additionally, you can set a list of IP addresses separated by a space to search for each of them. In addition to the space, the following characters are available as a separator: | and ,. For example:

• 46.73.103.114 34.159.7.65
• 46.73.103.114|34.159.7.65
• 46.73.103.114,34.159.7.65

Local search
Local search involves searching for the right IP address for a specific virtual host.

Additionally, you can set a list of IP addresses separated by a space to search for each of them. In addition to the space, the following characters are available as a separator: | and ,. For example:

• 46.73.103.114 34.159.7.65
• 46.73.103.114|34.159.7.65
• 46.73.103.114,34.159.7.65

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.

IP addresses are displayed in two formats:

• – IP address added for this domain;
• – the IP address added for all domains, including the current one.

The symbol * 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.

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.

Before sending a request to the Nemesida API Firewall for analysis of compliance with the specification, the method by which the request was sent is checked. If the request method does not match GET, POST, PUT, PATCH, DELETE, HEAD, OPTIONS or TRACE, the request will be blocked.

To use the functionality, several conditions must be met:

• added a license key with the Business or Enterprise plan in user settings;
• the functionality is activated by the administrator;
• the address of the connection to the Nemesida WAF API is specified in the parameter API_URI (file /var/www/app/cabinet/settings.py).

For the Business and Enterprise plan, the functionality is managed locally (the created specifications are stored in the local database).

Adding a specifications

To add a new specifications you must:

• click ;
• in the dialog box, you need to specify the specification’s name. Strict matching and wildcard values are allowed in the specification’s name: example.com, .example.com, *.example.com, *;
• upload the specification file in JSON or YML formats.

To work correctly, you must use the OpenAPI v3.1 specification.

The added specification is applied by the Nemesida AI MLA module, which will analyze requests for compliance him.

When clicking on you can edit specification’s name.

When clicking on the specification file is being downloaded to the local computer.

Button allows you to delete the specification. To remove individual elements from the specification, select the appropriate elements and click

After adding the specification, you can view it for each URL by clicking on it.

If it is necessary to sort the specifications by method, select the appropriate method from the suggested list

Specification Setup

Tab allows you to add a specification for URLs that are generated by the Nemesida AI MLC module during request analysis. To start the analysis process, you need to add virtual hosts in the section Nemesida AI MLC settings. To combine with existing specification, you can select several elements (or all) and click on . After that, the URLs (paths) will be added to the existing specification or a new one will be created, if there is no one for the virtual host.

When you click it will be possible to delete/exclude the URL. In case of an exception, the URL will not be used in the future when creating the specification.

URL Exclude

When clicking on a list of URLs excluded from the analysis by the Nemesida AI MLC module opens. Excluded URLs will not participate in creating a request specification in the OpenAPI format.

• added a license key with the Business or Enterprise plan in the user settings;
• the functionality is activated by the administrator.

All events from Nemesida AI are rendered on the main page («Attack») for the next processing. The main page displays events received via the Nemesida WAF API from the machine learning module, of the following type:

BT 11

The request was identified by the signature method as an attack, but by decision of the Nemesida AI module it was unblocked. There are several situations to consider when handling events from BT 11:

Situation	Solution
After additional analysis, Nemesida AI unblocked the request, identified by signature analysis as an attack.	The incident record can be deleted by click .
After additional analysis, Nemesida AI unblocked the request with the attack.	In this case, it implies the presence in the request of attack features that do not fall under the condition of unconditional blocking by signature analysis (score equals 12), but sufficient for sending for additional analysis by machine learning. If requests with clear signs of attack are unblocked by Nemesida AI, this means that the behavioral model is not trained accurately enough and that it is necessary to retrain the model. It is recommended to create a blocking rule for the time of training, using the Personal blocking rules.

BT 12

The request was blocked by the Nemesida AI module and was not defined by the signature method as an attack. When processing events from BT 12, it is necessary to carefully analyze the content of the zone where the anomaly was detected and take one of the following actions:

Situation	Solution
The content of the zone has signs of an attack.	The incident record can be deleted by click .
The contents of the zone show no signs of attack.	The request is evaluated as «False Positive» and is exported completely. To export a request, click the . It can be executed when the content of the request contains no signs of an attack.
	The request is treated as «False Positive» and is exported with editing the content of the zone where the anomaly is detected. Applies in cases where the zone content contains dynamic data. Example: csrf=29id2jr_@e29ei2fffw To export with editing the contents of a zone, click the and delete dynamic data.

BT 13

The request is blocked by the Nemesida AI module and by the signature method. The actions when analyzing events of this type are performed similarly to the BT 12:

Situation	Solution
The content of the zone has signs of an attack.	The incident record can be deleted by click .
The contents of the zone has not signs of attack.	The request is evaluated as «False Positive» and is exported completely. To export a request, click the . It can be executed when the content of the request contains no signs of an attack.
	The request is treated as «False Positive» and is exported with editing the content of the zone where the anomaly is detected. Applies in cases where the zone content contains dynamic data. Example: csrf=29id2jr_@e29ei2fffw To export with editing the contents of a zone, click the and delete dynamic data.

Events of type BT 11 and BT 13 are not passed to the Nemesida AI MLC module.

Exported «False Positive» requests will be considered by Nemesida AI as an example of a legitimate request.

When retraining the behavioral model (after the retraining process is completed), it is recommended to delete the exported “False Positive” queries to reduce the load on the Nemesida AI module and reduce the processing time of the request by the machine learning module.

The search field is available for requests’ filtering. It allows to select requests using occurrence of word(s) and using special operators.

ip:1.2.3.4

host:example.com

method:post

mz:body

bt:12

request_id:0a509eae749e62f2fe5c84

timestamp:11.05

cookie:csrf=1

ua:mozilla

referer:example.com

headers:example.com

url:/test

args:id=1

agent:MLC

waf_id:1601403941

ip:1.2.3.4 and url:/test

host:example.com and method:post

referer:example.com and bt:11

Navigation bar functions

Delete of the tagged records.

Record management of the main page functions

	Request export into the table.
	Delete marked request.
	Request contain editing with next export into the table.
	Display of extended information about the request.
	Checking the request using signature method.

• added a license key with the Enterprise plan in user settings;
• the functionality is activated by the administrator;
• the address of the connection to the Nemesida WAF API is specified in the parameter API_URI (file /var/www/app/cabinet/settings.py ).

By default, the data is loaded for the entire time, but a selection of events for a certain period is available at the top of the page. A selection of event display criteria is also available. Sorting of events is available according to the following criteria:

When you click on , a report in CSV format will be created. To delete records, select several (or all) records and click on .

List of the users

The tab contains a list of all users. When you click on the icon the user is being deleted. When you click on the icon the user editing window opens.

Vulnerability Scanner

In the admin panel, the tab displays requests that the administrator has excluded from the list of vulnerabilities.

List of all applications for unlocking requests

The tab displays a list of applications for unlocking requests. When you click on , the request is deleted.

Administrator can edit the request by clicking on .

Add new user

The tab contains window for adding a new user.

To add a new user, fill in the following fields:

Configuring the mail server

In the tab the administrator can configure the connection to the mail server to send email attack alerts.

When clicking on the icon the administrator can edit the settings.

To configure the mail server, you need to fill in the following fields:

Removing attacks

In the tab the administrator can configure automatic removal of attacks from the Nemesida WAF Cabinet. When deleting attacks from your Nemesida WAF Cabinet, information about them will also be deleted from the database.

When clicking on the icon the administrator can add a new task to the list.

To add a task, you need to fill in the following fields:

When clicking on the icon the administrator can edit the task settings, and when clicking on it is being deleted.

Tasks created by the administrator will be triggered according to the schedule every 60 minutes. When clicking on the icon active tasks will be forced to run outside the schedule.