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).

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

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;
06
07 # UnWantedAccess -> see app-server.rules
08 CheckRule "$UWA >= 8" BLOCK;
09
10 # Identified Attacks
11 CheckRule "$ATTACK >= 8" BLOCK;

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     }
10
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).

01 # jail.conf
02 [naxsi]
03
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
11
12 # filter.d/naxsi.conf
13
14 [INCLUDES]
15 before = common.conf
16
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).