ModSecurity

The Open Source Web

Application Firewall

Ivan Ristic
Chief Evangelist
Breach Security

1/30
 Introduction
Breach Security

 Global headquarters in
Carlsbad, California
 Web application security
provider for over six
years
 Led by experienced
security executives
 Trusted by large
enterprise customers

• Next-generation web application security solutions for protecting

business-critical applications transmitting privileged information.
• Resolve security challenges such as identity theft, information
leakage, regulatory compliance, and insecurely coded applications.
• Best threat detection in the industry and the most flexible
deployment options available.
2/30
 Introduction
Ivan Ristic

 Web application security and

web application firewall specialist.
 Author of Apache Security.
 Author of ModSecurity.
 OWASP London Chapter leader.
 Officer of the Web Application
Security Consortium.
► WAFEC project leader.

3/30
 Part 1
What are Web Application Firewalls?

4/30
Problems with Web Applications

How did it all start?

 HTTP and browsers designed for document
exchange.
 Web applications built using a number of loosely
integrated technologies.
 No one thought about security at the time.
Where are we today?
 Most web applications suffer from one type of
problem or another. It is very difficult to develop
a reasonably secure web application.
 Not possible to achieve 100% security.
5/30
How Can We Improve the Situation?

Education & good development practices.

 We have been working hard on
this since 2000.
 Much better than it used to be, but still
not good enough.
 Secure web programming too difficult and time consuming
for your average programmer.
Design & code reviews.
 Slow and expensive.
Scanning & penetration testing.
 Not conclusive.
 Slow and expensive.

6/30
Why Use Web Application Firewalls?

It's a cost-effective technology that works.

It can be deployed straight away.
Gives instant visibility of the systems it protects.
Can provide instant protection.
In some of its forms (reverse proxies) it is actually
an essential building block of HTTP
networks.
Good example of defence-in-depth.

7/30
Network Firewalls Do Not Work

Firewall

Application
Web Web Database
Client Server Application
Server

HTTP Traffic Port 80

Neither do IDS/IPS
solutions.

8/30
WAF Identity Problem: Naming

There is a long-standing WAF identity problem.

With the name, first of all:
Adaptive Firewall Web Adaptive Firewall
Adaptive Proxy Web Application Firewall
Adaptive Gateway Web Application Security Device
Application Firewall Web Application Proxy
Application-level Firewall Web Application Shield
Application-layer Firewall Web Shield
Application-level Security Gateway Web Security Firewall
Application Level Gateway Web Security Gateway
Application Security Device Web Security Proxy
Application Security Gateway Web Intrusion Detection System
Stateful Multilayer Inspection Firewall Web Intrusion Prevention System

9/30
WAF Identity Problem: Purpose

There are four aspects to consider:

1. Audit device
2. Access control device
3. Layer 7 router/switch
4. Web Application Hardening tool
The name (WAF) is overloaded. What about:
 Web Intrusion Detection System?
 HTTP Security Monitoring?

10/30
WAFEC

Short for Web Application Firewall

Evaluation Criteria.
Project of the Web Application Security
Consortium (webappsec.org).
It's an open project.
Virtually all WAF vendors on board
(not enough users though).
WAFEC v1.0 released last year.
 New versions coming soon.
11/30
 Part 2
ModSecurity

12/30
 What is ModSecurity?

It is an open source web application firewall.

 Most widely deployed web application
firewall according to Forrester Research.
That’s not surprising because it is:
 Readily available.
 Full-featured.
 Stable and reliable.
 Well documented.
 Does what it says on the box.

13/30
 History of ModSecurity

 Project started in 2002:

 “Wouldn’t it be nice if I had something to
monitor what’s going on in my applications?”

 Commercial support through Thinking Stone

since 2004.
 Acquired by Breach Security in 2006.
 Breach Security pledges to support the open
source nature of the project, adds resources.
 Still going strong.
14/30
 The Open Source Advantage

Four main points:

1. Availability
2. Collaborative development
3. Transparency
4. Education

15/30
 Deployment Architectures

 Embed into your existing web servers.

 Deploy as a network gateway combining
Apache working as reverse proxy with
ModSecurity.

16/30
 Use Cases

1. HTTP intrusion detection and

prevention.
2. Traffic logging.
3. Just-in-time patching.
4. Web application hardening.
► For example, defending against the
PDF UXSS vulnerability.

17/30
 Security Models

1. Negative security
 Easy to get started.
 Trying to detect attacks.
 Can be written by hand.

2. Positive security
1. Must be tailored per application.
2. But it only needs to determine what constitutes
valid data.
3. Virtual patches can be written by hand as they
are simple. Automated learning required
in all other cases.
18/30
 ModSecurity Philosophy

 Make the WAF technology available

to everyone.
 Nothing is done implicitly. You generally need
to know what you’re doing or use the pre-
packaged rule sets.
► Help users help themselves.
► Do not surprise the user.
» Document everything.
» Tell it like it is.
19/30
 ModSecurity Rule Language

 It's a simple event-based programming

language.
► Five processing phases, one for each major
processing step.
► Look at any part of the transaction.
► Transform data to counter evasion.
► Combine rules to form complex logic.

 Common tasks are easy, complex tasks

are possible.
20/30
 Advanced Features

 Persist information across requests.

► You can create small databases of sorts.

 Support for anomaly-based rules.

 Support for sessions and application users.
 Log entire transactions or sessions.
► Sanitise data before logging.

 Intercept file uploads.

 XML support (parse, validate, extract).
21/30
 Rule Examples

Very simple (apply regex to input):

SecRule ARGS attack
SecRule ARGS|!ARGS:p attack

Different operator:
SecRule ARGS "@verifyByteRange 10,13,32-126"

Interesting:
SecRule REMOTE_ADDR "@rbl sc.surbl.org"
22/30
 Real-life Example

Virtual patching example using

the positive security approach:
<Location /apps/script.php>
SecRule &ARGS "!@eq 1"
SecRule ARGS_NAMES "!^statid$"
SecRule ARGS:statID "!^\d{1,3}$"
</Location>
Rules should include meta-
data, such as ID, revision,
human-readable message,
and so on.

23/30
 Status

Stable version: 2.1.4

Next major version: 2.5.0
 Parallel matching. PDF Universal XSS
protection.
 GeoIP-based rules.
Support for efficient and
 Content injection.
secure log centralisation.
 Credit-card number
Full scripting support using
detection.
Lua.
 Automated rule updates.

Support for other web servers in 3.0.0.

24/30
 Part 3
Projects related to ModSecurity

25/30
 ModSecurity Core Rules
Coherent set of rules designed to detect
generic web application security attacks.
 Bundled with ModSecurity, but
with a separate release cycle.
 Lead by Ofer Shezaf.
Design goals:
 Performance. Automated updates
starting with
 Quality. ModSecurity 2.5.
 Stability.
 Plug and Play.
26/30
 ModSecurity Community Console

Self-contained application designed

for alert aggregation, monitoring and
reporting.
 Portable (Java).
 Free for up to 3
sensors.
 Not open source.

27/30
 REMO
A project to build a graphical rule editor for
ModSecurity with a positive / whitelist
approach.
 REMO stands for
Rule Editor for
ModSecurity.
 Community
project run by
Christian Folini.

28/30
 Distributed Open Proxy Honeypots

A network of open proxy sensors, each

deployed with ModSecurity configured to log
to the central server.
Goals:
 Observe what the bad guys are doing.
 Fine tune detection rules.
 WASC project (webappsec.org),
run by Ryan Barnett.

29/30
 Questions?

Thank you!
Ivan Ristic
[email protected]

30/30