ModSecurity and NGINX: Tuning the OWASP Core Rule Set - EMEA

ModSecurity and NGINX:
Tuning the OWASP Core
Rule Set

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

Agenda
• ModSecurity Overview
• OWASP Core Rule Set Overview
• OWASP Core Rule Set Installation
• OWASP Core Rule Set Tuning
• 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
5

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
6

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

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
• Blacklist rule set
• Should be used for all ModSecurity deployments
• Available at: github.com/SpiderLabs/owasp-
modsecurity-crs
11

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.
12
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 “Traditional” mode
• Traditional Detection Mode (or IDS/IPS mode) is the v2.9 operating
mode.
◦ All of the rules are self-contained; no intelligence is shared between rules and each rule has
no information about any previous rule matches.
◦ If a rule triggers, it will execute any disruptive/logging actions specified on the current rule.
13

CRS Anomaly Scoring
• 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

Anomaly Scores
• These are the default Severity ratings (with anomaly scores)
of the individual rules -
◦ 2: Critical - Anomaly Score of 5. Is the highest severity level possible without
correlation. It is normally generated by the web attack rules (40 level files).
◦ 3: Error - Anomaly Score of 4. Is generated mostly from outbound leakage
rules (50 level files).
◦ 4: Warning - Anomaly Score of 3. Is generated by malicious client rules (35
level files).
◦ 5: Notice - Anomaly Score of 2. Is generated by the Protocol policy and
anomaly files.
• A score is accumulated as rules are run
15

CRS Paranoia Modes
What rules are run?
• 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
16

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
19
• 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/*.conf
20
Add the bolded text to existing /etc/nginx/modsec/main.conf:
Reload NGINX for changes to take effect:
$ nginx -t && nginx –s reload

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>
21
• Will be detected by CRS as RCE attack
• Can try other attacks such as SQL Injection, XSS, etc.

Log Files are verbose
2018/09/25 09:26:46 [info] 4822#4822: *20 ModSecurity: Warning. Matched "Operator `PmFromFile' with parameter `unix-shell.data' against variable `ARGS:exec'
(Value: `/bin/bash' ) [file "/home/owen/src/owasp-modsecurity-crs-3.0.2/rules/REQUEST-932-APPLICATION-ATTACK-RCE.conf"] [line "404"] [id "932160"] [rev "1"]
[msg "Remote Command Execution: Unix Shell Code Found"] [data "Matched Data: bin/bash found within ARGS:exec: /bin/bash"] [severity "2"] [ver
"OWASP_CRS/3.0.0"] [maturity "1"] [accuracy "8"] [tag "application-multi"] [tag "language-shell"] [tag "platform-unix"] [tag "attack-rce"] [tag
"OWASP_CRS/WEB_ATTACK/COMMAND_INJECTION"] [tag "WASCTC/WASC-31"] [tag "OWASP_TOP_10/A1"] [tag "PCI/6.5.2"] [hostname "127.0.0.1"] [uri "/"] [unique_id
"153786400664.890971"] [ref "o1,8v11,9t:urlDecodeUni,t:cmdLine,t:normalizePath,t:lowercase"], client: 127.0.0.1, server: , request: "GET /?exec=/bin/bash
HTTP/1.1", host: "localhost"
2018/09/25 09:26:46 [info] 4822#4822: *20 ModSecurity: Access denied with code %d (phase 2). Matched "Operator `Ge' with parameter `5' against variable
`TX:ANOMALY_SCORE' (Value: `5' ) [file "/home/owen/src/owasp-modsecurity-crs-3.0.2/rules/REQUEST-949-BLOCKING-EVALUATION.conf"] [line "36"] [id "949110"]
[rev ""] [msg "Inbound Anomaly Score Exceeded (Total Score: 5)"] [data ""] [severity "2"] [ver ""] [maturity "0"] [accuracy "0"] [tag "application-multi"]
[tag "language-multi"] [tag "platform-multi"] [tag "attack-generic"] [hostname "127.0.0.1"] [uri "/"] [unique_id "153786400664.890971"] [ref ""], client:
127.0.0.1, server: , request: "GET /?exec=/bin/bash HTTP/1.1", host: "localhost"
2018/09/25 09:26:46 [warn] 4822#4822: *20 [client 127.0.0.1] ModSecurity: Warning. Matched "Operator `Ge' with parameter `5' against variable
`TX:ANOMALY_SCORE' (Value: `5' ) [file "/home/owen/src/owasp-modsecurity-crs-3.0.2/rules/REQUEST-949-BLOCKING-EVALUATION.conf"] [line "36"] [id "949110"]
[rev ""] [msg "Inbound Anomaly Score Exceeded (Total Score: 5)"] [data ""] [severity "2"] [ver ""] [maturity "0"] [accuracy "0"] [hostname "127.0.0.1"] [uri
"/"] [unique_id "153786400664.890971"] [ref ""], client: 127.0.0.1, server: , request: "GET /?exec=/bin/bash HTTP/1.1", host: "localhost"
2018/09/25 09:26:46 [info] 4822#4822: *20 ModSecurity: Warning. Matched "Operator `Ge' with parameter `5' against variable `TX:INBOUND_ANOMALY_SCORE' (Value:
`5' ) [file "/home/owen/src/owasp-modsecurity-crs-3.0.2/rules/RESPONSE-980-CORRELATION.conf"] [line "61"] [id "980130"] [rev ""] [msg "Inbound Anomaly Score
Exceeded (Total Inbound Score: 5 - SQLI=0,XSS=0,RFI=0,LFI=0,RCE=5,PHPI=0,HTTP=0,SESS=0): Remote Command Execution: Unix Shell Code Found"] [data ""]
[severity "0"] [ver ""] [maturity "0"] [accuracy "0"] [tag "event-correlation"] [hostname "127.0.0.1"] [uri "/"] [unique_id "153786400664.890971"] [ref ""]
while logging request, client: 127.0.0.1, server: , request: "GET /?exec=/bin/bash HTTP/1.1", host: "localhost"
22

Log Files are verbose
2018/09/25 09:26:46 [info] 4822#4822: *20 ModSecurity: Warning. Matched
"Operator `PmFromFile' with parameter `unix-shell.data' against variable
`ARGS:exec' (Value: `/bin/bash' ) [file "/home/owen/src/owasp-modsecurity-crs-
3.0.2/rules/REQUEST-932-APPLICATION-ATTACK-RCE.conf"] [line "404"] [id
"932160"] [rev "1"] [msg "Remote Command Execution: Unix Shell Code Found"]
[data "Matched Data: bin/bash found within ARGS:exec: /bin/bash"] [severity
"2"] [ver "OWASP_CRS/3.0.0"] [maturity "1"] [accuracy "8"] [tag "application-
multi"] [tag "language-shell"] [tag "platform-unix"] [tag "attack-rce"] [tag
"OWASP_CRS/WEB_ATTACK/COMMAND_INJECTION"] [tag "WASCTC/WASC-31"] [tag
"OWASP_TOP_10/A1"] [tag "PCI/6.5.2"] [hostname "127.0.0.1"] [uri "/"]
[unique_id "153786400664.890971"] [ref
"o1,8v11,9t:urlDecodeUni,t:cmdLine,t:normalizePath,t:lowercase"], client:
127.0.0.1, server: , request: "GET /?exec=/bin/bash HTTP/1.1", host:
"localhost"
23

Why do you need to tune ModSecurity?
• To reduce the rate of false positives
• To improve performance
25

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:
26
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:
27
SecRemoveRuleByID rule-id
• more sophisticated alternatives: edit rules (remotely) to remove
arguments, disable rule for URI, disable argument for URI
• Progressively lower anomaly threshold, to ideally back to the default of 5.

Using the NGINX mirror module
28
Applications
Internet
Mirror

Performance Tuning
• Disable audit log - Great for visibility, bad for performance. Change value of SecAuditEngine in
/etc/nginx/modsec/modsecurity.conf:
29
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:
30
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 inspecting static content will improve
performance

Download our Free Ebook
33
• 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 Honey 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 - EMEA

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 - EMEA

Recommended

More Related Content

What's hot (20)

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

More from NGINX, Inc. (20)

Recently uploaded (20)

ModSecurity and NGINX: Tuning the OWASP Core Rule Set - EMEA