[Owasp-modsecurity-core-rule-set] Issues with CRS3
Jose Pablo Valcárcel Lázaro
pablo.valcarcel1980 at gmail.com
Tue Nov 15 17:28:53 UTC 2016
Here there's a example where they use chain:
SecRuleUpdateActionById 981175 "chain,deny,status:501"
Have you tried with chain instead?
El mar., 15 de noviembre de 2016 17:40, Christian Folini <
christian.folini at netnea.com> escribió:
> Hi there,
> On Tue, Nov 15, 2016 at 04:44:15PM +0100, Heinrich M. wrote:
> > thank you for your great work! It is just great that there exists an
> > open source WAF and a corresponding ruleset! Thank you.
> You are most welcome. Glad you like it.
> > I'm quite new to ModSecurity. Today, I found some time to play around
> > with ModSecurity and the new CRS release in a basic testing setup. I
> > hope that I will be able to introduce ModSec and the CRS3 in some small
> > prod environment soon.
> Please keep us posted about your experience. Us, the dev team has
> years of experience and this is in fact a big problem as we do not
> even see the small problems and the many questions that new users
> like you face. Your perspective is very valuable.
> > 1. Issue
> > After including the new CRS rule files, apache didn't fire up.
> > journalctl provided the following error messages:
> > [...] Syntax error on line 36 of
> > [...] Error parsing actions: Unknown action: \\
> > Workaround (I don't know what other effects of this might be...): Adding
> > a space to line 36 resolved the issue: "t:none, \"
> This is a known issue with older Apache versions. It is documented
> in the CRS KNOWN_BUGS file:
> >* Apache 2.4 prior to 2.4.11 is affected by a bug in parsing multi-line
> > configuration directives, which causes Apache to fail during startup
> > with an error such as:
> > Error parsing actions: Unknown action: \\
> > Action 'configtest' failed.
> > ...
> > We advise to upgrade your Apache version. If upgrading is not possible,
> > we have provided a script in the util/join-multiline-rules directory
> > which converts the rules into a format that works around the bug.
> > You have to re-run this script whenever you modify or update
> > the CRS rules.
> Your workaround works equally well.
> > 2. Issue
> > Changing the blocking actions did not work as documented in
> > RESPONSE-999-EXCLUSION-RULES-AFTER-CRS.conf.
> > I tried to use the example "send an error 404" (line 67 and below).
> > With the two rules activated, blocking dind't work anymore. Removing the
> > "chain" from the actions made blocking work again. The rules then are as
> > follows:
> > SecRuleUpdateActionById 949110 "t:none,deny,status:404"
> > SecRuleUpdateActionById 959100 "t:none,deny,status:404"
> Ooops. I need to take a look at this. I'll be back.
> Worst-case thinking encourages society to adopt fear as of one
> of the key principles around which the public, the government
> and various institutions should organise their lives. It
> institutionalises insecurity and fosters a mood of confusion
> and powerlessness. Through popularising the belief that worst
> cases are normal, it also encourages people to feel defenceless
> and vulnerable to a wide range of future threats. In all but
> name, it is an invitation to social paralysis.
> -- Frank Furedi
> Owasp-modsecurity-core-rule-set mailing list
> Owasp-modsecurity-core-rule-set at lists.owasp.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Owasp-modsecurity-core-rule-set