ModSecurity and NGINX: Tuning the OWASP Core Rule Set

ModSecurity and NGINX:
Tuning the OWASP Core
Rule Set

Faisal Memon
Product Marketing Manager, NGINX
Formerly:
• Sr. Technical Marketing Engineer,
Riverbed
• Technical Marketing Engineer, Cisco
• Software Engineer, Cisco
Who am I?

Previously on…
ModSecurity 3.0 and NGINX: Getting
Started
• How to install ModSecurity 3.0 with NGINX Plus
• How to compile and install ModSecurity 3.0 with NGINX Open
Source
• How to validate installation with a basic test rule
• Watch on demand:
nginx.com/webinars/modsecurity-3-0-
and-nginx-getting-started/
3

Agenda
• ModSecurity Overview
• OWASP Core Rule Set Overview
• OWASP Core Rule Set Installation
• OWASP Core Rule Set Tuning
• Demo
• Summary

Brief History of ModSecurity
● 2002: First open source release
● 2004: Commercialized as Thinking Stone
● 2006: Thinking Stone acquired by Breach Security
● 2006: ModSecurity 2.0 released
● 2009: Ivan Ristic, original author, leaves Breach
Security
● 2010: Breach Security acquired by TrustWave
● 2017: ModSecurity 3.0 released
“... I realized that producing secure web applications is virtually impossible. As a result, I
started to fantasize about a tool that would sit in front of web applications and control the
flow of data in and out.”
- Ivan Ristic, ModSecurity creator

What is ModSecurity?
• Layer 7 web application firewall (WAF)
• Dynamic module for NGINX
• Inspects all incoming requests for malicious patterns
• Requests that have malicious patterns are logged
and/or dropped
• ModSecurity is the WAF engine, the Core Rule Set
(CRS) defines the malicious patterns
6

ModSecurity 3.0 and NGINX Interface
• ModSecurity 3.0 is a complete rewrite of
ModSecurity that works natively with NGINX
• Core ModSecurity functionality moved to
standalone libModSecurity functionality
• NGINX Connector interfaces between
libModSecurity and NGINX
• Connector also available for Apache
7

“ModSecurity is not a high-
flying, cloud-enabled, machine-
learning mastermind. It is better
to think of ModSecurity as of a
mechanical watch.
- Christian Folini, co-lead OWASP CRS

ModSecurity 3.0 Caveats
• Rules that inspect the response body are not supported and are ignored if included in the configuration The NGINX sub_filter
directive can be used to inspect and rewrite response data In the OWASP Core Rule Set, these are the 95x rules.
• The OWASP Core Rule Set DDoS mitigation rules (REQUEST-912-DOS- PROTECTION.conf) are not supported. Use NGINX rate limiting instead.
• Inclusion of the request and response body in the audit log is not supported.
• Some directives are not implemented; you may get an error if you try to use them. The ModSecurity Reference Manual lists all the available
directives in ModSecurity and whether or not they are supported in libModSecurity.
9

OSS and NGINX Plus Options
ModSecurity OSS NGINX WAF
Obtaining the
module
Build from source, test and deploy Fully-tested builds direct from
NGINX
Updates Track GitHub, build and deploy
updates as necessary
NGINX tracks GitHub and pushes
out necessary updates
Support Community (GitHub,
StackOverflow)
Additional commercial support
from Trustwave
Commercial support from NGINX
and Trustwave
Financial Cost $0, self-supported Per-instance, NGINX supported

CRS Overview
• First released in 2006 by Ofer Shezaf
• Version 3.0 released in November 2016
◦ Over 90% reduction in false positives
◦ Recommended for use with NGINX
• Community-maintained by a team of 10 developers, co-led by Dr. Christian
Folini
• Blocks SQLi, RCE, LFI, RFI, etc.
• Should be used for all ModSecurity deployments
• Available at: github.com/SpiderLabs/owasp-
modsecurity-crs
12

CRS Key Files and Directories
• crs-setup.conf – The main configuration file for the CRS
• rules/ – Directory containing the rules organized into different files, each of which
has a number assigned to it:
◦ 90x files – Exclusions to remedy false positives
◦ 91x files – Rules to detect malicious clients, such as scanners and bots
◦ 92x files – Rules to detect protocol violations
◦ 93x and 94x files – Rules to detect application attacks such as SQLi and RCE
◦ 95x files – Rules to detect outbound data leakage. Not supported by NGINX or
NGINX Plus
◦ .data files – Data used by the rules. For example crawlers-user-
agents.data contains a list of User-Agent values used by
scanners. This file is used by rule REQUEST-913-SCANNER-
DETECTION.conf to identify scanners and bots.
13
REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf
REQUEST-901-INITIALIZATION.conf
REQUEST-903.9001-DRUPAL-EXCLUSION-RULES.conf
REQUEST-903.9002-WORDPRESS-EXCLUSION-RULES.conf
REQUEST-905-COMMON-EXCEPTIONS.conf
REQUEST-910-IP-REPUTATION.conf
REQUEST-911-METHOD-ENFORCEMENT.conf
REQUEST-912-DOS-PROTECTION.conf
REQUEST-913-SCANNER-DETECTION.conf
REQUEST-920-PROTOCOL-ENFORCEMENT.conf
REQUEST-921-PROTOCOL-ATTACK.conf
REQUEST-930-APPLICATION-ATTACK-LFI.conf
REQUEST-931-APPLICATION-ATTACK-RFI.conf
REQUEST-932-APPLICATION-ATTACK-RCE.conf
REQUEST-933-APPLICATION-ATTACK-PHP.conf
REQUEST-941-APPLICATION-ATTACK-XSS.conf
REQUEST-942-APPLICATION-ATTACK-SQLI.conf
REQUEST-943-APPLICATION-ATTACK-SESSION-FIXATION.conf
REQUEST-949-BLOCKING-EVALUATION.conf
RESPONSE-950-DATA-LEAKAGES.conf
RESPONSE-951-DATA-LEAKAGES-SQL.conf
RESPONSE-952-DATA-LEAKAGES-JAVA.conf
RESPONSE-953-DATA-LEAKAGES-PHP.conf
RESPONSE-954-DATA-LEAKAGES-IIS.conf
RESPONSE-959-BLOCKING-EVALUATION.conf
RESPONSE-980-CORRELATION.conf
RESPONSE-999-EXCLUSION-RULES-AFTER-CRS.conf

CRS Anomaly Scoring
• Configurable anomaly-scoring model
• Each rule that fires increases the anomaly score
• If score exceeds configured anomaly threshold then transaction is blocked
• The anomaly levels are as follows:
◦ Critical – Anomaly score of 5. Likely application attack. Mostly generated by 93x and 94x files
◦ Error – Anomaly score of 4. Likely data leakage. Generated mostly by 95x files. 95x files are not supported with NGINX or NGINX Plus
◦ Warning – Anomaly score of 3. Likely malicious client. Generated mostly by 91x files
◦ Notice – Anomaly score of 2. Likely protocol violations. Generated mostly by 92x files
• Default anomaly threshold is 5.
14

CRS Paranoia Modes
• The CRS has different paranoia levels that enable more rules
• More attacks blocked at higher paranoia levels but also more false positives
• Higher paranoia levels will require application modifications
• Paranoia levels:
◦ Paranoia Level 1 (default) – Basic security. Minimal amount of False Positives
◦ Paranoia Level 2 – Elevated security level. More rules, fair amount of false positives
◦ Paranoia Level 3 – Online banking level security. Specialized rules, more false positives
◦ Paranoia Level 4 - Nuclear power plant level security. Insane rules, lots of false positives
15

Download and Install from GitHub
$ wget https://github.com/SpiderLabs/owasp-modsecurity-crs/archive/v3.0.2.tar.gz
$ tar -xzvf v3.0.2.tar.gz
$ sudo mv owasp-modsecurity-crs-3.0.2 /usr/local
$ cd /usr/local/owasp-modsecurity-crs-3.0.2
$ sudo cp crs-setup.conf.example crs-setup.conf
18
• Can use /usr/local/ as above or another location of your choice
• Version 3.1.0 of the CRS is currently in RC1

Modify Configuration
# Include the recommended configuration
Include /etc/nginx/modsec/modsecurity.conf
# OWASP CRS v3 rules
Include /usr/local/owasp-modsecurity-crs-3.0.2/crs-setup.conf
Include /usr/local/owasp-modsecurity-crs-3.0.2/rules/REQUEST-900-EXCLUSION-RULES-BEFORE-
CRS.conf
Include /usr/local/owasp-modsecurity-crs-3.0.2/rules/REQUEST-901-INITIALIZATION.conf
Include /usr/local/owasp-modsecurity-crs-3.0.2/rules/REQUEST-905-COMMON-EXCEPTIONS.conf
Include /usr/local/owasp-modsecurity-crs-3.0.2/rules/REQUEST-910-IP-REPUTATION.conf
Include /usr/local/owasp-modsecurity-crs-3.0.2/rules/REQUEST-911-METHOD-ENFORCEMENT.conf
...
19
Add the bolded text to existing /etc/nginx/modsec/main.conf:

Verify Installation
$ curl http://localhost/?exec=/bin/bash
<html>
<head><title>403 Forbidden</title></head>
<body bgcolor="white">
<center><h1>403 Forbidden</h1></center>
<hr><center>nginx/1.15.3</center>
</body>
</html>
20
• Will be detected by CRS as RCE attack
• Can try other attacks such as SQL Injection, XSS, etc.

Tuning for False Positives
• Run ModSecurity in blocking mode (SecRuleEngine On).
◦ If you watched previous webinar or have been following instructions on our website then this is already the case.
• Ensure audit log is enabled (default behavior)
• Set a high anomaly threshold, > 1000. Uncomment below rule in crs-setup.conf and adjust threshold:
22
SecAction "id:900110,
phase:1,
nolog,
pass,
t:none,
setvar:tx.inbound_anomaly_score_threshold=1000,
setvar:tx.outbound_anomaly_score_threshold=1000"

Tuning for False Positives
• Monitor audit log for false positives
• For any false positives, either modify application to remove strings triggering false positives or remove offending rule:
23
SecRemoveRuleByID rule-id
• Progressively lower anomaly threshold, to ideally back to the default of 5.

Performance Tuning
• Disable audit log - Great for visibility, bad for performance. Change value of SecAuditEngine in
/etc/nginx/modsec/modsecurity.conf:
24
2017/12/19 14:40:58 [warn] 1205#1205: *12 [client 127.0.0.1] ModSecurity:
Access denied with code 403 (phase 1). Matched "Operator 'Contains' with
parameter 'test' against variable 'ARGS:testparam' (Value: 'thisisatest' )
[file "/etc/nginx/modsec/ main.conf"] [line "202"] [id "1234"] [rev ""] [msg
""] [data ""] [severity "0"] [ver ""] [maturity "0"] [accuracy "0"]
[hostname "127.0.0.1"] [uri "/foo"] [unique_id "151369445814.452751"] [ref
"o7,4v19,11"], client: 127.0.0.1, server: , request: "GET /
foo?testparam=thisisatest HTTP/1.1", host: "localhost"
SecAuditEngine off
• NGINX error log contains information on blocked requests:

Performance Tuning
• Requests for static files don’t need to be inspected by ModSecurity. Use NGINX location blocks to separate out requests for static and
dynamic content:
25
server {
listen 80;
location / {
modsecurity on;
modsecurity_rules_file /etc/nginx/modsec/main.conf;
proxy_pass http://localhost:8085;
proxy_set_header Host $host;
}
location ~ .(gif|jpg|png|jpeg|svg)$ {
root /data/images;
}
}

Summary
• The OWASP Core Rule Set (CRS) is the standard rule set to be used with ModSecurity
• Open source and community-maintained
• Protects against many vulnerabilities: SQLi, RCE, RFI, etc.
• Designed for low-rate of false positives by default
• To tune, set a high anomaly threshold and progressively lower it
• Disabling audit log and not inspected static content will improve performance

Download our Free Ebook
29
• How ModSecurity 3.0 integrates with NGINX
• Installing ModSecurity with NGINX Plus
• Compiling and installing ModSecurity with NGINX Open Source
• Installing the Core Rule Set
• Installing Trustwave Commercial Rules
• Integrating with Project HoneyPot for IP reputation
• Tuning to minimize false positives
• Performance Tuning
Download now:
https://www.nginx.com/resources/library/mo
dsecurity-3-nginx-quick-start-guide/

ModSecurity and NGINX: Tuning the OWASP Core Rule Set

Q & ATry NGINX Plus and NGINX WAF free for 30 days: nginx.com/free-trial-request

ModSecurity and NGINX: Tuning the OWASP Core Rule Set

Recommended

More Related Content

What's hot (20)

Similar to ModSecurity and NGINX: Tuning the OWASP Core Rule Set (20)

More from NGINX, Inc. (20)

Recently uploaded (20)

ModSecurity and NGINX: Tuning the OWASP Core Rule Set

Editor's Notes