Hello. Here there's a example where they use chain: https://samhobbs.co.uk/2015/09/example-whitelisting-rules-apache-modsecurity-and-owasp-core-rule-set SecRuleUpdateActionById 981175 "chain,deny,status:501"
Have you tried with chain instead? Regards El mar., 15 de noviembre de 2016 17:40, Christian Folini < christian.fol...@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 > > > /etc/modsecurity/owasp-modsecurity-crs/rules/RESPONSE-950-DATA-LEAKAGES.conf: > > [...] 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. > > Ahoj, > > Christian > > > -- > 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@lists.owasp.org > https://lists.owasp.org/mailman/listinfo/owasp-modsecurity-core-rule-set >
_______________________________________________ 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
