NGINX Documentation

Using the ModSecurity Rules from Trustwave SpiderLabs with NGINX WAF

This article explains how to configure the ModSecurity Rules from Trustwave SpiderLabs for use with the NGINX WAF.


NGINX Plus Release 12 and later supports the NGINX web application firewall (WAF). The NGINX WAF protects web applications against SQL Injection (SQLi), Remote Code Execution (RCE), Local File Include (LFI), Cross-Site Scripting, and many other attacks.

The ModSecurity Rules from Trustwave SpiderLabs complement the Open Web Application Security Project Core Rule Set (OWASP CRS) with protection against specific attacks 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 WAF, showing how to configure the Trustwave SpiderLabs Rules to protect the demo web application created there.

The NGINX WAF also supports the OWASP CRS as described in Using the OWASP CRS with the NGINX WAF.


The NGINX WAF is available to NGINX Plus customers as a downloaded dynamic module at an additional cost. You can try the NGINX WAF free for 30 days. To purchase or add the NGINX 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 WAF and assumes you have following the instructions there to configure the demo application and NGINX Plus as a reverse proxy.

Configuring the Trustwave SpiderLabs Rules

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 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 NGINX WAF dynamic module downloads them automatically when the SecRemoteRules directive is included in the NGINX WAF 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 NGINX WAF 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 NGINX WAF configuration to make the NGINX WAF 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.

Using the Configuration Wizard

To configure the Trustwave SpiderLabs Rules for the demo application, perform the following steps:

  1. Log in to the ModSecurity Dashboard and start the Configuration Wizard.

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

  3. At the Configure your server step, the Wizard presents the SecRemoteRules directive that must be added to the NGINX WAF configuration, similar to the line below:

    SecRemoteRules license‑key https://url

    Here, the SecRemoteRules directive configures NGINX WAF 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 edit /etc/nginx/modsec/main.conf manually and add the SecRemoteRules directive 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 SecRule directive from that section.

    # Include the recommended configuration
    Include "/etc/nginx/modsec/modsecurity.conf"
    SecRemoteRules license‑key https://url
  4. 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"

    The SecDefaultAction directive defines the default list of actions for the rules, with the deny action blocking malicious requests and returning status code 403.

  5. Reload the NGINX Plus configuration:

    $ sudo nginx -s reload

    Reloading takes time as the rules are being downloaded from the remote server.

  6. Once the Wizard reports that NGINX Plus downloaded the rules, you can close the wizard and start testing the rules.

Testing the Rules

In Using the OWASP CRS with the NGINX 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.

Caveats for the SecRemoteRules Directive

Currently, the only way to download the ModSecurity Rules from Trustwave SpiderLabs is with the SecRemoteRules directive. While the directive simplifies the process of getting the rules onto an instance of NGINX 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 SecRemoteRulesFailAction directive 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 SecRemoteRulesFailAction directive must appear above SecRemoteRules directives in a NGINX WAF configuration file.
  • Downloading the rules takes some time, which delays the reload or restart operation.
  • Each SecRemoteRules definition leads to a separate download, further increasing the reload/restart time. To avoid that, try to minimize the number of SecRemoteRules definitions. 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_file directive (as in the /etc/nginx/conf.d/proxy.conf file created in Configuring NGINX Plus as a Reverse Proxy), NGINX WAF treats it as a separate definition.
  • Merging rules from different contexts (http {}, server {}, 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 SecRemoteRules definitions, try to include all rule definitions in a single context.

The Trustwave SpiderLabs rule set contains more than 16000 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 SecRemoteRules directive.

For information about using the OWASP CRS with the NGINX WAF, see Using the OWASP CRS with the NGINX WAF.