Mod_Security Questions, Problems And Issues

I have seen conflicting opinions regarding the necessity of mod_security on the forum. We have been having (in past as well) issues where performance periodically is bad, especially in the back end. It appears in these cases that something is trying to make a connection outside the browser and this is timing out. We just upgraded to CS-Cart 4.3.3 and our VPS has ModSecurity for Apache v2.9.0 installed. Log monitoring during issues seemed to indicate mod_security was the cause and we found an offending line, so we disabled mod_security for our CS-Cart domain (only CS-Cart is running here) as a quick fix and it worked . The problems seem to have gone away but since the the prevailing opinion on the forum is that mod_security should not be disabled I'm concerned that this makes us vulnerable. We have a subdomain for our Wordpress blog but left mod_security enabled there and this will be what we do going forward: that is, isolating applications by domain and configuring separately.

In a domain or subdomain with just CS-Cart is mod security in fact needed or is CS-Cart defensively coded so as to make mod_security unnecessary? If needed, is a list of rules available to properly configure mod_security for CS-Cart? Perhaps this thread might be a good place to start one and could serve as a permanent resource. Maybe CS-Cart support could contribute recommended list of rules to disable, using a CS-Cart only domain or subdomain as a reference which could then be modified as needed for other cases.

We found one line in the error log which was associated with a mod_security rule and elected to disable module rather than deal with the specific error, since our log monitoring was very limited and so there must be others anyway. Looking at forum posts on mod_security I saw that mod_security could interpret form coding mistakes as sql injection attacks and this makes sense since we have a new but uncompleted custom search add-on.

I am not a server, linux or coder guy. I have to leave that good stuff to others for now but nevertheless try to deal with issues as they arise. Hopefully I'll learn a bit in the process. Please bear with any lack of understanding and, as always, thanks for any insights.

No system is coded well enough to not need layered security ... and a Web Application Firewall like Mod_sec is a good addition to any server.

You can whitelist specific urls/sub's instead of just disabling the whole rule or set.

http://resources.infosecinstitute.com/avoiding-mod-security-false-positives-white-listing/

What you are describing above though with timeouts sounds like something other than mod_security by itself.

No system is coded well enough to not need layered security ... and a Web Application Firewall like Mod_sec is a good addition to any server.

You can whitelist specific urls/sub's instead of just disabling the whole rule or set.

http://resources.infosecinstitute.com/avoiding-mod-security-false-positives-white-listing/

What you are describing above though with timeouts sounds like something other than mod_security by itself.

Thanks for reply. We just upgraded to PHP 5.6 and that seemed to eliminate the timing out behavior and the pages load quickly now, however there are still problems. The fact that the timeouts just stopped seems to point to some kind of problem with PHP 5.4.

5.6 is recommended for CS-Cart and Multi-Vendor 4.3.x

https://www.cs-cart.com/requirements.html

What are the other problems you are still having?

5.6 is recommended for CS-Cart and Multi-Vendor 4.3.x

https://www.cs-cart.com/requirements.html

What are the other problems you are still having?

Thanks for reply. Trying to access our devx site running 4.2.4 was generating errors, including 500 errors. This was traced to a PHP misconfiguration and fixed. One that is not yet explained or fixed on our 4.3.3 production site is that debug mode won't start. In addition to the php update to 5.6 we added APC, Redis, opcache and mod_deflate as recommended on CS-Cart blog (5 tweaks to opptimize for 4.3.x, including php 5.6). This is the one we are currently trying to solve. Interestingly (and naturally), the production and devx sites are sharing the same environment but the 4.2.4 site goes in to debug mode while the 4.3.3 site does not.