📜 ⬆️ ⬇️

Protection for NGINX - NAXSI

What is NAXSI?


NAXSI = N GINX A NTI X SS & S QL INJECTION
Simply put, this is a web application firewall (WAF) for NGINX that helps protect against XSS, SQL injection, CSRF, Local & Remote file inclusions.
Distinctive features of it are speed and ease of setup. This makes it a good alternative for example mod_security and apache.

Why do you need NAXSI?

Obviously, it is best to defend against the above attacks with properly written code. But there are situations when WAF (and in particular naxsi) will help:



Installation

Ubuntu, Debian, Netbsd, Freebsd : available as a package.
For example, in server ubunt 12.04 it is enough to make
apt-get install nginx-naxsi 

')
Other Linux systems:
If packages have not yet appeared, we collect nginx + naxsi from sources:
 wget http://nginx.org/download/nginx-xxxx.tar.gz wget http://naxsi.googlecode.com/files/naxsi-x.xx.tar.gz tar xvzf nginx-xxxx.tar.gz tar xvzf naxsi-x.xx.tar.gz cd nginx-xxxx/ 

(instead of xxxx - put the current version)

Check that there are libpcre dependencies (optional, libssl for https), and compile:
 ./configure --add-module=../naxsi-x.xx/naxsi_src/ [    nginx] make make install 


How does NAXSI work

NAXSI can check a GET request, HTTP headers (for example, cookies) and the body of a POST request using rule sets.
The basic set of prohibitive rules is quite simple and prohibits various “dangerous” characters and sql keywords.
This set of rules is quite hard, and may prevent the site from working correctly in some cases, so NAXSI implements white lists allowing the use of forbidden characters (rules) in the context you need.

When checking a query, it is run according to all the restrictive rules, with the exception of those placed on the white lists for its context, and the “penalty” points are calculated in six categories: $ SQL, $ XSS, $ RFI, $ TRAVERSAL, $ EVADE, $ UPLOAD.

If the number of “penalty” points is above the threshold level, the request is considered dangerous and an internal (for nginx) redirect to DeniedUrl specified in the configuration is made. In the form of get-parameters, comprehensive information on the reason for blocking, the original url and ip of the aggressor is transmitted to the specified url. At the specified address, you can either simply issue a return 403; or accumulate information about the attack in your NIDS system.
NAXSI can work in “learning” and “combat” modes.

In the learning mode, NAXSI itself can prepare for you a set of white lists based on user activity. Simply put, if users often violate one of the rules at the same URL, the rule is whitelisted and not blocked. These lists should be reviewed and corrected after graduation.

In combat mode, the breach simply leads to DeniedUrl.

NAXSI setup

Uncomment the inclusion of the basic prohibitive rules in the nginx configuration
 include /etc/nginx/naxsi_core.rules; 


Now add the desired settings to the virtual host configuration (I recommend putting them into a separate file and connecting via include):
 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; 


Let us examine in more detail what these commands mean:

White lists can be formed on the basis of the work of the training mode, or through the analysis of log files.

How to work with the rules and lists, as well as view statistics and benchmarks, I will tell in the next article.

If you are interested in NAXSI, you can familiarize yourself with good documentation on the project Wiki .

Source: https://habr.com/ru/post/145241/


All Articles