On demand recording: https://www.nginx.com/resources/webinars/modsecurity-and-nginx-tuning-the-owasp-core-rule-set-emea/ In this webinar we discuss how to install the OWASP Core Rule Set (CRS) with NGINX and ModSecurity, as well as how to tune it. The CRS protects against many types of attack, including SQL Injection (SQLi), Local File Inclusion (LFI), and Remote Code Execution (RCE). Watch this webinar to learn: - How to install the OWASP Core Rule Set (CRS) with ModSecurity - About the types of attacks the CRS blocks, such SQLi, RFI, and LFI - How to tune the CRS to minimize false positives - What it looks like when ModSecurity blocks an attack (in a live demo), and how to interpret the audit log

1. ModSecurity and NGINX:
Tuning the OWASP Core
Rule Set

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

3. Agenda
• ModSecurity Overview
• OWASP Core Rule Set Overview
• OWASP Core Rule Set Installation
• OWASP Core Rule Set Tuning
• Summary

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

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

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
6

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

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

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

10. Agenda
• ModSecurity Overview
• OWASP Core Rule Set Overview
• OWASP Core Rule Set Installation
• OWASP Core Rule Set Tuning
• Summary

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

12. CRS Key Files and Directories
• crs-setup.conf.example – 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

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

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

15. 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
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).
rules (50 level files).
◦ 4: Warning - Anomaly Score of 3. Is generated by malicious client rules (35 level files).
level files).
◦ 5: Notice - Anomaly Score of 2. Is generated by the Protocol policy and anomaly files.
anomaly files.
• A score is accumulated as rules are run
15

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

17. CRS Paranoia Modes
17
Image copyright: Damiano Esposito, Zurich University of Applied Sciences and Dr. Christian Folini, netnea

18. Agenda
• ModSecurity Overview
• OWASP Core Rule Set Overview
• OWASP Core Rule Set Installation
• OWASP Core Rule Set Tuning
• Summary

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

20. 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
...
20
Add the bolded text to existing /etc/nginx/modsec/main.conf:

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

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

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

24. Agenda
• ModSecurity Overview
• OWASP Core Rule Set Overview
• OWASP Core Rule Set Installation
• OWASP Core Rule Set Tuning
• Summary

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

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

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

28. Using the NGINX mirror module
28
Applications
Internet
Mirror

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

30. 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;
}
}

31. Agenda
• ModSecurity Overview
• OWASP Core Rule Set Overview
• OWASP Core Rule Set Installation
• OWASP Core Rule Set Tuning
• Summary

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

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

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