Well this rules targeting Ruby on Rails vulnerability (CVE 2013-0156)
If you don’t have Ruby on your server you can safe disable them.
If you want to dig deeper:
PCRE limits exceeded is common problem in high-load environment. It happens when content analyzed by security rule with Perl regular expression is too complex or number of requests is too high. To avoid Deny of Service (DoS) on your server here is PCRE limits on guard.
For example, using a simple ‘aaaaaaaaaaaaaaaaaab’ style pattern in a parameter payload repeated 50 times makes a request go from 0.1 seconds to 5.5 seconds with a bad regex and 150,000 limit set. Making the pattern repeat 100 times yields 22.4 seconds to process it. During this time the Apache process is using 100% of one CPU core.
Higher value of PCRE limits means Apache will spend more time processing requests before limits reached. This can lead to DoS.
Lower value of PCRE limits means less probable DoS situation, but some requests will be dropped with “PCRE limits exceeded (-8): (null)” error.
So it’s important to find which value of PCRE limits will be good for your server. Not allowing DoS attacks and keeping “PCRE limits exceeded” errors at low level.
Here is recommended steps for tuning PCRE limits:
1. First, update your perl modules on server by running /scripts/checkperlmodules script several times (until you see no error messages)
Add to your PHP.INI the following commands:
pcre.backtrack_limit = 10000000
pcre.recursion_limit = 10000000
Try to change parameters in /usr/local/apache/conf/modsec2.conf to (alternatively you can use cPanel CWAF plugin->“Security Engine” tab):
SecPcreMatchLimit 50000
SecPcreMatchLimitRecursion 5000
If this not help try to change SecPcreMatchLimit and SecPcreMatchLimitRecursion to higher values. (SecPcreMatchLimitRecursion < SecPcreMatchLimit)
I run a WAF on a reverse proxy for customers to block attacks so it should block all kinds of attacks.
I already do remove some rules, it’s just that I thought I should ask about a general advice here first.
I dont have that ‘/scripts/checkperlmodules’, and I already increased the pcre limit ten fold from Trustwaves recommendation :-).
I have
/etc/modsecurity/modsecurity.conf:SecPcreMatchLimit 10000
/etc/modsecurity/modsecurity.conf:SecPcreMatchLimitRecursion 10000
/etc/apache2/mods-available/security2.conf: SecPcreMatchLimit 1000000
/etc/apache2/mods-available/security2.conf: SecPcreMatchLimitRecursion 1000000
Not sure what takes precedence but Trustwaves general advice is a mere 1000.
So removing (SecRemove*) the rule is what’s left then?
Hmm, yes for proxy configuration it’s wise to not disable any protection but processing more rules require more resources.
Seems you have two mod_security configuration (/etc/modsecurity/modsecurity.conf and /etc/apache2/mods-available/security2.conf)
Please check your Apache config. Which one is loading?
If both loads simultaneously only last option will take effect.
I’m not sure you need two mod_security configuration files
Also can you please describe your installation (Operating system, Web server, Web control panel (webmin, Plesk etc), how rules was installed (plugin, vendor, just downloaded) )
Rules 220041 & 220042
Ubuntu 14.04 running Apache 2.4 with modsecurity 2.7.7 and latest cwaf rules.
It’s a cluster of apache nodes which we can scale up almost infinitely high so resource usage is not a prime concern right now. We have http/https load balancer which balances traffic to a set of identically configured modsecurity apache hosts, which then in turn reverse proxies to the real backends. No control panel.
/etc/apache2/mods-enabled/security2.conf is the governing file. It initiates mod_security, further includes /etc/modsecurity/modsecurity.conf and lastly cwaf rules :-).
# Default Debian dir for modsecurity's persistent data
SecDataDir /var/cache/modsecurity
SecPcreMatchLimit 1000000
SecPcreMatchLimitRecursion 1000000
# Main config options
IncludeOptional /etc/modsecurity/*.conf
# Comodo Waf attack patterns
Include "/usr/share/cwaf/etc/cwaf.conf"
So now following values are in effect (from /etc/modsecurity/modsecurity.conf):
SecPcreMatchLimit 10000
SecPcreMatchLimitRecursion 10000
Tuning PCRE Limits is tricky business and performed for certain server
As I see values are equal but SecPcreMatchLimitRecursion have to be < SecPcreMatchLimit (as described in recommendation).
