Nginx Free WAF: NAXSI vs Nemesida WAF Free
Today we would like to test and compare work of two free WAFs: NAXSI and Nemesida WAF Free. We will take into account ease of use, quality of preinstalled signatures, quantity of an attack missing and frequency of false positives.
About NAXSI
NAXSI means Nginx Anti XSS & SQL Injection. Its operation principle is following: «everything which is not allowed is forbidden». Every HTTP request (GET|PUT|POST only) is checked on the compliance to the patterns of prohibited rules set by default in file naxsi_core.rules. These rules cover 99% of all possible variants of malicious requests. For example, by default all requests in which URL double quote mark is content are prohibited. If for normal web application work this mark is necessary, you should make the corresponding exclusion in whitelist (WL). But there is other side — if allowed rules will be elaborate bad, NAXSI will block a part of the legitimate requests. That is why the vendors put the responsibility for the result on the system administrator. As a majority of modules for Nginx, NAXSI is not available from the repository, that is why you have to download and compile it manually.
About Nemesida WAF
The dynamic module of Nemesida WAF Free is a free WAF for Nginx based on the signature method with basic protection for a web application against OWASP class attacks. Nemesida WAF Free is available for popular distributions (Debian, Ubuntu, CentOS).
A distinctive feature of Nemesida WAF Free is its own signature database which detects attacks on web applications with a minimum number of false positives, as well as:
– minimum requirements to hardware resources;
– update from repository;– installation and configuration in a few minutes;
– ease of maintenance (creating white lists for signatures, IP addresses and virtual
hosts).
Setting Up
NAXSI
Before testing NAXSI, it is necessary to create whitelist rules for working with legitimate traffic. We added several rules in whitelist (on the below screenshot: there is pattern above the rule using which the legitimate request was blocked) to exclude blocking of the legitimate requests.
Briefly about the rules
We had added the first 5 rules in whitelist only to load the site. Rules deal with () <>, also were added in whitelist, because they are using while creating the content on the site (it is possible to write some of refinements in brackets and during the text edition use HTML tags). All in all if you will decide use NAXSI you should be ready to waste a lot of time for making WL. More than that with every WL a chance of an attack missing increases.
Nemesida WAF Free
After the installation Nemesida WAF Free a preset was not require, false positives were not detected.Configuration file Nemesida WAF Rules was not change:
SQLi
NAXSI
The first point of the compare testing will be the check for blocking SQL injection attacks rules taking into account whitelist. During the test of NAXSI one unpleasant moment was detected — it does not detect URL encode in cookie parameter, because of this the most of its default rules become useless, if to transmit payload in URL encode look. Attack like:
[“1807182982’)) uni”,”on sel”,”ect 1,2,3,4,5,6,7,8,9,’0’,11#”]will be blocked:
But if you will use URL encode, the request will change to:
%5B%221807182982%27%29%29%20uni%22%2C%22on
%20sel%22%2C%22ect%201%2C2%2C3%2C4%2C5%2C6%2C7%2C8%2C9%2C%2pentestit%27%2C11%23%22%5D
and will not be blocked:
When this URL encode occurs in Body/ARGS — NAXSI will perform a preliminary request URL decoding. As an example we tried to exploit an injection on the login page to pass an authorization, but, unlike previous example, NAXSI understood our intentions:
Nemesida WAF Free
Nemesida WAF Free uses double decoding of all zones, that is why all requests were blocked:
LFI
Further the possibility of the requests with LFI (Local File Inclusion) was test. As an example consider request in which we try to get file /etc/passwd (RCE) access. Every of WAFs blocked such request:
But response splitting:
cat /etc/pas?wd
will not allow to detect the signature and the attack will perform.
It is rather difficult to create signatures for such attacks, because of their wide variation. Machine learning module is able to detect such attacks (its variations, zero day attacks etc.), which is available in full version of Nemesida WAF.
XSS
The last step of the compare test will be attempt of bypassing WAF to exploit XSS vulnerability.
NAXSI
As previously mentioned, while the text content creation or edition on the site it is possible to use brackets or HTML tags. The need to add these characters to the white list for the correct site using led to possibility of performing XSS:
Nemesida WAF Free
The request was blocked:
Conclusion
NAXSI and Nemesida WAF Free functionalities are similar, but the last one is easier to install, update and set. There is only one advantage NAXSI has open-source code. At the same time NAXSI has two seriously disadvantages:
- preinstalled signatures do not allow to work with web application, while the whitelist creation encourage to bypass NAXSI;
- vulnerabilities in source code allow to bypass NAXSI (lack of URL decoding in cookie etc.). High quality of the signatures database of Nemesida WAF Free allows to use the module with the settings from the box without false positives. More than that, Nemesida WAF Free has functionality of an addition users rules, easy installation from repository and does not require an additional settings for basic work.
That is all! If you use NAXSI you must try Nemesida WAF Free.
