|
From: Ryan B. (JIRA) <no...@mo...> - 2011-03-11 14:53:38
|
[ https://www.modsecurity.org/tracker/browse/MODSEC-46?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Ryan Barnett closed MODSEC-46.
------------------------------
Resolution: Invalid Config
This has been addressed in the CRS by having all skipAfter actions use SecMarker locations instead of active ruleIDs.
> SecRuleRemoveById vs SecRuleUpdateActionById
> --------------------------------------------
>
> Key: MODSEC-46
> URL: https://www.modsecurity.org/tracker/browse/MODSEC-46
> Project: ModSecurity
> Issue Type: Bug
> Security Level: Normal
> Components: Core
> Affects Versions: 2.5.7
> Environment: CentOS5
> Reporter: Jason Haar
> Assignee: Breno Silva Pinto
> Fix For: 2.6.0
>
>
> I have spent around two weeks trying to find out why one of our backend servers wasn't been protected by modsecurity, when others were. The only difference between the configs came down to some SecRuleRemoveById rules, and sure enough, when I commented them all out, the server started blocking things it was supposed to. In the end I had to disable them all, and one by one re-enable them until the problem re-appeared, to figure out the cause.
> It was rule 959005, and it was actually the line "SecAction phase:2,pass,nolog,skipAfter:959005" in modsecurity_crs_40_generic_attacks.conf that caused the problem. Basically disabling that one rule caused the skipAfter to trigger and skip all the remaining rules?
> Anyway, I see that back in Jan Ofer Shezaf had the same problem, and the solution mentioned for him worked for me too - use SecRuleUpdateActionById instead.
> I think that's a REAL GOTCHA. That's just plain too hard to remember. Most of your users won't have testbeds of attacks they try against their servers, and one day they'll disable one rule and won't even know they've effectively disabled modsecurity due to some skipAfter rule. I mean - there isn't even a relationship. You test rule "x", find it doesn't work when it should, and it ends up being an issue associated with rule Y.
> It seems to me I'd be better off just exclusively using SecRuleUpdateActionById to disable rules. If that is true, why bother having SecRuleRemoveById? Or alias SecRuleRemoveById to "SecRuleUpdateActionById NUMBER 'pass,nolog'"?
> Or, what about making SecRuleRemoveById not remove all traces of the rule, so that skipAfter can still act properly?
> Just my 2cents
> Jason
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://www.modsecurity.org/tracker/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
|
