modsecurity 3.0 and nginx: getting started

NGINX and

ModSecurity 3.0:

Getting Started

Faisal Memon, NGINX

November 27, 2017

Who Am I?

Faisal Memon

Product Marketer

Formerly:• Sr. Technical Marketing Engineer,

Riverbed

• Technical Marketing Engineer, Cisco

• Software Engineer, Cisco

Agenda

1. The current security landscape

2. ModSecurity overview

3. How to install with NGINX open source

4. How to install with NGINX Plus

5. Basic configuration and validation

Akamai State of the Internet, Security report

In the last 12 months…

Web Application attacks are increasing:

… whereas DDoS attacks levels are flat:

Source: Q3 2017 Akamai State of the Internet Security report

69% total increase in web application attacks

3% decrease in total DDoS attacks

2% decrease in infrastructure layer attacks

2% decrease in reflection-based attacks

Akamai State of the Internet, Security report

Recent trends (Q2 to Q3 2017)

What attackers are after

1. High-value personal data

• Credit card numbers

• Passwords

• Email, address, phone numbers,

any identity information

2. Ransom and Extortion

• Steal, pay not to release

• Encrypt, pay to decrypt

3. Botnets and CryptoCurrency mining

4. Political change

8 months in 2017

March 2017

• Wonga, UK: 0.25m customer details

• Chipolte: Payment card data

• Gamestop: 5 months of payment data

• HipChat: Cloud Web Tier compromised

• AA: 2m customer details

April 2017

• Deloitte: Client details, inc. passwords

• ABTA: 43,000 customer details

• Cellebrite: 900Gb data, inc users and passwords

• Debenhams Flowers: 26,000 customer payment details

May 2017:

• Edmodo: 78m customer details

• Bell: 1.9m customer details

• Guardian Soulmates: Unspecified customer details

• OneLogin: Unspecified database tables

June 2017:

• Deep Root Analytics: 2m US voter details

July 2017

• Equifax: 143m account details

• Bithumb: 32,000 users compromised

• HBO: 1.5Tb data, GoT scripts, 1,000’s docs

• Parity: $32m ethereum

August 2017

• Cex: 2m customer details

September 2017

• Sonic Drive-In: 5m customer payment details

October 2017

• Yahoo: All 3bn accounts

• PizzaHut: 60,000 customer payment details

Enterprises need a multi-faceted approach

Web App Firewall:

• SQLi, XSS, Misuse,

Brute-Force Login

Network-Level

attack

Behavior

attack

Web. App-level

attack

Network Firewall:

• Whitelist traffic

• Protocol Attacks

IPS:

• Traffic Anomalies

• Signatures

Cloud DDoS:

• Large-Volume

network floods

Layer 2-4

Layer 4

Layer 7

Example: Apache Struts (CVE-2017-5638)

• Bug in a widely-deployed Java Application Framework

• Not an operating-system library, so challenging to replace

• https://nvd.nist.gov/vuln/detail/CVE-2017-5638:

Incorrect exception handling … allows remote attackers to

execute arbitrary commands via a crafted Content-Type,

Content-Disposition, or Content-Length HTTP header,

as exploited in the wild in March 2017 with a Content-Type

header containing a #cmd= string. ”

• Within hours, scanning and attack tools were updated with

signatures to identify vulnerable web applications

“

Example: Apache Struts (CVE-2017-5638)

• Check vulnerability announcement, determine nature of issue:

• “a Content-Type header containing a #cmd= string”

• Construct and deploy Web App Firewall rule to block this traffic,

monitor for false positives:

• Investigate vulnerability further; determine that other headers

(Content-Disposition, Content-Length) and other exploits (#cmds=)

are possible. Extend Web App Firewall rule as necessary

• Finally, patch applications, verify, decommission WAF rule

SecRule REQUEST_HEADERS:Content-Type "@contains #cmd="

"id:5638,auditlog,log,deny,status:403"

Agenda






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

How ModSecurity works

• Dynamic module for NGINX

• Sits in front of application servers

• Inspects all incoming traffic

• Matches traffic against database of

rules searching for malicious

patterns

• Traffic that violates rules are

dropped and/or logged

What you get with ModSecurity

• Layer 7 attack protection– SQLi, LFI, RFI, RCE, XSS,CSRF, and

more

• Project Honeypot IP reputation

• Standard PCRE regex rules

language

• Virtual patching

• Audit logs

• PCI-DSS 6.6 compliance

What’s new in ModSecurity 3.0

• Redesigned to work natively with NGINX

• Core functionality split off into libmodsecurity

• A special NGINX connector integrates libmodsecurity with

NGINX

-- Connector available for Apache

• Previous ModSecurity 2.9 technically worked with NGINX

but had poor performance and reliability

ModSecurity 3.0 Caveats

• Not yet at full feature parity with ModSecurity 2.9

• DDoS mitigation rules not supported; use NGINX native

functionality

• Rules that inspect application responses are not supported

• Other miscellaneous directives are yet to be implemented,

or will not be carried forward from 2.9

• OWASP CRS and Trustwave Commercial Rules are

supported with the above caveats

Agenda






Install ModSecurity with NGINX open source

1. Install build tools and

prerequisites

2. Clone and build

libmodsecurity

3. Clone and build

NGINX connector and

NGINX module

1 Prerequisites

1. Install NGINX 1.11.5 or later from our official repository• See: nginx.org/en/linux_packages.html#mainline

2. Install prerequisite packages

apt-get install -y apt-utils autoconf automake build-essential git libcurl4-openssl-dev libgeoip-dev liblmdb-devibpcre++-dev libtool libxml2-dev libyajl-dev pkgconf wgetzlib1g-dev

2. Download and compile libmodsecurity

1. Clone the GitHub repository

2. Compile the source code

$ cd ModSecurity$ git submodule init$ git submodule update$ ./build.sh$ ./configure$ make$ make install

$ git clone --depth 1 -b v3/master --single-branch https://github.com/SpiderLabs/ModSecurity

3. Download and compile NGINX connector

1. Clone the GitHub repository

2. Determine NGINX version

$ nginx -vnginx version: nginx/1.13.7

$ git clone --depth 1 https://github.com/SpiderLabs/ModSecurity-nginx.git

3. Download and compile NGINX connector

3. Download corresponding NGINX source code

4. Compile the dynamic module and copy it to NGINX directory

$ cd nginx-1.13.7$ ./configure --with-compat --add-dynamic-module=../ModSecurity-nginx$ make modules$ cp objs/ngx_http_modsecurity_module.so /etc/nginx/modules

$ wget http://nginx.org/download/nginx-1.13.7.tar.gz$ tar zxvf nginx-1.13.7.tar.gz

Agenda






Install NGINX WAF

1. Install directly from

NGINX repository

Install ModSecurity dynamic module

1. Upgrade subscription to include NGINX WAF

2. Install NGINX Plus’ ModSecurity WAF module

Debian/Ubuntu:

$ apt-get install nginx-plus-module-modsecurity

RedHat/CentOS:

$ yum install nginx-plus-module-modsecurity

Agenda






1. Load the dynamic module

1. Add the load_module directive in the main (top-level) context in /etc/nginx/nginx.conf

user nginx;worker_processes auto;

load_module "modules/ngx_http_modsecurity_module.so";

error_log /var/log/nginx/error.log notice;pid /var/run/nginx.pid;

2. Configure ModSecurity

1. Download recommended ModSecurity configuration

1. Change from “detection only” mode to actively dropping traffic

$ mkdir /etc/nginx/modsec$ wget -P /etc/nginx/modsec/ https://raw.githubusercontent.com/SpiderLabs/ModSecurity/master/modsecurity.conf-recommended$ mv /etc/nginx/modsec/modsecurity.conf-recommended /etc/nginx/modsec/modsecurity.conf

$ sed -i 's/SecRuleEngine DetectionOnly/SecRuleEngine On/' /etc/nginx/modsec/modsecurity.conf

3. Create test rule

1. Put the following text in /etc/nginx/modsec/main.conf

# From https://github.com/SpiderLabs/ModSecurity/blob/master/\# modsecurity.conf-recommended## Edit to set SecRuleEngine OnInclude "/etc/nginx/modsec/modsecurity.conf"

# Basic test ruleSecRule ARGS:testparam "@contains test" "id:1234,deny,status:403"

4. Final NGINX configuration

1. Enable ModSecurity in NGINX configuration

2. Reload for changes to take effect

server {# ...modsecurity on;modsecurity_rules_file /etc/nginx/modsec/main.conf;

}

$ nginx -t && nginx –s reload

5. Test it out

1. Issue the following curl command, look for the 403

$ curl localhost?testparam=test<html><head><title>403 Forbidden</title></head><body bgcolor="white"><center><h1>403 Forbidden</h1></center><hr><center>nginx/1.13.1</center></body></html>

Enable Audit and Debug Logging

1. HOWTO: See NGINX

Admin Guide

2. Deep Dive: see

https://www.nginx.com/

blog/modsecurity-

logging-and-

debugging/

Deploy the OWASP Core Ruleset (CRS)

See NGINX Admin Guide

1. Clone from GitHub and

Include rules

2. Test in detection-only

mode first, and

investigate false-

positives:

SecRemoveRuleById

Comparing 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

Summary

• The number of web application attacks is rising year over year

• The cost of a security breach can be devastating to the business

• Protecting web applications requires a multi-faceted approach

• A web application firewall protects against layer 7 attacks

• ModSecurity WAF now runs natively with NGINX

• NGINX Plus users get access to a pre-built binary and 24x7 support

Q & ATry NGINX WAF free for 30 days: [email protected]