Protecting your web application infrastructure with the Nginx Naxsi firewall

Fire Protection

Core Ruleset

Naxsi comes with its own core ruleset; it contains generic signatures for SQL Injection (SQLi), Remote File Inclusions (RFIs), directory traversal, cross-site scripting (XSS), and some evading tricks, and it provides reliable protection against the exploitation of potential vulnerabilities. For example, the default installation detected and blocked [9] all ModSecurity bypasses by Trustwave Security Challenge in our lab. The core ruleset, consisting of about 50 rules, should always be loaded, even if most false positives occur in this area.

For sites with high potential for interaction, Naxsi will initially generate a lot of false positives. Whitelists help prevent the appearance of false positives. Whitelists can be location-based, which means you can maintain separate configurations for different areas or web applications on one server. Whitelists are easy to store in a file and then add to the configuration via include.

Whitelist rules are similar in structure to detection rules. The designator BasicRule is mandatory; it is followed by the rule ID, for which the exception should apply, followed by the match zone:

BasicRule wl:1000 "mz:$URL:/dontpanic/index.php|$ARGS_VAR:topic";
BasicRule wl:1005 "mz:$URL:/lib/exe/fetch.php|$ARGS_VAR:media";

Naxsi can be switched on or off at the location level; even parallel operation of Learning mode and Live mode is possible for different locations. The configuration of Naxsi is done in three steps: First, the administrator defines the rulesets to load at the HTML/server level. In the location context, the firewall is turned on and off or switched to Learning mode. Finally, the check rules specify the aggregated score, at which the firewall blocks the request. The individual configuration directives can be outsourced to files, which gives you a modular configuration (see Listings 3-5).

Listing 3


01 #LearningMode; #Enables learning mode
02 SecRulesEnabled;
03 #SecRulesDisabled;
04 DeniedUrl "/RequestDenied";

Listing 4

Check Rules

01 CheckRule "$SQL >= 8" BLOCK;
02 CheckRule "$RFI >= 8" BLOCK;
03 CheckRule "$TRAVERSAL >= 4" BLOCK;
04 CheckRule "$EVADE >= 4" BLOCK;
05 CheckRule "$XSS >= 8" BLOCK;
07 # UnWantedAccess -> see app-server.rules
08 CheckRule "$UWA >= 8" BLOCK;
10 # Identified Attacks
11 CheckRule "$ATTACK >= 8" BLOCK;

Listing 5

Naxsi Configuration via Includes

01 server {
02     ...
03     include        /etc/nginx/doxi-rules/rules.conf;
04     ...
05     location /dev/ {
06         ...
07         include        /etc/nginx/doxi-rules/learning-mode.rules
08         ...
09     }
11     location /live/ {
12         ...
13         include        /etc/nginx/doxi-rules/active-mode.rules
14         include        /etc/nginx/doxi-rules/local_whitelist.rules
15         ...
16     }
17 }

Doxi Rules

You don't need to just stand back and watch while your own server infrastructure is scanned for vulnerabilities day and night. The Doxi rules [10] were developed to detect a number of scans for current or older vulnerabilities (such as the WordPress TimThump-RFI [11]) and provide good protection against script kiddies and automated attack tools.

To allow this to happen, 200 server-specific rules were converted from the Emerging Threats rulesets to Naxsi format; they are freely available via the source code repository. On the basis of Emerging Threats, the rulesets are web_server.rules, scanner.rules, app_server.rules, web_apps.rules, and malware.rules. In a similar way to Emerging Threats, signatures are created when new vulnerabilities appear in popular apps or servers and then announced on the Naxsi mailing list and Doxi blog.

The Doxi tools [12] have emerged to help administrators keep their Naxsi installations up-to-date. Rulesets can be updated automatically from a centralized admin computer. With a simple, five-line Fabric recipe, the administrator can then update several WAFs simultaneously with new rulesets. The Doxi tools are suitable for production use; later versions should provide similar functions to Oinkmaster for updating Snort sensors.

Because Naxsi writes the events it detects to the Nginx error log, a small filter is all it takes to connect the application firewall with Fail2ban and punish multiple attempts with a ban at the IP level (see the Fail2ban configuration in Listing 6).

Listing 6

Fail2ban Configuration

01 # jail.conf
02 [naxsi]
04 enabled = true
05 port = http,https
06 filter = naxsi
07 logpath = /var/log/nginx/error.log
08 maxretry = 6
09 banaction = iptables-multiport-log
10 action = %(action_mwl)s
12 # filter.d/naxsi.conf
15 before = common.conf
17 [Definition]
18 failregex = NAXSI_FMT: ip=Host
19 ignoreregex = learning=1

Limits and Prospects

Naxsi is still in development, but it is already stable enough for production use. Currently, developers are extending Naxsi to include plugin APIs that will provide the opportunity to add custom detectors and modules, such as CSRF (Cross-Site Request Forgery) protection, loadable blacklists, or DDoS protection. Some features are still lacking, such as the filtering of outgoing responses, time-based thresholds to prevent brute-force attacks, and filtering by method (GET/POST/CONNECT).

Buy ADMIN Magazine

Get it on Google Play

US / Canada

Get it on Google Play

UK / Australia

Related content

  • The OpenResty distribution for Nginx
    Event-based request processing makes Nginx an agile web server. With the OpenResty packages, it becomes a fast application server based on the Lua scripting language.
  • Better compression of web pages
    Google develops a software tool that is a genuine alternative to Gzip, with improved website compression rates that save bandwidth for server operators.
  • Security first with the Hiawatha web server
    The small but secure Hiawatha web server provides an appealing alternative to the complex Apache and other alternatives.
  • Interview: Nginx's Gus Robertson
    The Nginx web server platform is not as well known as another open source web alternative known as Apache, but the fast and frugal Nginx is growing in popularity around the world as web admins contend with increased traffic and the challenges of container and cloud environments. We talked to Nginx CEO Gus Robertson.
  • Activate HTTP/2 on web servers
    HTTP/2 offers reduced website load times and other performance benefits, along with the promise of server push.
comments powered by Disqus
Subscribe to our ADMIN Newsletters
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs

Support Our Work

ADMIN content is made possible with support from readers like you. Please consider contributing when you've found an article to be beneficial.

Learn More”>


		<div class=