Thread: [mod-security-users] Disabling modsecurity for Single VirtualHost
Brought to you by:
victorhora,
zimmerletw
From: Ken S. <sh...@gm...> - 2010-04-15 16:07:48
|
I have modsecurity 2.5.12 installed on Apache 2.2.15 with a small subset of the CRS-2.0.6. Everything seems to be working great except for one site. The webserver is hosting about 150 sites on it. This one site is taking about 15 seconds to load the initial index page and is very sluggish; all the other sites that I checked on the server were very responsive so it is something isolated to this site. Thinking the only big change to the server in the past month was the addition of modsecurity I thought I would disable it by commenting out the two "Include *.conf" lines from httpd.conf. After restarting apache the site is now around a 1 second load time and very responsive. After re-enabling it, the site is back to being slow. I don't want to disable modsecurity for them but need to find a way to disable it during the day (when most of their visitors are hitting it) while I try to figure out what is happening in their off-hours and eventually get it re-enabled again. So doing some Google searches I found that you can use "SecRuleEngine Off" to turn it off, however, I cannot get this to work. I have put it in both the virtualhost block and also the directory block and neither place seems to disable modsecurity. I even found a bug report where someone used "SecRuleInheritance Off" so I tried that with no luck; the site still runs slow. <VirtualHost aa.bb.cc.dd:80> ServerName www.mysite.tld ServerAlias mysite.tld DocumentRoot /usr/local/apache2/htdocs/mysite.tld SecRuleEngine Off SecRuleInheritance Off ... And thinking that maybe it was just one of the rules within CRS, I commented out from httpd.conf the line "Include conf/modsecurity/base_rules/*conf" so it wouldn't include any of the rules, and this also results in a slow site. So if anyone sees the silly mistake that I'm missing, I'd be happy if you pointed it out. Also, if you have any ideas on how to debug this issue, I would love those, too. -ken -- Have a nice day ... unless you've made other plans. |
From: Ken S. <sh...@gm...> - 2010-04-16 16:08:23
|
Forgot to copy the list on my previous email. Below is a link to the debug log that was set to 9 for a few seconds while I hit the site. Thanks for any guidance. -ken On Thu, Apr 15, 2010 at 2:44 PM, Ken S. <sh...@gm...> wrote: > On Thu, Apr 15, 2010 at 2:26 PM, Jamuse <ja...@gm...> wrote: >> Can you put debugging on 9 and show some of the debug log, that will >> indicate where the enabled rules are coming from. > > I set the debugging to 9, hit the site, then quickly set it back to 1. > grep'd out the lines to the site we are having issues with and put > them out to a file. Put them up online here: > > http://www.imacollector.com/modsec2-debug.txt > > Lightly sanitized for my sanity. :) > > -ken > > >> >> - J >> >> On Thu, Apr 15, 2010 at 7:07 PM, Ken S. <sh...@gm...> wrote: >>> >>> I have modsecurity 2.5.12 installed on Apache 2.2.15 with a small >>> subset of the CRS-2.0.6. Everything seems to be working great except >>> for one site. The webserver is hosting about 150 sites on it. This >>> one site is taking about 15 seconds to load the initial index page and >>> is very sluggish; all the other sites that I checked on the server >>> were very responsive so it is something isolated to this site. >>> Thinking the only big change to the server in the past month was the >>> addition of modsecurity I thought I would disable it by commenting out >>> the two "Include *.conf" lines from httpd.conf. After restarting >>> apache the site is now around a 1 second load time and very >>> responsive. After re-enabling it, the site is back to being slow. >>> >>> I don't want to disable modsecurity for them but need to find a way to >>> disable it during the day (when most of their visitors are hitting it) >>> while I try to figure out what is happening in their off-hours and >>> eventually get it re-enabled again. >>> >>> So doing some Google searches I found that you can use "SecRuleEngine >>> Off" to turn it off, however, I cannot get this to work. I have put >>> it in both the virtualhost block and also the directory block and >>> neither place seems to disable modsecurity. I even found a bug report >>> where someone used "SecRuleInheritance Off" so I tried that with no >>> luck; the site still runs slow. >>> >>> <VirtualHost aa.bb.cc.dd:80> >>> ServerName www.mysite.tld >>> ServerAlias mysite.tld >>> DocumentRoot /usr/local/apache2/htdocs/mysite.tld >>> SecRuleEngine Off >>> SecRuleInheritance Off >>> ... >>> >>> And thinking that maybe it was just one of the rules within CRS, I >>> commented out from httpd.conf the line "Include >>> conf/modsecurity/base_rules/*conf" so it wouldn't include any of the >>> rules, and this also results in a slow site. >>> >>> So if anyone sees the silly mistake that I'm missing, I'd be happy if >>> you pointed it out. Also, if you have any ideas on how to debug this >>> issue, I would love those, too. >>> >>> -ken >>> -- >>> Have a nice day ... unless you've made other plans. >>> >>> >>> ------------------------------------------------------------------------------ >>> Download Intel® Parallel Studio Eval >>> Try the new software tools for yourself. Speed compiling, find bugs >>> proactively, and fine-tune applications for parallel performance. >>> See why Intel Parallel Studio got high marks during beta. >>> http://p.sf.net/sfu/intel-sw-dev >>> _______________________________________________ >>> mod-security-users mailing list >>> mod...@li... >>> https://lists.sourceforge.net/lists/listinfo/mod-security-users >>> Commercial ModSecurity Appliances, Rule Sets and Support: >>> http://www.modsecurity.org/breach/index.html >> >> > > > > -- > Have a nice day ... unless you've made other plans. > -- Have a nice day ... unless you've made other plans. |
From: Brian R. <Bri...@br...> - 2010-04-17 17:41:29
|
Ken S. wrote: > Forgot to copy the list on my previous email. Below is a link to the > debug log that was set to 9 for a few seconds while I hit the site. > > Thanks for any guidance. > > -ken > > On Thu, Apr 15, 2010 at 2:44 PM, Ken S. <sh...@gm...> wrote: >> On Thu, Apr 15, 2010 at 2:26 PM, Jamuse <ja...@gm...> wrote: >>> Can you put debugging on 9 and show some of the debug log, that will >>> indicate where the enabled rules are coming from. >> I set the debugging to 9, hit the site, then quickly set it back to 1. >> �grep'd out the lines to the site we are having issues with and put >> them out to a file. �Put them up online here: >> >> http://www.imacollector.com/modsec2-debug.txt >> >> Lightly sanitized for my sanity. �:) From what I see there, it is disabled (rule engine, not the audit engine, see below) Here the request is "/" for some periods because it is before the mapping to the filesystem and "/index.php" later on after it was mapped. It shows that ModSecurity was initialized, then shutdown as it was disabled: [/][4] Initialising transaction (txid S8dbxkUUfVYAADZBdAcAAAAM). [/][5] Adding request cookie: name "PHPSESSID", value "uo7fj3tnph39fjc9kc3olk3h14" [/][4] Transaction context created (dcfg 9e40358). [/][4] Processing disabled, skipping (hook request_early). [/][4] PdfProtect: Not enabled here. [/][4] Processing disabled, skipping (hook request_late). [/index.php][4] Hook insert_filter: Adding PDF XSS protection output filter (r b0e8168). [/index.php][4] Hook insert_filter: Processing disabled, skipping. Here is the logging phase started as it was still disabled, but it did not do anything as there was nothing to log. You can use "SecAuditEngine Off" to disable this as well. [/index.php][4] Initialising logging. [/index.php][4] Starting phase LOGGING. [/index.php][4] Audit log: Ignoring a non-relevant request. All the requests are like that above, so I am not sure why it would be taking so long to process. None of the rules are running. See more comments to your original email below... >> >> -ken >> >> >>> - J >>> >>> On Thu, Apr 15, 2010 at 7:07 PM, Ken S. <sh...@gm...> wrote: >>>> I have modsecurity 2.5.12 installed on Apache 2.2.15 with a small >>>> subset of the CRS-2.0.6. �Everything seems to be working great except >>>> for one site. �The webserver is hosting about 150 sites on it. �This >>>> one site is taking about 15 seconds to load the initial index page and >>>> is very sluggish; all the other sites that I checked on the server >>>> were very responsive so it is something isolated to this site. >>>> Thinking the only big change to the server in the past month was the >>>> addition of modsecurity I thought I would disable it by commenting out >>>> the two "Include *.conf" lines from httpd.conf. �After restarting >>>> apache the site is now around a 1 second load time and very >>>> responsive. �After re-enabling it, the site is back to being slow. Include *.conf This, IMHO, is very dangerous way to enable ModSecurity. You are enabling all rules and anything else in there that is *.conf. Better would be to only enable the rule files you need. I think we need to remove this example from the docs. Ryan? >>>> >>>> I don't want to disable modsecurity for them but need to find a way to >>>> disable it during the day (when most of their visitors are hitting it) >>>> while I try to figure out what is happening in their off-hours and >>>> eventually get it re-enabled again. >>>> >>>> So doing some Google searches I found that you can use "SecRuleEngine >>>> Off" to turn it off, however, I cannot get this to work. �I have put >>>> it in both the virtualhost block and also the directory block and >>>> neither place seems to disable modsecurity. �I even found a bug report >>>> where someone used "SecRuleInheritance Off" so I tried that with no >>>> luck; the site still runs slow. >>>> >>>> <VirtualHost aa.bb.cc.dd:80> >>>> � �ServerName www.mysite.tld >>>> � �ServerAlias mysite.tld >>>> � �DocumentRoot /usr/local/apache2/htdocs/mysite.tld >>>> � �SecRuleEngine Off >>>> � �SecRuleInheritance Off >>>> � �... Also: SecAuditEngine Off >>>> >>>> And thinking that maybe it was just one of the rules within CRS, I >>>> commented out from httpd.conf the line "Include >>>> conf/modsecurity/base_rules/*conf" so it wouldn't include any of the >>>> rules, and this also results in a slow site. Hmm, I am confused as you said above that you removed the "Include *.conf" inclusions above and that did help. The above would not do anything except save some RAM for holding all the rules since you had "SecRuleEngine Off". What files was "Include *.conf" including vs "Include conf/modsecurity/base_rules/*conf"? Does commenting out the inclusion of the modsecurity_crs_10_config.conf solve the performance issue (vs all the rule under base_rules directory)? >>>> >>>> So if anyone sees the silly mistake that I'm missing, I'd be happy if >>>> you pointed it out. �Also, if you have any ideas on how to debug this >>>> issue, I would love those, too. Since the "Include *.conf" seems to be including the culprit conf file, I would suggest replacing "Include *.conf" with a set of directives for each file that that included and comment them all out. Then uncomment them one-by-one until you narrow this down. It does not appear that ModSecurity is doing anything to hold this up. The only thing I can think of that ModSecurity may be triggering is one of two things: 1) Interacting with another module badly (seems unlikely given the debug output) 2) Using up enough RAM because of the large number of rules to cause your system to swap RAM to disk. If this is the case, then your system would probably be borderline on running our of RAM anyhow. One other question. Are you loading the CRS globally, or in each Virtual Host? If in each Virtual Host, then this could eat up a lot of RAM if you have a large number of Virtual Hosts. Thanks, -B -- Brian Rectanus Breach Security |