Hello Gessy,
Sorry to hear about your problems. PCRE limit issues are common with the
CRS. They are an inherent problems when using PCRE and not all rules
are optimised to avoid it.
The limit is here to protect you from DoS via Regex (-> REDoS). But in
the default ModSec setting the limit will stop a rule from being
executed. So if an attacker can construct the payload in a way that
fails with a PCRE limit exception - and still work as an exploit on the
backend - he has successfully circumvented one of your rules. Your
defense is raising the PCRE limits. Both, as you did. But this makes you
more vulnerable to REDoS. However in the age of the Mirai botnet,
REDoS might be your least DoS concern, so it is generally OK to
raise the limits to even higher levels. Personally, I run some prod
servers with a limit of 1M.
I investigated this throughly for the 2nd edition of the ModSecurity
Handbook. It was only at 1M that I started to see a performance impact.
You can monitor it fairly easily via the overall duration of the request
or the ModSecurity performance data for phase 2.
With that being said, I suggest you raise some more and then you look
at the rules in question. I would not mind you issuing some tickets
on github with the exact payload and the rules where you ran into
the PCRE limits.
I do not think you should disable the susceptible rules, but it is
generally OK to ignore the PCRE limit alerts. If you stick with the
default setting of ModSec and CRS, the rule is simply aborted and
execution continues with the next rule.
If this is still unclear, then just ask.
Ahoj,
Christian
On Wed, Jan 04, 2017 at 01:52:34PM +, Gessy wrote:
> Hi
> Thanks to the community for all support and would like to ask one more
> question
> I used modsecurity with CRS 2.2.5 rules and everything worked as expected.
> I have decided to upgrade to modsecurity 2.9.1 and CRS 3.0.0 by following
> the INSTALL file.
>
> Then I started having many blocking events with the message "ModSecurity
> internal error flagged: TX: MSC_PCRE_LIMITS_EXCEEDED"
>
> I googled it and tried the solution
>
> SecPcreMatchLimit 15
> SecPcreMatchLimitRecursion 15
>
> But it did not work and it did not help to further increase the limits
>
> So I thought about disabling the rule that generates this block but I saw
> that several rules can generate this
>
> I'm having many events of this mainly with sites that use shibboleth
> authentication and I do not know how to solve it anymore ... Does anyone
> know how to solve this problem?
>
> Thank you so much!!!
> ___
> Owasp-modsecurity-core-rule-set mailing list
> Owasp-modsecurity-core-rule-set@lists.owasp.org
> https://lists.owasp.org/mailman/listinfo/owasp-modsecurity-core-rule-set
--
https://www.feistyduck.com/training/modsecurity-training-course
mailto:christian.fol...@netnea.com
twitter: @ChrFolini
___
Owasp-modsecurity-core-rule-set mailing list
Owasp-modsecurity-core-rule-set@lists.owasp.org
https://lists.owasp.org/mailman/listinfo/owasp-modsecurity-core-rule-set
