Guide to fixing main problems in 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/app/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