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 +0000, 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 150000 > SecPcreMatchLimitRecursion 150000 > > 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
