Interesting article on Apache logging
There is a really nice article on ONLamp: Profiling LAMP Applications with Apache's Blackbox Logs. Most Apache users accept the default logging configuration and often never realise exactly what is going on. This works when things are going well, but not so much when a problem arises and needs to be troubleshooted. In the article, Chris Josephes explains how to make the most of the Apache logging facilities.
It is surprising how little people talk about logging, given that data is essential for forensic analysis. One of the reasons I initially created mod_security is to allow me to see the contents of POST requests.
Honeypot Scan of the Month 31: Open Proxy Challenge
The Honeypot Scan of the Month project consists of a series of challenges where readers are presented with raw service logs, and given a task to analyze and decode the attacks. In the latest edition of Scan of the Month, Ryan C. Barnett presents logs from running an Apache open proxy for a month: Open Proxy Honeypot. Since only three days remain until the end of the challenge it is too late to participate but that's not important - seeing the raw logs is fascinating in itself. Mod_security audit log feature was used to collect POST data.
ModSecurity audit log to MySQL parser
Dhillon A. K. has written a new article about mod_security. The article is essentially a brief introduction to the module. More importantly, however, there is a piece of code attached to the article (in PHP) that parses the mod_security audit log and inputs the data it into a MySQL database. I didn't really have time to try it out myself, but seems pretty handy if you want to inspect the data afterwards!
Chroot support significantly improved in v1.8
Last night I updated the code that provides the internal chroot functionality in mod_security. I am glad to announce version 1.8 will be much more reliable. The tricky part when doing chroot from within a module is that you don't know when to perform the call! Let me explain.
Apache modules are initialised twice. First attempt is a drill: Apache wants to know every module will know how to initialise itself (the configuration is correct, etc). The second attempt is the real thing. Unfortunately, a module does not (and cannot) know if it is being called for the first or for the second time.
The approach I used before is to look at the parent process id. It seemed to me the parent pid was always 1 (init) on second initialisation. As it turns out - I was wrong. In some instances the pid was different, causing mod_security to miss the opportunity to invoke chroot. To resolve this I rewrote the code to use a file on disk as a lock, and now it works great.
While I was doing that I used the opportunity and enhanced the code in other ways, to remove potential weaknesses and provide better error reporting when something goes wrong. The end result is a much more solid implementation. If you want to try it out - download the nightly CVS snapshoot.