ApacheCon – ModSecurity

Presented by Ivan Ristic, a web application firewall expert and author of ModSecurity and Apache Security

The problem: HTTP and browsers are designed for document exchange.  We have web applications built using a number of loosely integrated technologies.  These are created without a lot of thought about security.  Things now are better than ten years ago, but there are also more threats now to defend against.

The solution: (or at least one solution) – a web application firewall.

I apologize in advance – Ivan was moving very fast, and many of the notes are sparse as he was jumping from slide to slide.  I couldn’t keep up.


Part 1 – What are Web Application Firewalls?

Web Application Firewalls are a cost-effective technology that works, and can be deployed easily.  Ivan explains that network firewalls do not work for many kind of attacks. 

Part 2 – ModSecurity

What is it?  It’s an open source web application firewall.  According to some independent researchers, it is the most widely deployed WAF on the internet.  Commerical support has been available through Thinking Stone since 2004 and now Breach Security.  It doesn’t do anything implicitly – it’s goal is to empower the user to do what you need, and to do this, it needs to be configured.  Fortunately, one of the goals of the project is to be very well documented.  There is a separate project called ModSecurity Core Rules.  This provides a general set of rules that can typically be used for any web application.

Two ways that it can be used:

  • Embed it into your existing web servers
  • Deploy it as a network gateway, using Apache proxy – putting it in front of all of your web servers.

There are five phases:

  1. REQUEST HEADERS – run this as early as possible
  2. REQUEST BODY – it inspects the request body before the Apache server gets it and starts processing it.
  3. RESPONSE HEADERS
  4. RESPONSE BODY
  5. LOGGING

With ModSecurity, you can log the entire transaction, or parts of it.  There are two formats: Serial – a single file, convenient but limited.  Concurrent - file per transaction, scalable but not suitable for manual handling.  Then you can use Mlogc which can take what you logged and send it to a central logging server.  There is a free (as in beer – not open source) tool available to analyze logs – ModSecurity Community Console.

ModSecurity Rule Language – it’s a simple, event-based programming language, which lives within the Apache configuration syntax.  With it, you can look at any part of the transaction, can trasnform it as needed, and you can combine rules to form complex logic.  This means that common tasks are easy, and complex tasks are possible.

Basic syntax: SecRule TARGETS OPERATOR [ACTIONS]

Example: SecRule ARGS|REQUEST_HEADERS “<script id:1001,msg:’XSS Attack’, severity:ERROR,deny,status:404″

Chaining example (blocks admin to only login from single IP):
SecRule ARGS:username “@streq admin” chain,deny
SecRule REMOTE_ADDR !@streq 192.168.1.1

There are 22 different operators in the latest version that allow things like string operations, numerical comparison, XML validation (i.e. XPath – get piece of XML from request, and inspect it), and other operators like allowing external script to check uploaded files for viruses.

Actions – Ations tell ModSecurity what to do when a match occurs.  There are 42 actions in the latest version, such as blocking a transaction, influencing logging, set / change / delete variables, or storing anomalies in a persistent storage for later review.

Part 3 – Real-life examples

Here’s an example of what Ivan calls “virtual patching“.  The example is that you discover a SQL injection vulnerability in a script, in the input variable statID.  You don’t have someone on staff who can fix it right now, or you are not legally allowed to change the source code.  You can enforce a rule that the variable is only a number, thereby eliminating the SQL injection vulnerability.

<Location /apps/script.php>
   SecRule $ARGS “!@eq 1″
   SecRule ARGS_NAMES “!^statid$”
   SecRule ARGS:statID “!^d{1,3}$”
</Location>

Here’s a common request – the ability to whitelist or blacklist certain IP addresses.

SecRule REMOTE_ADDR “@streq 192.168.254.1″ allow,phase:1,nolog
SecRule REMOTE_ADDR “@beginsWith 192.168.254.” allow,phase:1,nolog

Tracking activity per IP adddress:

First, initialise an IP address collection:
SecAction phase:1,initcol:ip=%{REMOTE_ADDR}mnolog,pass

Then, increment score in rule match:
SecRule ARGS prttern phase:2,pass,setvar:ip.score=+1

Deny IP address whose scores are too high:
SecRule IP:score “@gt 20″ phase:1,log,deny

Other related projects and features:

You can also use Lua scripting language and call Lua scripts from ModSecurity rules.  This functionality is currently experimental.

There is a new tool called ModProfiler that attempts to analyze logged application traffic and tries to identify anomalies and create rules for you.

REMO is a community project to build a graphical rule editor.

Open Proxy Honeypots – a network of open proxy sensors that have the goal of observing what the bad guys are doing and fine tune detection rules.

Be Sociable, Share!

Leave a Reply

Your email address will not be published. Required fields are marked *

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>