Announcing General Availability of the NGINX Plus with ModSecurity WAF

KENNETH

8년 ago

quote-para {
color: #009639;
font-size: 25px;
line-height: 35px;
font-family: Aktiv Grotesk W01;
font-style: italic;
margin:0;
padding-top:50px;
}

“…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 Plus with 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 the NGINX Plus with 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 WAF module plugs into NGINX Plus to help protect applications from security threats

ModSecurity, like NGINX, 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 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 open source NGINX, and is actively supported by the NGINX, Inc. and Trustwave teams.

The 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 ModSecurity WAF, or add the 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 blocked, logged, or both, depending on configuration.

ModSecurity uses a database of “rules” that define malicious behaviors. The NGINX Plus with 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):

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

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

The 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 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 ModSecurity WAF module and the OWASP CRS. You can deploy custom rules of your own, but they are not supported.