Using the ModSecurity Rules from Trustwave SpiderLabs with NGINX WAF
Note: The NGINX Plus with ModSecurity WAF is now known as NGINX WAF.
This article explains how to configure the ModSeurity Rules form Trustwave SpiderLabs for use with the NGINX Plus with ModSecurity WAF.
NGINX Plus Release 12 and later supports the NGINX Plus with ModSecurity web application firewall (WAF). The ModSecurity WAF protects web applications against various Layer 7 attacks; provides DDoS mitigation, real‑time blacklisting, audit logging; and enables PCI‑DSS 6.6 compliance.
The ModSecurity Rules form Trustwave SpiderLabs complement the Open Web Application Security Project Core Rule Set (OWASP CRS) with protection against specific attacks of multiple categories – including SQL injection, cross‑site scripting (XSS), local and remote file includes (LFI and RFI) – for many common applications (ASP.NET, Joomla, WordPress, and many others). Additionally, the Trustwave SpiderLabs Rules provide IP reputation along with other capabilities, and are updated daily.
This chapter builds on the basic configuration in Installing the NGINX Plus with ModSecurity WAF, showing how to configure the Trustwave SpiderLabs Rules to protect the demo web application created there.
The NGINX Plus with ModSecurity WAF also supports the OWASP CRS as described in Using the OWASP CRS with the NGINX Plus with ModSecurity WAF.
NGINX Plus with ModSecurity WAF is available to NGINX Plus customers as a downloaded dynamic module at an additional cost. To purchase or start a free trial of NGINX Plus with ModSecurity WAF, or add the ModSecurity WAF to an existing NGINX Plus subscription, contact the NGINX sales team.
You must purchase the Trustwave SpiderLabs Rules directly from Trustwave.
As noted above, this chapter builds on Installing the NGINX Plus with ModSecurity WAF and assumes you have following the instructions there to configure the demo application and NGINX Plus as a reverse proxy.
Purchasing the Trustwave SpiderLabs Rules gives you access to the ModSecurity Dashboard, which is a web portal where you can customize the Trustwave SpiderLabs Rules on individual instances of NGINX Plus with the ModSecurity WAF (and other ModSecurity installations). The Dashboard simplifies configuration compared to the OWASP CRS, in two ways:
- You don’t need to download rules onto individual NGINX Plus instances, because the ModSecurity WAF dynamic module downloads them automatically when the
SecRemoteRulesdirective is included in the ModSecurity configuration (see Step 3 in the next section).
- You enable and disable rules – a significant part of the configuration process – with a GUI on the Dashboard instead of in ModSecurity configuration files.
To configure the Trustwave SpiderLabs Rules for the demo application, first create a profile (or use the default one) that includes selected rules for protecting the application. Then modify the local ModSecurity configuration to make the ModSecurity dynamic module download and apply the rules. The instructions use the Configuration Wizard on the Dashboard for creating a profile.
Detailed instructions for using the Dashboard are not provided here. For more information, log in to the Dashboard to access the Dashboard FAQ.
To configure the Trustwave SpiderLabs Rules for the demo application, perform the following steps:
Log in to the ModSecurity Dashboard and start the Configuration Wizard.
Create a profile, enabling rules that are relevant for your application. None of the existing rules actually apply to our demo application, but for the purposes of this step select the WordPress‑related rules. You can also enable additional options, such as IP reputation.
At the Configure your server step, the Wizard presents the
SecRemoteRulesdirective that must be added to the ModSecurity configuration, similar to the line below:
SecRemoteRules license‑key https://url
SecRemoteRulesdirective configures ModSecurity to download rules from the remote server, represented by the url, using the provided license‑key.
The Wizard does not provide an interface for adding the directive, so you need to eEdit /etc/nginx/modsec/main.conf manually and add the
SecRemoteRulesdirective presented by the Wizard (we created the file in Step 4 of Protecting the Demo Web Application). Comment out any other rules that might already exist in the file, such as the
SecRuledirective from that section.
# Include the recommended configuration Include "/etc/nginx/modsec/modsecurity.conf" SecRemoteRules license‑key https://url
By default, the Trustwave SpiderLabs Rules only detect malicious requests and don’t block them. To block the requests, add the following lines to /etc/nginx/modsec/main.conf below the SecRemoteRules directive you added in the previous step:
SecDefaultAction "phase:2,log,auditlog,deny,status:403" SecDefaultAction "phase:1,log,auditlog,deny,status:403"
SecDefaultActiondirective defines the default list of actions for the rules, with the
denyaction blocking malicious requests and returning status code
Reload the NGINX Plus configuration:
$ sudo nginx -s reload
Reloading takes time as the rules are being downloaded from the remote server.
Once the Wizard reports that NGINX Plus downloaded the rules, you can close the wizard and start testing the rules.
In Using the OWASP CRS with the NGINX Plus with ModSecurity WAF, we use the Nikto scanning tool to test how the CRS blocks malicious requests. However, Trustwave SpiderLabs rule are specific rules that cannot detect the generic attacks sent by Nikto.
The Dashboard provides a description of each ModSecurity rule, which you can use to construct and send a malicious request to NGINX Plus to test how the rule behaves.
Currently, the only way to download the Trustwave_SpiderLabs Rules is with the
SecRemoteRules directive. While the directive simplifies the process of getting the rules onto an instance of NGINX_Plus with the ModSecurity_WAF, the following caveats apply:
- Every time you reload the NGINX_Plus configuration or restart NGINX_Plus, the rules are freshly downloaded from a remote server. The
SecRemoteRulesFailActiondirective controls what happens when the download fails, for example when connectivity to the remote server is lost. The directive supports two values:
Abort, which forces the reload or restart of NGINX_Plus to fail, and
Warn, which lets NGINX_Plus reload or restart successfully but with no remote rules enabled. The
SecRemoteRulesFailActiondirective must appear above
SecRemoteRulesdirectives in a ModSecurity configuration file.
- Downloading the rules takes some time, which delays the reload or restart operation.
SecRemoteRulesdefinition leads to a separate download, further increasing the reload/restart time. To avoid that, try to minimize the number of
SecRemoteRulesdefinitions. Note that even if you define SecRemoteRules only in one file (as in the /etc/nginx/modsec/main.conf file modified in Step_3 above), each time you include this file into NGINX_Plus configuration using the
modsecurity_rules_filedirective (as in the /etc/nginx/conf.d/proxy.conf file created in Configuring NGINX), ModSecurity treats it as a separate definition.
- Merging rules from different contexts (
location) also adds time to the reload/restart operation and consumes a lot of CPU, especially for a huge rule set such as the Trustwave_SpiderLabs Rules. In addition to minimizing the number of
SecRemoteRulesdefinitions, try to include all rule definitions in a single context.
The Trustwave_SpiderLabs rule set contains more than 16,000_rules for protecting various applications. The more rules there are, the worse the WAF performs, so it is crucial that you enable only rules that are relevant for your application.
Inspecting the response body is not supported, so rules that do so have no effect.
We configured ModSecurity Rules from Trustwave SpiderLabs to protect our application against WordPress‑related attacks. We also reviewed caveats for the
For information about using the OWASP CRS with the ModSecurity WAF, see Using the OWASP CRS with the NGINX Plus with ModSecurity WAF.