NAXSI is Nginx Anti XSS & SQL injection. In simple words, it’s a firewall for web applications (WAF) for Nginx, protecting from XSS, SQL injections, CSRF, Local & Remote file inclusions. NAXSI is known for its fast working and simple configuring. It’s a good alternative for mod_security in Apache.
What would you need NAXSI for?
It’s obvious that’s the best way of protection from attacks is correctly written code, but in some situations WAF and particularly NAXSI can help:
- low quality of site code with no resources or possibilities of rewriting it;
- closed source code in which fixing mistakes is impossible;
- the quality of code is unknown and unpredictable (i.e. shared hosting).
For Ubuntu, Debian, NetBSD and FreeBSD NAXSI is available in packages.
For example, to install Nginx + NAXSI on Ubuntu 12.04 Server run:
apt-get install nginx-naxsi
If the package isn’t yet available for your system you can build it from sources:
wget http://nginx.org/download/nginx-x.x.xx.tar.gz wget http://naxsi.googlecode.com/files/naxsi-x.xx.tar.gz tar xvzf nginx-x.x.xx.tar.gz tar xvzf naxsi-x.xx.tar.gz cd nginx-x.x.xx/
Check if all dependencies ( libpcre, optionally libssl for https) are installed and run:
./configure --add-module=../naxsix.xx/naxsi_src/ [your options for nginx] make make install
How NAXSI works
NAXSI can check GET-requests, HTTP headers (for example cookies) and POST-request body by rules. NAXSI core rules are pretty simple. They forbid “dangerous” symbols and SQL keywords.
Those rules are pretty strict and can in some cases even prevent your website from working correctly. In this case you can use whitelists. Whitelists allow using some forbidden symbols and rules when you need them.
Requests are being first checked by core rules except for whitelists. Then we have local checkrules: $SQL, $XSS, $RFI, $TRAVERSAL, $EVADE and $UPLOAD which set how strict your website will be, and set the max tolerated page score before a request is denied.
If the score indicates that the request is to be denied the user will be redirected to the page defined in the configuration (DeniedURL). The reason of blocking, original URL and attacker’s IP address will be sent to this URL. You can either return 403 or register attack information in your NIDS system.
NAXSI learning and production modes
NAXSI can work in learning mode or in production mode.
In learning mode NAXSI can provide you with white lists based on users activity. For example, when users often break one of the rules with the same URL the rule is being put into white list and is not blocked. You can check these lists after learning stage and edit them the way you need it.
In production mode rule breaking results in DeniedURL.
In Nginx configuration file add this activation of basic rules:
Add required settings to the virtual host configuration (i.e. inside of “location /” section):
LearningMode; SecRulesEnabled; DeniedUrl "/RequestDenied"; include "/etc/nginx/mynaxsi.rules"; ## check rules CheckRule "$SQL >= 8" BLOCK; CheckRule "$RFI >= 8" BLOCK; CheckRule "$TRAVERSAL >= 4" BLOCK; CheckRule "$EVADE >= 4" BLOCK; CheckRule "$XSS >= 8" BLOCK;
Some important notes:
- LearningMode – activates learning mode when requests aren’t blocked and white lists are created;
- SecRulesEnabled – NAXSI is activated for this location. If you want to disable it (for example, for some secured inner location) write SecRulesDisabled in it’s section;
- DeniedURL – redirect URL for blocked requests;
- CheckRule – per-category check scores
- /etc/nginx/mynaxsi.rules – NAXSI rules. It’s empty for now, it’ll be filled at runtime by the learning daemon.