Guide to solving main issues while setting up and operating the Nemesida WAF.
🔗 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 thenwaf_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 formatnwaf_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.