How we fought xss / sql attack with Nginx and Naxsi

Most recently, at the height of the working day, we received alarming information from the client that their site was undergoing XSS / SQL attacks, some of which were successful. It was necessary to take urgent measures and set up basic protection within a few hours, because developers were not able to quickly find and eliminate imperfections of the code.

After some deliberation, the choice fell on the firewall of web applications for nginx called naxsi, which is technically a nginx module. Naxsi works on the principle: everything that is not allowed is prohibited. Each HTTP request (GET | PUT | POST) is checked for compliance with the rules of the prohibiting rules specified by default in the file naxsi_core.rules. These simple rules cover 99% of all possible malicious requests. For example, by default, all requests in URI which contain the character "<" are prohibited. If for the application the use of such a symbol is necessary for normal operation, then you need to manually write the corresponding exceptions to the white list.

This approach provides a high level of protection, since for naxsi, there is no such thing as an “unknown type of attack”, as it can be with other protection systems that use signatures of known vulnerabilities in filtering. But there is also a downside: if the permitting rules are worked out badly, then naxsi will also block some legitimate requests. Responsibility for the final result of the developers of the module is entirely placed on the system administrator. With these thoughts we set about installing the module.
')
The client site is running CentOS 6. Unfortunately, there was no ready-made nginx package with the naxsi module enabled for CentOS 6, so you had to compile it yourself.

In our company there is a policy according to which it is prohibited to install any of the sources, therefore, to solve the problem, my colleague assembled an rpm package, which, if desired, can be taken in our repository .

Installation from the package:

rpm -Uvh http://rpms.southbridge.ru/southbridge-rhel6-stable.rpm yum install -y nginx-naxsi 

Add nginx to autorun:

 chkconfig nginx on 

Create a file with standard naxsi rules:

 wget -O /etc/nginx/naxsi_core.rules https://raw.githubusercontent.com/nbs-system/naxsi/master/naxsi_config/naxsi_core.rules 

We include standard prohibiting rules in the nginx config in the http context:
/etc/nginx/nginx.conf

 http { ... include /etc/nginx/naxsi_core.rules; ... } 

Create a naxsi configuration file:

 touch /etc/nginx/my_naxsi.rules cat << EOF >/etc/nginx/naxsi.rules LearningMode; #  .  SecRulesEnabled; #SecRulesDisabled; DeniedUrl "/RequestDenied"; include "/etc/nginx/my_naxsi.rules"; ## check rules CheckRule "$SQL >= 8" BLOCK; CheckRule "$RFI >= 8" BLOCK; CheckRule "$TRAVERSAL >= 4" BLOCK; CheckRule "$EVADE >= 4" BLOCK; CheckRule "$XSS >= 8" BLOCK; EOF 

We enable naxsi for the desired virtual host:

 server { ... set $naxsi_extensive_log 1; #      ... location / { ... include /etc/nginx/naxsi.rules; ... } ... location /RequestDenied { return 500; #  ""    500 } ... } 

Restart nginx:

 service nginx restart 

From now on, naxsi works in a learning mode. No requests are blocked, but are actively recorded in the errorlog for the specified virtual host nginx. In order not to disrupt the site’s future work, in the learning mode it is necessary to ensure the load of the site with legitimate traffic so that as many different requests as possible will arise in its usual mode. work.

After learning, go to the generation of exceptions (whitelists) for the basic prohibitory rules. This can be done both manually and automatically using the nx_util.py utility.

 wget -O /tmp/naxsi.zip https://github.com/nbs-system/naxsi/archive/0.53-2.zip unzip /tmp/naxsi.zip rm -f /tmp/naxsi.zip sed -i 's/\/usr\/local\/etc/\/tmp\/naxsi-0.53-2\/nx_util/' /tmp/naxsi-0.53-2/nx_util/nx_util.py python /tmp/naxsi-0.53-2/nx_util/nx_util.py -l <///errorlog-> -o 

The utility parses the errorlog file for records from NAXSI and prints the generated list of exceptions to stdout, sorted by the frequency of operations. In this case, the rules from the bottom of the list can be commented out by default.
The data generated exceptions, their completeness and correctness are the main factor - how effectively the Naxsi filtering will be applied. Automatically generated rules must be analyzed and, if necessary, edited. You can understand the syntax of the rules by studying the official documentation.
We copy the obtained whitelist rules into the /etc/nginx/my_naxsi.rules file.
Turn on combat mode naxsi:

 sed -i 's/LearningMode/#LearningMode/' /etc/nginx/naxsi.rules 

Restart nginx:

 nginx -t service nginx reload 

Basic setup complete!
If, while the module is in combat mode, any legal requests are still unrecorded and blocked, then you need to add them to the white list in the /etc/nginx/my_naxsi.rules file. To do this, you can rerun nx_util.py or learn how to analyze NAXSI records in errorlog and write exceptions yourself.
Check whether any requests get blocked or not by:

 cat <///errorlog-> | grep NAXSI 

This is how in just a few hours the basic protection of the site against XSS / SQL attacks was organized. And the developers, without haste, continued to eliminate the imperfections in the code.

That's all. Thanks for attention!

By Last_Lame

We will be happy to answer any questions in personal correspondence or by mail ask@centos-admin.ru