Thread: [mod-security-users] v1.9 memory usage problem
Brought to you by:
victorhora,
zimmerletw
Menu
▾
▴
mod-security-users
|
From: Jim <st...@cl...> - 2006-04-23 07:35:22
|
Hi all, First time post here and newsgroup newbie in general so I hope I do this correctly :) ----- Distro: CentOS 3.6 (cPanel control panel installed) RAM: 2 GB Swap: 4 GB ----- root@xxxx [/usr/src]# uname -a Linux xxxx.xxxx.xxxx 2.4.21-40.ELsmp #1 SMP Wed Mar 15 14:21:45 EST 2006 i686 i686 i386 GNU/Linux ----- Apache (v1.3.34) loaded modules: Compiled-in modules: http_core.c mod_env.c mod_log_config.c mod_mime.c mod_negotiation.c mod_status.c mod_include.c mod_autoindex.c mod_dir.c mod_cgi.c mod_asis.c mod_imap.c mod_actions.c mod_userdir.c mod_alias.c mod_access.c mod_auth.c mod_so.c mod_setenvif.c mod_ssl.c mod_frontpage.c suexec: enabled; valid wrapper /usr/local/apache/bin/suexec ----- PHP (v4.4.2) compile line: './configure' '--with-apxs=/usr/local/apache/bin/apxs' '--with-xml' '--enable-bcmath' '--enable-calendar' '--with-curl' '--with-dom' '--with-dom-xslt' '--with-dom-exslt' '--enable-ftp' '--with-gd' '--with-jpeg-dir=/usr/local' '--with-png-dir=/usr' '--with-xpm-dir=/usr/X11R6' '--with-imap' '--with-imap-ssl' '--with-kerberos' '--enable-mbstring' '--enable-mbstr-enc-trans' '--enable-mbregex' '--with-mcrypt' '--with-ming=../ming-0.2a' '--enable-magic-quotes' '--with-mysqli' '--with-mysql=/usr' '--with-openssl' '--enable-discard-path' '--with-pear' '--enable-sockets' '--enable-track-vars' '--with-ttf' '--with-freetype-dir=/usr' '--enable-gd-native-ttf' '--enable-versioning' '--with-xmlrpc' '--with-zlib' '--enable-xslt' '--with-xslt-sablot' '--with-sablot-js=/usr' ----- The issue I am posting about has previously been discussed here: http://www.gotroot.com/tiki-view_forum_thread.php?forumId=35&comments_threshold=0&comments_parentId=658&comments_offset=0&comments_maxComments=20&comments_style=commentStyle_threaded The problem we (and others from the look of that thread) have seen is that mod_security is causing used RAM to go extremely high resulting in swapping. We first saw this when upgrading from mod_security v1.8.7 to version 1.9.1. After being unable to find the cause, we rolled back to 1.8 and all has been fine. Recently, the upgrade has been tried again (this time to v1.9.3) with exactly the same problem. This only happens on 2 of our servers out of about 45-50 which is very strange. When Apache is started things are fine with each httpd process showing around 20-30 MB usage in 'top'. Within approx 15 minutes, one httpd process (a parent) can then be seen to be using 1.0-1.1 GB of RAM in 'top'. Soon after, things go downhill. I have been using trial and error to try and find the cause of this but it's definitely related to mod_security. When no rules are in use (but module still loaded in httpd.conf) there is no problem. In fact, I have narrowed it down to the 'SecFilterScanPOST' setting - when this is enabled the problem occurs, when disabled/Off there is no problem. Our ruleset is a custom ruleset comprising of around 500-600 rules. We are continuing to troubleshoot this to see if we can find common factors between the very few servers affected. This post is mainly to see if anyone has experienced similar problems with the 1.9 branch of mod_security? Maybe the data in this post will be of use to anyone troubleshooting the same issue. If any additional info is needed (or suggestions to try and post back), feel free to ask. Thanks, Jim |
|
From: Justin G. <web...@sw...> - 2006-04-23 07:43:24
|
must be one of the rules I guess. We use 1.9.3 on several servers with way more than 500 rules and don't see it. We're on RHEL 3/4 here. Justin Jim wrote: > Hi all, > > First time post here and newsgroup newbie in general so I hope I do this correctly :) > > ----- > > Distro: CentOS 3.6 (cPanel control panel installed) > RAM: 2 GB > Swap: 4 GB > > ----- > > root@xxxx [/usr/src]# uname -a > Linux xxxx.xxxx.xxxx 2.4.21-40.ELsmp #1 SMP Wed Mar 15 14:21:45 EST 2006 i686 i686 i386 GNU/Linux > > ----- > > Apache (v1.3.34) loaded modules: > > Compiled-in modules: > http_core.c > mod_env.c > mod_log_config.c > mod_mime.c > mod_negotiation.c > mod_status.c > mod_include.c > mod_autoindex.c > mod_dir.c > mod_cgi.c > mod_asis.c > mod_imap.c > mod_actions.c > mod_userdir.c > mod_alias.c > mod_access.c > mod_auth.c > mod_so.c > mod_setenvif.c > mod_ssl.c > mod_frontpage.c > suexec: enabled; valid wrapper /usr/local/apache/bin/suexec > > ----- > > PHP (v4.4.2) compile line: > > './configure' '--with-apxs=/usr/local/apache/bin/apxs' '--with-xml' '--enable-bcmath' '--enable-calendar' '--with-curl' '--with-dom' '--with-dom-xslt' '--with-dom-exslt' '--enable-ftp' '--with-gd' '--with-jpeg-dir=/usr/local' '--with-png-dir=/usr' '--with-xpm-dir=/usr/X11R6' '--with-imap' '--with-imap-ssl' '--with-kerberos' '--enable-mbstring' '--enable-mbstr-enc-trans' '--enable-mbregex' '--with-mcrypt' '--with-ming=../ming-0.2a' '--enable-magic-quotes' '--with-mysqli' '--with-mysql=/usr' '--with-openssl' '--enable-discard-path' '--with-pear' '--enable-sockets' '--enable-track-vars' '--with-ttf' '--with-freetype-dir=/usr' '--enable-gd-native-ttf' '--enable-versioning' '--with-xmlrpc' '--with-zlib' '--enable-xslt' '--with-xslt-sablot' '--with-sablot-js=/usr' > > ----- > > > The issue I am posting about has previously been discussed here: http://www.gotroot.com/tiki-view_forum_thread.php?forumId=35&comments_threshold=0&comments_parentId=658&comments_offset=0&comments_maxComments=20&comments_style=commentStyle_threaded > > The problem we (and others from the look of that thread) have seen is that mod_security is causing used RAM to go extremely high resulting in swapping. > > We first saw this when upgrading from mod_security v1.8.7 to version 1.9.1. After being unable to find the cause, we rolled back to 1.8 and all has been fine. Recently, the upgrade has been tried again (this time to v1.9.3) with exactly the same problem. > > This only happens on 2 of our servers out of about 45-50 which is very strange. When Apache is started things are fine with each httpd process showing around 20-30 MB usage in 'top'. Within approx 15 minutes, one httpd process (a parent) can then be seen to be using 1.0-1.1 GB of RAM in 'top'. Soon after, things go downhill. > > I have been using trial and error to try and find the cause of this but it's definitely related to mod_security. When no rules are in use (but module still loaded in httpd.conf) there is no problem. In fact, I have narrowed it down to the 'SecFilterScanPOST' setting - when this is enabled the problem occurs, when disabled/Off there is no problem. > > Our ruleset is a custom ruleset comprising of around 500-600 rules. We are continuing to troubleshoot this to see if we can find common factors between the very few servers affected. > > This post is mainly to see if anyone has experienced similar problems with the 1.9 branch of mod_security? Maybe the data in this post will be of use to anyone troubleshooting the same issue. > > If any additional info is needed (or suggestions to try and post back), feel free to ask. > > Thanks, > > Jim > > > > ------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > mod-security-users mailing list > mod...@li... > https://lists.sourceforge.net/lists/listinfo/mod-security-users |
|
From: Jim <st...@cl...> - 2006-04-23 07:55:48
|
Hi, > must be one of the rules I guess. We use 1.9.3 on several servers with way more than 500 rules > and don't see it. We're on RHEL 3/4 here. That;s the thing, the *exact* same ruleset works perfectly on v1.8 but not on v1.9. Is there any specific changes made to the software between these versions with regard to how 'SecFilterScanPOST' is handled which could cause this? Jim |
|
From: Justin G. <web...@sw...> - 2006-04-23 07:59:20
|
Is this apache 2 or 1? If it's 1, try using pcre (look in the docs about compiling). This might speed things a lot. Justin Jim wrote: > Hi, > >> must be one of the rules I guess. We use 1.9.3 on several servers with way more than 500 rules >> and don't see it. We're on RHEL 3/4 here. > > That;s the thing, the *exact* same ruleset works perfectly on v1.8 but > not on v1.9. Is there any specific changes made to the software > between these versions with regard to how 'SecFilterScanPOST' is > handled which could cause this? > > Jim > > > > > > ------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > mod-security-users mailing list > mod...@li... > https://lists.sourceforge.net/lists/listinfo/mod-security-users |
|
From: Ivan R. <iva...@gm...> - 2006-04-23 08:10:25
|
On 4/23/06, Jim <st...@cl...> wrote: > Hi, > > > must be one of the rules I guess. We use 1.9.3 on several servers with = way more than 500 rules > > and don't see it. We're on RHEL 3/4 here. > > That;s the thing, the *exact* same ruleset works perfectly on v1.8 but > not on v1.9. Is there any specific changes made to the software > between these versions with regard to how 'SecFilterScanPOST' is > handled which could cause this? Not that I recall. Which 1.8.x version exactly is that? -- Ivan Ristic, Technical Director Thinking Stone, http://www.thinkingstone.com ModSecurity: Open source Web Application Firewall |
|
From: Jim <st...@cl...> - 2006-04-23 08:15:26
|
>> That;s the thing, the *exact* same ruleset works perfectly on v1.8 but >> not on v1.9. Is there any specific changes made to the software >> between these versions with regard to how 'SecFilterScanPOST' is >> handled which could cause this? > Not that I recall. Which 1.8.x version exactly is that? We're currently running (and having no problems with) mod_security version 1.8.7. We've tried versions 1.9.1, 1.9.2 and 1.9.3 and hit the same issue each time before rolling back to 1.8.7. |
|
From: Ivan R. <iva...@gm...> - 2006-04-23 08:02:51
|
On 4/23/06, Jim <st...@cl...> wrote: > Hi all, Hi Jim, > This only happens on 2 of our servers out of about 45-50 which is very st= range. Are all these servers running the same software and the same rule set? > Our ruleset is a custom ruleset comprising of around 500-600 rules. Please send me the ruleset (privately) and I'll have a look. To begin with I want to rule out a known regex library problem that causes problems similar to those you describe. -- Ivan Ristic, Technical Director Thinking Stone, http://www.thinkingstone.com ModSecurity: Open source Web Application Firewall |
|
From: Jim <st...@cl...> - 2006-04-23 08:13:42
|
Hello Ivan, >> This only happens on 2 of our servers out of about 45-50 which is very strange. > Are all these servers running the same software and the same rule set? Throughout all servers there is a mixture on Centos v3 and v4 with the same Apache + PHP versions (though slightly different compile options on PHP throughout). All servers run exactly the same mod_sec ruleset. >> Our ruleset is a custom ruleset comprising of around 500-600 rules. > Please send me the ruleset (privately) and I'll have a look. To begin > with I want to rule out a known regex library problem that causes > problems similar to those you describe. I'll send this over to you in a sec. Thanks, Jim |
|
From: Ivan R. <iva...@gm...> - 2006-04-23 09:19:33
|
On 4/23/06, Jim <st...@cl...> wrote: > ... > The issue I am posting about has previously been discussed here: http://w= ww.gotroot.com/tiki-view_forum_thread.php?forumId=3D35&comments_threshold= =3D0&comments_parentId=3D658&comments_offset=3D0&comments_maxComments=3D20&= comments_style=3DcommentStyle_threaded A small comment for the sake of list subscribers: I've been in touch with several people who referred me to this forum thread. All of the issues so far have been related to having too little memory to handle the workload. Still, I am approaching every problem report as a new issue just in case. -- Ivan Ristic, Technical Director Thinking Stone, http://www.thinkingstone.com ModSecurity: Open source Web Application Firewall |
|
From: Jim <st...@cl...> - 2006-04-23 09:57:18
|
Hi, Thank you for looking into this Ivan. My main intention in posting here was to see whether there was a 'quick fix' from others who have experienced the same issue (in case it was a known bug or similar) as it seemed odd that this issue only happening with the upgrade of mod_sec with all other variables (hardware, server activity, software config) remaining exactly the same. With this not being the case, I'm happy to put this issue on hold for the time being. I will follow your advice on adding back the rules in separate blocks to see if we can get closer to any that could be causing this. If this doesn't work I will get all the testing data you mentioned in your email such as requests per second, mem usage, etc. I'll post back here with any findings. Thanks again, Jim |
|
From: Ivan R. <iva...@gm...> - 2006-04-23 10:09:58
|
On 4/23/06, Jim <st...@cl...> wrote: > Hi, > > Thank you for looking into this Ivan. My main intention in posting > here was to see whether there was a 'quick fix' from others who have > experienced the same issue (in case it was a known bug or similar) as > it seemed odd that this issue only happening with the upgrade of > mod_sec with all other variables (hardware, server activity, software > config) remaining exactly the same. My gut feeling is that 1.9.x requires more memory than 1.8.x, so that might be the problem. FYI my gut feeling also tells me 2.x will require more memory than 1.9.x. The only known problem that applies is the one I already mentioned, documented here: https://www.thinkingstone.com/tsn/defects/view_defect.php?defect=3DMSA-116 > With this not being the case, I'm happy to put this issue on hold for > the time being. That's OK, but be aware that if you don't pursue the issue probably no one else will. -- Ivan Ristic, Technical Director Thinking Stone, http://www.thinkingstone.com ModSecurity: Open source Web Application Firewall |
|
From: Jim <st...@cl...> - 2006-04-23 11:33:57
|
Hello Ivan,
I had planned to begin troubleshooting properly tomorrow but while I was here I started some things and thought I'd post back as the early results are interesting.
I upgraded to mod_sec 1.9.3 again and first tried the suggestion of adding the 'DynamicOnly' and no post buffer settings and got the same problem.
Next, I started with the removal of all rules and adding them back block by block to see if this turns anything up. I removed everything and got the same problem within 10 minutes of the apache restart.
mod_sec config:
root@xxxx [~]# cat /etc/httpd/conf/mod_security.conf
# Turn the filtering engine On or Off
SecFilterEngine DynamicOnly
# Make sure that URL encoding is valid
SecFilterCheckURLEncoding Off
# Unicode encoding check
SecFilterCheckUnicodeEncoding Off
# Only allow bytes from this range
SecFilterForceByteRange 0 255
# Only log suspicious requests
SecAuditEngine RelevantOnly
# The name of the audit log file
SecAuditLog /var/log/httpd/audit_log
# Debug level set to a minimum
SecFilterDebugLog /var/log/httpd/modsec_debug_log
SecFilterDebugLevel 0
# Should mod_security inspect POST payloads
SecFilterScanPOST On
# By default log and deny suspicious requests
# with HTTP status 500
SecFilterDefaultAction "deny,log,status:406"
# no ban to localhost
SecFilterSelective REMOTE_ADDR "^127.0.0.1$" nolog,allow
# suggestion by mod_sec devs
SetEnvIfNoCase Content-Type "^multipart/form-data;" \
"MODSEC_NOPOSTBUFFERING=Do not buffer file uploads"
SecFilterSelective THE_REQUEST "_vti_bin" allow,nolog
SecFilterSelective THE_REQUEST "/fpsrvadm\.exe" pass
SecFilterSelective THE_REQUEST "/fpremadm\.exe" pass
SecFilterSelective THE_REQUEST "/admisapi/fpadmin\.htm" pass
SecFilterSelective THE_REQUEST "/scripts/Fpadmcgi\.exe" pass
SecFilterSelective THE_REQUEST "/_private/orders\.txt" pass
SecFilterSelective THE_REQUEST "/_private/form_results\.txt" pass
SecFilterSelective THE_REQUEST "/_private/registrations\.htm" pass
SecFilterSelective THE_REQUEST "/cfgwiz\.exe" pass
SecFilterSelective THE_REQUEST "/authors\.pwd" pass
SecFilterSelective THE_REQUEST "/_vti_bin/_vti_aut/author\.exe" pass
SecFilterSelective THE_REQUEST "/administrators\.pwd" pass
SecFilterSelective THE_REQUEST "/_private/form_results\.htm" pass
SecFilterSelective THE_REQUEST "/_vti_pvt/access\.cnf" pass
SecFilterSelective THE_REQUEST "/_private/register\.txt" pass
SecFilterSelective THE_REQUEST "/_private/registrations\.txt" pass
SecFilterSelective THE_REQUEST "/_vti_pvt/service\.cnf" pass
SecFilterSelective THE_REQUEST "/service\.pwd" pass
SecFilterSelective THE_REQUEST "/_vti_pvt/service\.stp" pass
SecFilterSelective THE_REQUEST "/_vti_pvt/services\.cnf" pass
SecFilterSelective THE_REQUEST "/_vti_bin/shtml\.exe" pass
SecFilterSelective THE_REQUEST "/_vti_pvt/svcacl\.cnf" pass
SecFilterSelective THE_REQUEST "/users\.pwd" pass
SecFilterSelective THE_REQUEST "/_vti_pvt/writeto\.cnf" pass
SecFilterSelective THE_REQUEST "/dvwssr\.dll" pass
SecFilterSelective THE_REQUEST "/_private/register\.htm" pass
SecFilterSelective THE_REQUEST "/_vti_bin/" pass
httpd processes in top when problem starts (see highlighted process which is the parent httpd process previously mentioned):
root@xxxx [~]# top -b | grep httpd
2088 nobody 15 0 24756 24M 5352 S 0.4 1.2 0:00 0 httpd
1479 root 15 0 24072 23M 4944 S 0.0 1.1 0:01 0 httpd
1497 nobody 15 0 28128 27M 5488 S 0.0 1.3 0:01 1 httpd
1498 nobody 15 0 31420 30M 5664 S 0.0 1.5 0:02 0 httpd
1499 nobody 15 0 28688 28M 5668 S 0.0 1.3 0:01 0 httpd
1500 nobody 15 0 29768 29M 5652 S 0.0 1.4 0:01 0 httpd
1501 nobody 15 0 34308 33M 5676 S 0.0 1.6 0:01 1 httpd
1502 nobody 15 0 29076 28M 5676 S 0.0 1.4 0:02 0 httpd
1503 nobody 15 0 31460 30M 5664 S 0.0 1.5 0:02 1 httpd
********
1504 nobody 15 0 1052M 1.0G 5492 S 0.0 52.4 0:03 1 httpd
********
1505 nobody 15 0 31636 30M 5668 S 0.0 1.5 0:02 0 httpd
1506 nobody 15 0 37040 36M 5464 S 0.0 1.8 0:01 0 httpd
2086 nobody 15 0 27888 27M 5412 S 0.0 1.3 0:00 0 httpd
2087 nobody 15 0 24684 24M 5320 S 0.0 1.2 0:00 0 httpd
2104 nobody 16 0 24628 24M 5316 S 0.0 1.1 0:00 1 httpd
Output of free:
root@xxxx [~]# free -m
total used free shared buffers cached
Mem: 2006 1983 23 0 61 515
-/+ buffers/cache: 1406 600
Swap: 4094 148 3945
================================================
================================================
Next, I kept things *exactly* the same except I changed one line of the mod_sec config:
root@xxxx [~]# grep SecFilterScanPOST /etc/httpd/conf/mod_security.conf
SecFilterScanPOST Off
I sat and watched top for 30-40 minutes (the big httpd process has usually reared its head by this time) and all is fine:
root@xxxx [~]# top -b | grep httpd
2322 nobody 15 0 35492 34M 5496 S 1.4 1.7 0:02 1 httpd
2325 nobody 15 0 36964 36M 5496 S 0.9 1.7 0:01 0 httpd
2330 nobody 15 0 36112 35M 5504 S 0.9 1.7 0:03 0 httpd
2327 nobody 15 0 37252 36M 5672 S 0.4 1.8 0:02 1 httpd
2329 nobody 15 0 29296 28M 5504 S 0.4 1.4 0:02 1 httpd
2311 root 15 0 24076 23M 4944 S 0.0 1.1 0:01 0 httpd
2321 nobody 15 0 31444 30M 5496 S 0.0 1.5 0:02 0 httpd
2323 nobody 15 0 31592 30M 5664 S 0.0 1.5 0:02 0 httpd
2324 nobody 15 0 30424 29M 5508 S 0.0 1.4 0:02 1 httpd
2326 nobody 15 0 35908 35M 5504 S 0.0 1.7 0:03 1 httpd
2328 nobody 15 0 37556 36M 5492 S 0.0 1.8 0:03 1 httpd
root@xxxx [~]# free -m
total used free shared buffers cached
Mem: 2006 1125 881 0 92 603
-/+ buffers/cache: 428 1577
Swap: 4094 151 3943
================================================
================================================
Finally, I rolled back to version 1.8.7 (this is a live server and I can't leave it on 1.9) and put our full ruleset back into place (including SecFilterScanPOST On). As it has been doing for months on this version, everything is still fine.
root@xxxx [~]# top -b | grep httpd
4321 nobody 15 0 36732 35M 5620 S 0.9 1.7 0:02 0 httpd
4325 nobody 15 0 30792 30M 5636 S 0.9 1.4 0:03 0 httpd
4327 nobody 15 0 54432 53M 5628 S 0.9 2.6 0:10 1 httpd
4328 nobody 16 0 26240 25M 5428 S 0.9 1.2 0:01 1 httpd
4315 nobody 15 0 29888 29M 5464 S 0.4 1.4 0:01 1 httpd
4317 nobody 15 0 27272 26M 5444 S 0.4 1.3 0:01 1 httpd
4308 root 15 0 24552 23M 4928 S 0.0 1.1 0:01 0 httpd
4318 nobody 15 0 30404 29M 5460 S 0.0 1.4 0:02 1 httpd
4319 nobody 15 0 29752 29M 5480 S 0.0 1.4 0:02 0 httpd
4322 nobody 15 0 36556 35M 5444 S 0.0 1.7 0:02 0 httpd
4326 nobody 15 0 28120 27M 5448 S 0.0 1.3 0:01 0 httpd
4357 nobody 15 0 30624 29M 5444 S 0.0 1.4 0:02 1 httpd
4537 nobody 15 0 27656 27M 5364 S 0.0 1.3 0:00 0 httpd
4538 nobody 15 0 25100 24M 5196 S 0.0 1.2 0:00 0 httpd
4539 nobody 15 0 25216 24M 5344 S 0.0 1.2 0:00 1 httpd
root@xxxx [/var/log/httpd]# free -m
total used free shared buffers cached
Mem: 2006 1167 838 0 98 654
-/+ buffers/cache: 415 1590
Swap: 4094 151 3943
================================================
================================================
One thing I forgot to mention earlier which I don't think should make a difference but not sure is that we're using the -DDISABLE_HTACCESS_CONFIG flag on our mod_security compiles to disable the addition/alteration of rulesets via user htaccess files.
|
|
From: Ivan R. <iva...@gm...> - 2006-04-23 17:22:37
|
On 4/23/06, Jim <st...@cl...> wrote: > Hello Ivan, > > I had planned to begin troubleshooting properly tomorrow but while I was = here I started some things and thought I'd post back as the early results a= re interesting. Thanks a lot for the detailed information. > ... > Finally, I rolled back to version 1.8.7 (this is a live server and I can'= t leave it on 1.9) and put our full ruleset back into place (including SecF= ilterScanPOST On). As it has been doing for months on this version, everyt= hing is still fine. I think we should focus on the fact 1.9.x with no rules creates problems for you where 1.8.7 does not. I will create a special version of mod_security for you to test and hopefully we'll locate the problem. -- Ivan Ristic, Technical Director Thinking Stone, http://www.thinkingstone.com ModSecurity: Open source Web Application Firewall |
|
From: Ivan R. <iva...@gm...> - 2006-04-28 09:50:42
|
On 4/23/06, Ivan Ristic <iva...@gm...> wrote: > > I think we should focus on the fact 1.9.x with no rules creates > problems for you where 1.8.7 does not. I will create a special version > of mod_security for you to test and hopefully we'll locate the > problem. We did locate and fix the problem. The fix is now available in 1.9.4-rc1, which was updated to handle some of the more unusual requests better (these requests caused high memory consumption that Jim reported). Try this version if you've been experiencing similar issues. (If not, wait for the "proper" 1.9.4.) -- Ivan Ristic, Technical Director Thinking Stone, http://www.thinkingstone.com ModSecurity: Open source Web Application Firewall |
Thanks for helping keep SourceForge clean.
X