Mod_security-2.1.1 and mod_limitipconn patch procedure

Hello all

The mod_security team quickly isolated my problem and generated a patch for me to address it. To give a summary of the issue, when updating to mod_security-2.1.1 AND using mod_limitipconn-0.22-r1, mod_security blocks are bypassed. Mod_security logs the rule trigger and states that it issued a 403 (or whatever status you set 500, etc), but the request is not stopped and processing is continued. Obviously, this is a bad thing. Removing mod_limitipconn or rolling back to mod_security-1.8.7 fixed the problem.

It was great the mod_sec team worked hard to get a patch out, since mod_limitipconn is a great Apache module and didn’t want to leave it behind to take the mod_security.

Thought I’d take a moment to discuss how I applied the patch in my Gentoo environment.

Here is the patch file that was sent to me (subrequests.diff)

Hello all

It was great the mod_sec team worked hard to get a patch out, since mod_limitipconn is a great Apache module and didn’t want to leave it behind to take the mod_security.

Thought I’d take a moment to discuss how I applied the patch in my Gentoo environment.

Here is the patch file that was sent to me (subrequests.diff)

Index: apache2/mod_security2.c =================================================================== --- apache2/mod_security2.c (revision 266) +++ apache2/mod_security2.c (working copy) @@ -558,6 +558,10 @@

/* Has this phase been completed already? */ if (msr->phase_request_body_complete) { + if (msr->was_intercepted) { + msr_log(msr, 4, "Phase REQUEST_BODY subrequest already intercepted with code %u.", msr->intercept_actionset->intercept_status); + return msr->intercept_actionset->intercept_status; + } if (msr->txcfg->debuglog_level >= 4) { msr_log(msr, 4, "Phase REQUEST_BODY already complete, skipping."); }

The current ebuild does not deal with any patches, etc. and this change will be rolled in the next release of mod_security. So in the meantime, I need to patch the source. To do this, and to keep everything portage friendly, I opted to use the local portage overlay. I’m assuming that you already have your overlay defined in /etc/make.conf, but if not, I defined it to be /usr/local/portage.

mkdir -p /usr/local/portage/net-www/mod_security/files cd /usr/local/portage/net-www/mod_security/files vi subrequests.diff cd .. cp /usr/portage/net-www/mod_security/mod_security-2.1.1.ebuild . vi mod_security-2.1.1.ebuild

To explain what happened above, I created directories for my overlay mod_security and created the diff file in the /files directory. Next, I took the existing ebuild and copied it to here. For this to work, we need to modify this ebuild (and that’s why we’re doing this in a overlay vs. portage since emerge –sync will nuke our changes there).

First we need to add an additional ‘inherit’, since it’s currently only inheriting apache-module. We need to add ‘eutils’ since we’ll be using epatch in the ebuild to patch the source. The line should like like this:

inherit apache-module eutils

Next we need to actually execute the patch. Add a new routine called src_unpack() to the ebuild:

src_unpack() { unpack ${A} cd "${S}" epatch "${FILESDIR}/"subrequests.diff }

Do this after ‘need_apache2’.

With our ebuild looking good, we need to create a manifest to make sure portage is happy when we try to emerge this modified mod_security ebuild. Issue the following command

ebuild mod_security-2.1.1.ebuild digest

You should see the following output:

>>> Creating Manifest for /usr/local/portage/net-www/mod_security

Next, do a pretend emerge for mod_security.

emerge -pv mod_security

You should see something like this:

These are the packages that would be merged, in order:

Calculating dependencies... done! [ebuild R ] net-www/mod_security-2.1.1 USE="-doc" 0 kB [1]

Total: 1 package (1 reinstall), Size of downloads: 0 kB Portage overlays: [1] /usr/local/portage

Notice it’s looking in /usr/local/portage since that will be preferred over the ebuild in /usr/portage now.

Once you emerge for real, keep an eye out for the following during the emerge process:

>>> Unpacking source... >>> Unpacking modsecurity-apache_2.1.1.tar.gz to /var/tmp/portage/net-www/mod_security-2.1.1/work * Applying subrequests.diff ... [ ok ] >>> Source unpacked.

You should be all good to go. I asked for an ‘official’ patch file (since I was just testing with their patch). Once I have the official file, I’ll submit it to bugs/gentoo.org and see if we can get the current ebuild updated to use this patch file, then we can dismiss our portage overlay of mod_security.