# mod_security-2.1.1 not stopping the request [RESOLVED]

## hanj

Hello All

Running out of places to turn. I'm running into some weird behaviour with the recent mod_security 2.x upgrade.

The problem is this. I have a simple SecRule that is designed to catch spam before it goes to my processing page. When I do my tests, it 'appears' to give a 403 Access Denied and all is good.. but it's not.. it still allows the request to go through. I can reproduce this 100% of the time.

I stripped all rules out except for the 10_config.conf base rules and added the one rule in there.. and the behaviour is the same. I made sure I restarted Apache every time. Looking at the logs it almost appears the request is handle first.. then passed to mod_security. This definitely didn't happen in mod_sec 1.x. Here is an example:

Here my request:

```
xxx.xxx.xxx.xxx - - [27/May/2007:12:51:25 -0600] "POST /index.php/contact.process HTTP/1.1" 302 - "http://www.domain.com/index.php/contact.main.htm" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.11) Gecko/20070312 Firefox/1.5.0.11"
```

Notice, I received 302 code. Now.. seconds later...

```
[Sun May 27 12:51:57 2007] [error] [client xxx.xxx.xxx.xxx ] ModSecurity: Access denied with code 403 (phase 2). Pattern match "(viagra|cialis|phentermine|levitra)" at REQUEST_BODY. [hostname "www.domain.com"] [uri "/index.php/contact.process"] [unique_id "IHB45ULbO5UAAAmaXPIAAAAB"]
```

Now, mod_sec denies with 403, but that is AFTER the request already made it to the server. PHP took the request and sent me an email with the SPAM in it.

Here is my ENTIRE mod_sec conf:

```
SecRuleEngine On

SecRequestBodyAccess On

SecResponseBodyAccess On

SecResponseBodyMimeType (null) text/html text/plain text/xml

SecResponseBodyLimit 524288

SecDefaultAction "phase:2,log,deny,status:403"

SecServerSignature "Apache"

SecRule REQUEST_BODY "(viagra|cialis|phentermine|levitra)"

SecUploadDir /tmp

SecUploadKeepFiles Off

SecAuditEngine RelevantOnly

SecAuditLogRelevantStatus "^[45]"

SecAuditLogType Serial

SecAuditLog logs/modsec_audit.log

SecAuditLogParts "ABIFHZ"

SecArgumentSeparator "&"

SecCookieFormat 0

SecRequestBodyInMemoryLimit 131072

SecDebugLog             logs/modsec_debug.log

SecDebugLogLevel        3

SecDataDir /tmp

SecTmpDir /tmp
```

I'm hoping someone can see something goofy in there. Not sure why the order of mod_sec would be goofed. I removed all of the other policy rules, etc for eliminating. Currently, when I execute my test, Apache does NOT throw a 403 to the browser and everything appears fine, yet the logs show 403 for mod_sec.

I'll probably need to roll back in the meantime.

Here are my current packages.. maybe it's a USE issue??

```
[ebuild   R   ] net-www/mod_security-2.1.1  USE="-doc" 0 kB

[ebuild   R   ] net-www/apache-2.0.58-r2  USE="apache2 mpm-prefork ssl -debug -doc -ldap -mpm-itk -mpm-leader -mpm-peruser -mpm-threadpool -mpm-worker (-selinux) -static-modules -threads" 4,652 kB
```

Thanks!

hanji

EDIT

Installing 2.2.1-r1 corrects the problem with subrequests. Patch listed below was prior to 2.2.1-r1 release and was used to fix sub request issue. The patch is for mod_security vs mod_limitipconn.

----------

## hanj

I tried re-compiling Apache and Mod_Security.. no help. Rolling back to 1.8.4 and everything is working as it should. I've posted various emails to the mod_sec mailing list, I'll report anything I find from there. I would advise others to test their mod_sec rules to see if processing continues.. if so, this is a serious bug with mod_security.

Thanks

hanji

----------

## hanj

Additional information this morning. Looks like there is a conflict or issue related to another module. I'm currently using mod_limitipconn and if I remove that module, mod_security-2.1.1 works as expetected. limitipconn had no issues with 1.8.4 or 1.9.4 versions of mod_security. I submited a query to the mod_security mailing list to see if there is a solution to the problem, since I really need to have this module as well, but would rather have mod_security if I had to choose.

```
[ebuild   R   ] net-www/mod_security-2.1.1  USE="-doc" 0 kB

[ebuild   R   ] net-www/mod_limitipconn-0.22-r1  7 kB

[ebuild   R   ] net-www/apache-2.0.58-r2  USE="apache2 mpm-prefork ssl -debug -doc -ldap -mpm-itk -mpm-leader -mpm-peruser -mpm-threadpool -mpm-worker (-selinux) -static-modules -threads" 4,652 kB
```

Is anyone else using mod_limitipconn and mod_security-2.1.1?

Thanks!

hanji

----------

## hanj

Apparently, I'm the only one on the planet using mod_security-2.1.1 and mod_limitipconn.. weird. 

Anyways, they issued a patch for testing and it corrected the problem. Once I get more information from them, I'll submit a bug and see if devs can include the official patch the current ebuild for 2.1.1. Other modules might experience the same issues, so you may want to test.

If you need to patch right away (and use at your own risk), here is the patch and procedure for using portage overlay for mod_security:

Fix for mod_security-2.1.1 and mod_limitipconn

Thanks!

hanji

----------

## terminallymortal

This mod_limitipconn patch breaks custom 500 ErrorDocument scripts

[12/Jul/2007:11:25:58 --0600] [mydomain.ca/sid#9263190][rid#943a2a0][/gallery/.../][1] Access denied with code 500 (phase 2). Pattern match "\\.\\.\\./" at REQUEST_URI. [id "300006"] [rev "1"] [msg "Bogus Path denied"] [severity "CRITICAL"]

[12/Jul/2007:11:25:58 --0600] [mydomain.ca/sid#9263190][rid#943a2a0][/gallery/.../][4] Time #2: 968063

[12/Jul/2007:11:25:58 --0600] [mydomain.ca/sid#9263190][rid#944e9c0][/error/error.cgi][4] Phase REQUEST_BODY subrequest already intercepted with code 500.

[12/Jul/2007:11:25:58 --0600] [mydomain.ca/sid#9263190][rid#944e9c0][/error/error.cgi][4] Initialising logging.

Browser gets the old: "Additionally, a 500 Internal Server Error error was encountered while trying to use an ErrorDocument to handle the request."

Remove the patch and it works peachy.

----------

## hanj

The original problem was mod_security's handling of sub-requests. Version 2.1.1-r1 includes the code that handles that (basically the patch I linked to above). If you're running 2.1.1-r1, you don't want to add the patch.. and that might have broke your 500 handling. I just tested my 2.1.1-r1 w/limitipconn, and custom 500 is working fine on my end.

Thanks!

hanji

----------

