Re: [Owasp-modsecurity-core-rule-set] Problem with ModSecurity internal error flagged: TX: MSC_PCRE_LIMITS_EXCEEDED
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
[Owasp-modsecurity-core-rule-set] Problem with ModSecurity internal error flagged: TX: MSC_PCRE_LIMITS_EXCEEDED
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
Re: [Owasp-modsecurity-core-rule-set] Owasp-modsecurity-core-rule-set Digest, Vol 93, Issue 1
Hi Gessy,
I had some time to try and replicate your scenario and was able to
achieve the result you are aiming. The problem is the "chain" keyword
at the end of the SecRuleUpdateActionById directive; try with this:
SecRuleUpdateActionById 949110 "t: none, redirect: 'http://'"
The manual says:
Note : If the target rule is a chained rule, you must currently
specify chain in the SecRuleUpdateActionById action list as well. This
will be fixed in a future version.
But rule 949110 is not a chained rule.
I'm not sure, but I think the chain word cause the following (changes
deny with redirect and appends chain at the end of the rule):
SecRule TX:ANOMALY_SCORE "@ge %{tx.inbound_anomaly_score_threshold}" \
"msg:'Inbound Anomaly Score Exceeded (Total Score: %{TX.ANOMALY_SCORE})',\
severity:CRITICAL,\
phase:request,\
id:949110,\
t:none,\
redirect:'http://',\
log,\
tag:'application-multi',\
tag:'language-multi',\
tag:'platform-multi',\
tag:'attack-generic',\
setvar:tx.inbound_tx_msg=%{tx.msg},\
setvar:tx.inbound_anomaly_score=%{tx.anomaly_score},
chain"
SecRule TX:PARANOIA_LEVEL "@lt 1"
"phase:1,id:949011,nolog,pass,skipAfter:END-REQUEST-949-BLOCKING-EVALUATION"
I say I'm not sure about the above chain because redirect and pass are
both disruptive actions, and there can be only one and in the first
rule of the chain, so modsecurity should raise an error (but I don't
get any).
Hope this will help you
Regards
Paolo Luise
> Date: Mon, 02 Jan 2017 13:51:06 +
> From: Gessy
> To: "owasp-modsecurity-core-rule-set@lists.owasp.org"
>
> Subject: [Owasp-modsecurity-core-rule-set] Redirect to another URL on
> blocking problem
> Message-ID:
>
> Content-Type: text/plain; charset="utf-8"
>
> Hi
>
> I installed modsecurity 2.9.1 on a CentOS 6 and tried to use the CRS3 rules.
> Then I made the default configuration only modified the
> RESPONSE-999-EXCLUSION-RULES-AFTER-CRS.conf file so when there is a
> blocking action, the client is redirected to a specific page.
>
> Then I used:
>
> SecRuleUpdateActionById 949110 "t: none, redirect: 'http://',
> chain"
> SecRuleUpdateActionById 959100 "t: none, redirect: 'http://',
> chain"
>
> But it did not work when I tested it with http:
> ///?foo=../../../etc/passwd
>
> When I comment the lines that change the Disruptive Action for Anomaly
> Mode, the blocking occurs as expected with code 403
>
> Does anyone know how to make this work.
> Thank you!
>
> Gessy
___
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
