Apache suEXEC chroot patch

Posted by ivanr on March 27, 2006.

I was recently involved with a project where we needed to configure an Apache server that was intended to run multiple web sites/applications. It's a pretty common assignment. To ensure the setup is secure I decided to start by creating a separate user account for each application. This allowed me to correctly configure file permissions to allow Apache to serve the static files directly. To take care of the dynamic content, I configured suEXEC to execute each application's scripts under its own account. (In case you are wondering, this particular server is fast enough to run the scripts as CGIs. But if process creation becomes a bottleneck we can always seamlessly switch to FastCGI to avoid the performance penalty. Nothing to worry about, then.)

SuEXEC is a great tool but I'd love it to be capable of jailing (via the chroot system call) the binaries it executes. However, this feature is not present in the stock version. Having been responsible for the internal chroot feature of ModSecurity, I think I have a pretty good idea of why this is the case: unless you know what you're doing it's pretty easy to break applications with chroot. And if that happens you are going to ask for help... from those that created the feature, right? Of course! As it turns out, chrooting is notoriously difficult to debug remotely and that's why the developers would much rather not deal with it.

But, if do you know your way around feel free to use my suexec chroot patch, which I have just added to the Apache Tools project. But, please, don't write to me if it's not working as you are expecting :)

Posted by ivanr at 04:11 PM

First development release of ModSecurity 2.x

Posted by ivanr on March 08, 2006.

It's that time of year again, when I get to work on new features (instead of supporting the old ones). With a major change to the version number of the way I took the opportunity to introduce major improvements too. ModSecurity 2.0.0-dev1 is available right now and it offers the following major improvements:

Transaction scoring.
IP address tracking and blacklisting.
IP address scoring.
RPC API.
Functions (e.g. you are no longer confined to using only regular expressions in rules).
Real-time Black List (RBL) support.
Completely re-written response buffering code. It is now more robust, consumes less memory, and able to put a limit on the response size.

The new features are properly documented so you shouldn't have any problems trying them out. I will follow up on some of them here, to explain why I think they will change how you view ModSecurity.

P.S. There is no support for Apache 1.x in this development release.

Posted by ivanr at 10:54 AM

Small but important improvements in ModSecurity 1.9.3

Posted by ivanr on March 06, 2006.

I have just released ModSecurity for Apache 1.9.3-rc1, a release candidate, as I always do when there are less than trivial changes in a release. I normally do not add new features to a stable branch, but I was recently testing ModSecurity Console and realised a few small changes could yield significant improvements to the users. It's not a problem for me since I'm always running the development version anyway but I expect people will be using 1.9.x for months to come. Adding the improvements to the development branch (2.x) was out of the question. The improvements are as follows:

New action, logparts, can be used to change what is logged to the audit log on the per-request basis. This is pretty exciting as it allows you, for example, to not log the response bodies by default, but to do log them for transactions where the bodies contain suspicios content.
New variables, SCRIPT_BASENAME and REQUEST_BASENAME, make it easier to look at the filenames and, especially, at their extensions. This makes it easier to ignore certain transactions (e.g. static files) and focus on the important stuff.
Multiple messages are now supported per transaction (in the audit log). Yay! This is great for people that wish to use ModSecurity as an intrusion detection tool only.

Posted by ivanr at 09:57 PM