The most common issues while setting up the Nemesida WAF

Guide to solving main issues while setting up and operating the Nemesida WAF.

Content

Attacks not blocked
Attacks are blocked, but are not displayed in the Nemesida WAF Cabinet
The settings management functionality does not appear in the Nemsida WAF Cabinet
Real IP addresses of clients are not displayed
The behavioral model is not displayed in the Nemesida WAF Cabinet

🔗 Attacks not blocked

Nemesda WAF comes as a dynamic module for Nginx. After the initial configuration of the component, it is necessary to check the correct operation of the signature attack detection method by sending a http://YOUR_SERVER/nwaftest request.

The server should return a 403 response code, and an entry will appear in the error log of the Nginx web server:

Nemesida WAF: the request 5274fe3c397782a09b4f1b057e572e21 blocked by rule ID 1 in zone URL, ...

If the request is not blocked:

check that after making changes to the Nginx configuration, the nginx nwaf_update mla_main services were restarted;
check that the dynamic module /etc/nginx/modules/ngx_http_waf_module.so is in /etc/nginx/modules and included in /etc/nginx/nginx. conf;
check the size of /etc/nginx/nwaf/rules.bin file, it should not be empty. If you suspect a violation of the integrity of the file, you can delete it and download it again by restarting the nwaf_update service;
check if the request is received for processing by the Nginx web server, where the Nemesida WAF dynamic module is installed;
check that there are no request processing exclusion rules for the virtual host/IP address;
check that the IP address you are accessing from is not on the allow list (WL).

🔗 Attacks are blocked, but are not displayed in the Nemesida WAF Cabinet

In cases where attacks are blocked and displayed in the error log of the Nginx web server, but are not displayed in the Nemesida WAF Cabinet, you need to check:

the address of the Nemesida WAF API server is correctly set in /etc/nginx/nwaf/conf/global/nwaf.conf in the format nwaf_api_config host=http://api.example.com:8080/nw -api;
the proxy server address (if used) is correctly set for accessing the Nemesida WAF API in /etc/nginx/nwaf/conf/global/nwaf.conf;
correct installation and configuration of the Nemesida WAF API component, no errors in the log /var/log/uwsgi/nw-api/nw-api-logging.log;
the Nemesida WAF API server has access to the database to connect.

🔗 The settings management functionality does not appear in the Nemsida WAF Cabinet

To activate the Nemesida WAF settings management functionality, several conditions must be met:

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

🔗 Real IP addresses of clients are not displayed

Server with web application does not get real IP addresses of clients

All legitimate requests who not blocked by Nemesida WAF are sent to the web application upstream. In order for the web application to receive the correct client IP address from the filtering node (Nginx web server with the Nemesida WAF dynamic module installed), you need to add the set_real_ip_from header.

To do this, on the web application server, bring the configuration file nginx.conf to the form:

http {
...
   set_real_ip_from x.x.x.x;
...
}

x.x.x.x – filtering node address (Nginx web server with Nemesida WAF dynamic module installed).

After making the change, check the configuration and restart the Nginx service:

# nginx -t && service nginx reload

Real IP-addresses of clients are not displayed in the Nemesida WAF Cabinet

The Nemesida WAF Cabinet is designed to visualize information about attacks. All necessary information about the attack, including the source IP address of the requests, is transmitted from the dynamic Nemesida WAF module.

If an additional server processes requests in the reverse proxy mode and passes them to the filtering node (Nginx web server with the Nemesida WAF dynamic module installed), all requests will come with a single IP address of this server. To get correct information about client IP addresses, add the set_real_ip_from header.

To get the real IP addresses of clients, on the server with the Nemesida WAF dynamic module installed, bring the configuration file nginx.conf to the form:

http {
...
   set_real_ip_from x.x.x.x;
...
}

x.x.x.x – address of the server operating in the reverse proxy mode.

After making the change, check the configuration and restart the Nginx service:

# nginx -t && service nginx reload

🔗 The behavioral model is not displayed in the Nemesida WAF Cabinet

The Nemesida WAF Cabinet allows to manage behavioral models. To create a behavioral model, it is enough to add a virtual host in the section management Nemesida AI MLC settings. After 4 days of training, a behavioral model will be formed and available in the Nemesida WAF Cabinet. If the behavioral model is not available, then you need to check the Nemesida AI MLC /var/log/nwaf/mlc.log component log, paying attention to the following entries:

```
Current training progress for virtual host example.com: 5%
```
The entry means that the training has not been completed. When the progress is equal to 100%, the training will be completed automatically and the behavioral model will appear in the Nemesida WAF Cabinet.
```
An error occurred while sending the models of virtual host example.com to Nemesida WAF API: status: <Response [413]>
```
The entry means that the model has already been formed, but cannot be sent to the Nemesida WAF API due to its restrictions on the maximum size of the request body.

Solution: increase the value of the client_max_body_size parameter by bringing the configuration file /etc/nginx/nwaf/conf.d/nwaf-api.conf to the form:
```
server {

        ...

        client_max_body_size 64M;

        ...
}
```
The value of the parameter to be set must be greater than the value of the file size with the extension .ml in the directory /opt/mlc/ml/tmp/. After making changes, you need to restart the Nemesida WAF API component:
```
# systemctl restart nw-api rldscupd memcached
```
```
Not enough available memory (12%) to process
```
The entry means that there are not enough server hardware resources to handle the traffic.

Solution: increase the amount of server RAM.
```
Insufficient traffic to build behavioral models for virtual host example.com (required: 25)
```
The entry means that Nemesida AI MLC has not received enough traffic to build a behavioral model and training will continue.

Solution:
- check that the web application traffic goes to the filtering node;
- in the configuration file /opt/mlc/mlc.conf check that the connection details to the RabbitMQ service on the filtering node are correctly specified;
- check that the Nemesida AI MLC collects traffic from the corresponding RabbitMQ queue (no entries accumulate in the nwaf queue) on the filtering node.