June 5, 2012 at 13:20

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, which helps protect against XSS, SQL injection, CSRF, Local & Remote file inclusions.
    Its distinctive features are speed and ease of setup. This makes it a good alternative, such as mod_security and apache.

    Why is NAXSI needed?

    Obviously, it is best to defend against the above attacks with correctly written code. But there are situations when WAF (and in particular naxsi) will help:
    • Poor quality of the site code, in the absence of the ability / resources to throw everything out and rewrite normally.
    • “Closed” code in which it is impossible to fix errors.
    • Unknown code quality in a business critical area.



    Installation

    Ubuntu, Debian, Netbsd, Freebsd : Available as a package.
    For example, in server ubunt 12.04 it’s enough to do
    apt-get install nginx-naxsi


    Other Linux-systems:
    If the packages have not yet appeared, collect nginx + naxsi from the 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/

    (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 NAXSI Works

    NAXSI can check the GET request, HTTP headers (for example, cookies) and the body of the POST request against the rule sets.
    The basic set of prohibition rules is quite simple and prohibits various “dangerous” characters and sql keywords.
    This set of rules is quite tough, and can interfere with the correct operation of the site in some cases, therefore NAXSI has white lists that allow the use of prohibited characters (rules) in the context you need.

    When checking a request, it is run according to all prohibitive rules, with the exception of whitelisted ones for its context, and “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 performed. In the form of get-parameters comprehensive information about the reason for blocking, the original url and ip of the aggressor is transmitted to the specified url. At the specified address, you can or simply return 403; or accumulate information about an attack in your NIDS system.
    NAXSI can work in “learning” and “combat” modes.

    In Learning Mode, NAXSI itself can prepare a set of white lists for you 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 are worth reviewing and adjusting after graduation.

    In combat mode, the violation simply leads to DeniedUrl.

    Configuring NAXSI

    Uncomment the inclusion of basic restrictive 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 in 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:
    • LearningMode - learning mode is on. Requests are not blocked, a whitelist is generated.
    • SecRulesEnabled - NAXSI is enabled for this location. If we want to turn it off for another location (for example, a protected internal zone), then we make SecRulesDisabled in it.
    • DeniedURL - redirect URL for denied requests.
    • CheckRule - check “penalty points” of a request by category.
    • /etc/nginx/mynaxsi.rules - generated rules (not generated yet - commented out).

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

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

    If you are interested in NAXSI, you can read the good documentation on the project Wiki .
    Tags:

    Also popular now: