15 December, 2013

MIRcon 2013 - Analyzing Web Attacks with ModSecurity

MIRcon 2013 - Analyzing Web Attacks with ModSecurity
Jason Wood
Author: Jason Wood
Share:

Last week I was able speak at MIRcon 2013 about how to use ModSecurity to discover attack activity and defend your environment.  The presentation started out by discussing a fair bit of background information on ModSecurity and how it works.  This was really important since ModSecurity can get a bit involved when setting it up.  This post is the first in several on ModSecurity and will cover how ModSecurity processes HTTP traffic and how that fits in with the rules.

The first time I really read through the ModSecurity configuration and rules, I was a bit puzzled by the constant references to phase 1, phase 2, etc.  What on earth did this mean and what was I supposed to do with it?  After I did some reading, I found that the phases actually refer to what component of the HTTP request and response is being processed.  There are five different phases that ModSecurity works in.  Here is a graphic from ModSecurity’s wiki which illustrates the different phases.

Analyzing Web Attacks with ModSecurity
https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual#wiki-Processing_Phases
  • Phase 1 refers to the processing of the HTTP request headers.  This is where things like cookies, authorization tokens and miscellaneous request information is stored.  
  • Phase 2 is the processing of the HTTP request body.  The request body includes the parameters and data values being sent to the application.  
  • Phase 3 is the analysis of the response headers.  Similar data to what is in phase 1, but now we are checking out what the server is sending back to the client.
  • Phase 4 is processing of the actual response body.  This is where our HTML, XML, JSON, JavaScript and other data is sent to the client.
  • Phase 5 is performed after all of the processing is completed and the HTTP transaction is completed.  This is where ModSecurity does any post processing and logs everything to disk.
With this in mind, it starts making a lot more sense when you read through the rules and configuration information.  When we are looking at our log data and the rules related to an event being fired, you can understand where we were at in the session when the event occurred.  Similarly, we can use this information in writing our own custom rules.  A rule which checks the cookies being sent from the client can only be processed in phase 1.  A rule which omits sensitive data from being logged to disk must specify phase 5.
 
This is a critical bit of information if you decide to run ModSecurity (and really monitor and maintain it).  Our analysis and rules will be a mess if we do not understand what it means when a rule fires in the phase 2 processing or some other stage. 

A final note on MIRcon 2013 itself.  I really enjoyed the opportunity to speak at the conference and want to thank Mandiant for allowing me to do so.  The way the conference ran was fantastic and the quality of the speakers was excellent.  If you get a chance to attend next year’s conference, I’d highly recommend it.  To the Mandiant crew, nice work and well done!

Jason Wood is a Senior Security Consultant at Secure Ideas. If you are in need of a penetration test or other security consulting services you can contact him at jason@secureideas.com or visit the Secure Ideas – Professionally Evil site for services provided.

Join the Professionally Evil newsletter

Sign Up

Related Resources