> On 06 Mar 2016, at 10:00, Franziska Buehler
> <franziska.buehler.schmoc...@gmail.com> wrote:
>
> Hi,
>
> We have some proposals for stricter siblings of existing rules.
> When cloning rules to stricter siblings, multiple rules at different
> paranoia levels could match.
> Several clones of a rule should use strict limits to avoid multiple
> log entries for one request.
I also think that 'stricter siblings’ should not cause rule matches for all
siblings.
Having multiple log lines in the audit entry for one violation will be
confusing to users and waste space.
Your message also makes me remember another possible problem: the anomaly score
being increased multiple times. (I don’t recall if this was already decided on
earlier, in any case I can’t find it in the list archives)
For instance, if a user runs at paranoia level 4, we don’t want the following
to happen:
> Paranoia level 2:
> SecRule ARGS_NAMES|ARGS|XML:/* "([\~\!\@\#\.....\<\>].*?){5,}" \…
anomaly +5
> Paranoia level 3:
> SecRule ARGS_NAMES|ARGS|XML:/* "([\~\!\@\#\.....\<\>].*?){3,}" \…
anomaly +5
> Paranoia level 4:
> SecRule ARGS_NAMES|ARGS|XML:/* "[\~\!\@\#\.....\<\>]" \…
anomaly +5
…which gives the user an anomaly score of 15 for a single character sequence.
It seems counter-intuitive to me that we’d accumulate the anomaly score just by
the presence of a single threat heuristic (that we happen to have multiple
siblings for). This would make these rules overpowered compared to the other
rules.
So, I think it’s very important to prevent multiple sibling rules firing.
If we want to prevent this, we could do it with a variable. As soon as a
sibling triggers, we just set a variable specific to that ‘family’ of siblings.
The other siblings would chain on that variable and simply not trigger when
it’s set by an earlier sibling. Then, as the rules are handled from top to
bottom, simply the most severe sibling will be triggered and logged.
It comes with a little bit of rule complexity in handling the variables, but
this will be an easy copy-pasteable recipe, we won’t have to change the
paranoia mechanism, and its performance impact is low.
(Alternatively, in the rule example you’ve given, we could hand-craft the rules
to only trigger in their specific instance, like:
- level 2: {5,}
- level 3: {3,4}
- level 4: {1,2}
but this has the danger that we will mistype and cause a ‘hole’ in the
coverage. I think it’s safer for the rules to “overlap” and prevent multiple
triggers through another mechanism.)
Any thoughts or other possible solutions?
Cheers!
WH
_______________________________________________
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
