NGINX.COM
Web Server Load Balancing with NGINX Plus

[Editor – The NGINX ModSecurity WAF module for NGINX Plus officially went End-of-Sale as of April 1, 2022 and is transitioning to End-of-Life effective March 31, 2024. For more details, see F5 NGINX ModSecurity WAF Is Transitioning to End-of-Life on our blog.]

…even when you understand web security, it is difficult to produce secure code, especially when working under the pressure so common in today’s software development projects.
– Ivan Ristić, creator of ModSecurity

More than ever before, organizations need all the help they can get with web application security. According to the Q4 2016 State of the Internet / Security Report from Akamai, there were 350 million attacks against web application attacks in that quarter alone. Successful attacks are disruptive to business, causing outages, loss of sensitive data, and system takeover by attackers. Successful attacks can also cascade, causing outages and disruptions to customers who depend on applications that have been attacked.

NGINX ModSecurity WAF

A web application firewall (WAF) is a widely used solution for improving web application security. We’re pleased to announce general availability of NGINX ModSecurity WAF for production use as a top‑quality, NGINX‑supported WAF. It detects and stops a broad range of attacks – such as SQL injection (SQLi), local file inclusion (LFI), and cross‑site scripting (XSS) – from reaching your applications. SQLi, LFI, and XSS together accounted for 95% of known web application attacks in Q4 2016, according to Akamai.

The ModSecurity web application firewall for NGINX Plus plugs in to improve web application security by mitigating DDoS attacks and other security threats
The NGINX ModSecurity WAF module plugs into NGINX Plus to help protect applications from security threats

ModSecurity, like NGINX Open Source, is available as open source software. Initially released in 2002, it is now used used by more than one million websites globally, including some of the world’s busiest e-commerce and financial applications. It is one of the most well‑known, battle‑tested, and trusted names in web application security.

The NGINX ModSecurity WAF module for NGINX Plus is based on a major rewrite of the legacy, Apache‑based 2.9 release. This new architecture, version 3.0, moves the core functionality into a stand‑alone engine (libmodsecurity), and interfaces with NGINX Plus through an optimized connector. It’s considerably faster and more stable than the legacy module has been with NGINX Open Source, and is actively supported by the NGINX, Inc. and Trustwave teams.

NGINX ModSecurity WAF is available to NGINX Plus customers as a dynamic module at an additional cost. To purchase or start a free trial of NGINX Plus with NGINX ModSecurity WAF, or to add NGINX ModSecurity WAF to an existing NGINX Plus subscription, contact the NGINX sales team.

How ModSecurity Works

As a web application firewall, ModSecurity is specialized to focus on HTTP traffic. When an HTTP request is made, ModSecurity inspects all parts of the request for any malicious content or anomalies in the traffic. If the packet is deemed malicious it can be blocked, logged, or both, depending on configuration.

ModSecurity uses a database of “rules” that define malicious behaviors. NGINX ModSecurity WAF supports the OWASP ModSecurity Core Rule Set (CRS), the most widely used rule set for ModSecurity. The OWASP CRS is community‑maintained and has been been tuned through wide exposure to have very few false positives.

SQL injection is one of the most common exploits, accounting for over 51% of known web application attacks in the Akamai report. This type of attack exploits improper validation of user input fields, such as forms. As a simple example, consider an attacker entering the following into a login form (the password field is unmasked for clarity):

Login screen showing an SQL injection attack. The NGINX ModSecurity WAF module for NGINX Plus provides protection against this type of attack as well as DDoS protection, for better web application security.
SQL injection attack to bypass password verification

If a web application uses the information entered on the form directly to form a SQL query for retrieving user information from a database, without first validating the password, it generates an SQL statement like this:

SELECT * FROM Users WHERE Username='someone_else' AND Password='1' OR '1' = '1';

Because the statement '1' = '1' is always true, this query bypasses the password check and allows the attacker to log in as someone_else (or any other account).

The CRS SQL injection rules in the OWASP CRS test input parameters and cookies for all requests against this and other patterns that attackers use to insert malicious SQL queries into forms. If a request matches any of the SQL injection rules, ModSecurity can drop the packet and/or log it, as configured.

There are similar rules in the CRS to detect and stop other common attacks, such as XSS and LFI.

What Other Protections Does ModSecurity Provide?

Blocking Scanners and Bots

Most attackers run vulnerability scanners, such as Nikto, to identify vulnerabilities in their targets. Once they learn what vulnerabilities are present, they can launch the appropriate attacks. Most scanners put identifiable data into the User-Agent HTTP header, as well as into other HTTP headers. The CRS Scanner Detection rules recognize the identifiers for a multiple of scanners and so can block requests from them. Deprived of data from the scanners, attackers are significantly hampered because they don’t know where or what to attack.

In addition, the CRS Scanner Detection rule set can detect various crawlers, SEO tools, and bots that have been reported as potentially malicious.

Rejecting Requests from Denylisted Addresses

There are third‑party reputation sites, such as Project Honeypot, that publish lists of known bad IP addresses. With ModSecurity you can query this database for each unique IP address and automatically block known bad actors. Responses are cached to minimize latency.

To query a particular IP address at Project Honeypot, you submit a DNS query with three elements: your access key (provided by Project Honeypot when you register), the IP address with the octets in reverse order, and the dnsbl.httpbl.org domain name. For example, to get information about 10.2.3.4, you submit this query:

access-key.4.3.2.10.dnsbl.httpbl.org

Project Honeypot responds with a DNS A record in which each octet in the IP address encodes Project Honeypot’s assessment of the submitted IP address:

  • Octet 1 – Always 127
  • Octet 2 – Number of days since there was activity for the address on the Project Honeypot network, so you can assess the “freshness” of the information
  • Octet 3 – Threat score, with a larger value meaning greater threat
  • Octet 4 – Bitset indicating one or more categories to which the address belongs (search engine, harvester, and so on)

So, for example, 127.3.50.2 means the last activity was three days ago, the threat score is 50, and the address represents a harvester.

NGINX ModSecurity WAF understands the meaning of the codes, and you can configure rules to act on them (for example, blocking addresses with threat scores higher than 5).

Mitigating DDoS Attacks

There are many types of DDoS attacks. Some are purely volumetric, meant to deny access to your web applications by saturating available bandwidth. In many cases, a firewall is not enough to stop volumetric attacks. If your NGINX instance has a 10 Gb network card, ModSecurity cannot mitigate an attack of more than 10 Gbps, not accounting for the legitimate traffic your traffic is handling. To mitigate volumetric DDoS attacks, you need to add rules further downstream, for example at your router or ISP, or use an external proxy such as a CDN or other cloud‑based DDoS protection service.

NGINX ModSecurity WAF can protect you from application‑level DDoS attacks, which exploit requests that cause a lot of work to be done on the backend, such as requests that make multiple database queries or cause scripts to run. Attackers can exploit these vulnerabilities by repeatedly making such requests to keep application servers busy and unable to process real user requests. This type of DDoS attack appeals to attackers because it doesn’t require as many resources as a volumetric attack.

Full Support

The NGINX ModSecurity WAF module is fully supported 24/7 by NGINX, Inc., so there’s just one number to call if something goes wrong. Support includes installation, configuration, and troubleshooting of both the NGINX ModSecurity WAF module and the OWASP CRS. You can deploy custom rules of your own, but they are not supported.

Learn More

For more information about NGINX ModSecurity WAF, see our documentation:

Try NGINX ModSecurity WAF for Free Today

To start a free trial of NGINX Plus with NGINX ModSecurity WAF, contact the NGINX sales team.

[NGINX ModSecurity WAF officially went End-of-Sale as of April 1, 2022 and is transitioning to End-of-Life effective March 31, 2024. For more details, see F5 NGINX ModSecurity WAF Is Transitioning to End-of-Life on our blog.]

Hero image
Are Your Applications Secure?

Learn how to protect your apps with NGINX and NGINX Plus



About The Author

Owen Garrett

Sr. Director, Product Management

Owen is a senior member of the NGINX Product Management team, covering open source and commercial NGINX products. He holds a particular responsibility for microservices and Kubernetes‑centric solutions. He’s constantly amazed by the ingenuity of NGINX users and still learns of new ways to use NGINX with every discussion.

About F5 NGINX

F5, Inc. is the company behind NGINX, the popular open source project. We offer a suite of technologies for developing and delivering modern applications. Together with F5, our combined solution bridges the gap between NetOps and DevOps, with multi-cloud application services that span from code to customer.

Learn more at nginx.com or join the conversation by following @nginx on Twitter.