Monday, July 11, 2016

Audit ModSecurity Log Quickly and Systematically with Reconity

Having recently installed ModSecurity as my web application firewall, I started to keep an eye on the audit logs generated by ModSecurity regularly.  The audit log records web access events which had set off any of the configured firewall rules.  For example, an event entry in the log may look this (IP addresses have been masked for privacy):

[27/Jun/2016:08:18:10 +0000] V3GlK2-sf88lhesfakqlUgAAI X.X.X.X 57596 Y.Y.Y.Y 80
GET /../../../../../../../mnt/mtd/OCxW HTTP/1.1
Host: Z.Z.Z.Z
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/48.0.2564.103 Safari/537.36
Accept-Encoding: gzip
Connection: close

HTTP/1.1 400 Bad Request
X-Content-Type-Options: nosniff
Content-Length: 226
Connection: close
Content-Type: text/html; charset=iso-8859-1

Message: Warning. String match "Invalid URI in request" at WEBSERVER_ERROR_LOG. [file "/etc/httpd/modsecurity.d/activated_rules/modsecurity_crs_20_protocol_violations.conf"] [line "82"] [id "981227"] [rev "1"] [msg "Apache Error: Invalid URI in Request."] [data "GET /../../../../../../../mnt/mtd/OCxW HTTP/1.1"] [severity "WARNING"] [ver "OWASP_CRS/2.2.8"] [maturity "9"] [accuracy "9"] [tag "OWASP_CRS/PROTOCOL_VIOLATION/INVALID_REQ"] [tag "CAPEC-272"]
Apache-Error: [file "core.c"] [line 4306] [level 3] AH00126: Invalid URI in request %s
Stopwatch: 1467015490548268 657 (- - -)
Stopwatch2: 1467015490548268 657; combined=435, p1=213, p2=0, p3=1, p4=41, p5=131, sr=92, sw=49, l=0, gc=0
Producer: ModSecurity for Apache/2.8.0 (; OWASP_CRS/2.2.8.
Server: Apache
Engine-Mode: "ENABLED"


The above entry tells us that one of the installed rules caught and blocked an illegitimate attempt to access private and protected resource on the server.  According to the entry, the source of the intrusion was X.X.X.X, the offending request was "GET /../../../../../../../mnt/mtd/OCxW", the response was "400 Bad Request" and the rule in violation was 981227.

Often, my audit log also contains false alarms or events pertaining to the internal workings of ModSecurity rather than an external offense such as:

[13/Jun/2016:15:48:05 +0000] V11sVtSgC7wd3k4LMd8eSAXAAAg 52076 80
POST /foo HTTP/1.1
Host: localhost

HTTP/1.1 200 OK
X-Content-Type-Options: nosniff
Content-Type: application/json; charset=utf-8

Message: collections_remove_stale: Failed deleting collection (name "ip", key "X.X.X.X_c7ad53c03q60y9cdrf1e71t5e4k04bx21e589z6e"): Internal error
Apache-Handler: application/x-httpd-php
Stopwatch: 1465832885236582 714358 (- - -)
Stopwatch2: 1465832885236582 714358; combined=4576, p1=259, p2=0, p3=0, p4=0, p5=2162, sr=104, sw=2, l=0, gc=2153
Producer: ModSecurity for Apache/2.8.0 (; OWASP_CRS/2.2.8.
Server: Apache


This particular event is harmless and is caused by a bug in ModSecurity as discussed in a previous article.

A typical log of mine contains a garden variety of events like the ones above.  When the log is big, sifting through it becomes time consuming especially if I want to examine every single recorded event out of paranoia.  What I needed was a simple tool for exploratory analysis of the log.  Being a software engineer, I decided to spend some time building a tool to my specification.

And so born Reconity, an online interactive log auditing tool for ModSecurity.  The tool extracts key event information from part A, B, F and H of the log into an interactive table so I can inspect events quickly.  With a single mouse click, I can hide events like the aforementioned internal errors from view and switch my attention over to other more serious events.  The tool was built in mind to help audit log systematically by narrowing down important events quickly.


I wrote the tool mostly in JavaScript so that it can run in a browser.  There is no manual to learn or read as the web user interface is intuitive.  Since processing is done within the browser, there is no need to upload log file to a remote machine for processing or invoke commands at the command line.  This means sensitive log data remains private and local to the browser computer.  While JavaScript may not be the fastest programming language out there, I was able to audit 100,000 events (~200 MB log file) responsively with the tool.  With optimization, I should be able to extend the limit further if my log ever get bigger than 200 MB.

As I have been using the tool for weeks now, I find that it saves time for me from the laborious task of log auditing.  If auditing ModSecurity log is one of your regular routines, you are welcome to simplify the chore with Reconity!


  1. Hey Navid not sure what your git handle is but we'd love to have you drop by the OWASP-CRS git page. We have some updates to the DOS logic that we'd love you to test out to see how you like it and if you have any suggestions. Nice Posts and good work on Reconity.

    1. Thanks for the comment and invite! I'm okay with the DoS rule changes because they are at a higher paranoid level and from what I've gathered, the paranoid levels are suppose to generate more false positives.