When I started reading Christian’s answer I was sure, I will defend my point of view and we absolutely have to limit the firing sibling rules to only one per request. But when I continued reading I have to admit, that Christian has a point.
Confusing people by adding new rules, apparently at random, by changing the paranoia level, is really not nice. That’s true. On this point I don’t entirely agree with you, Christian: “The higher you go. The more alerts you get and the higher the score. This is what I would expect from a paranoia setting.” We already have a stricter rule on a higher level. We don’t also need a higher score, triggered by more matching rules. I don’t like the fact, that with a higher paranoia level you get a higher score, caused by these stricter siblings. You also don’t. That is what you described with: “So cumulation has an unbalancing effect.“ That could mislead to raise the anomaly threshold at a higher paranoia level. That’s dangerous. But I also agree, that if someone chooses a higher paranoia level, he knows what he does and will instead tune the rules. And your approach to choose a low paranoia level, then tune and choose a higher level also makes sense. With our numbering scheme (incrementing last digit) we always see at a glance which rules belong together: 9xxxx0, 9xxxx1, 9xxxx2. That should simplify the log’s readability and If someone is familiar with these stricter siblings he immediately understands the system and identifies why a request was blocked. At the end I agree with both of you. Let’s keep it simple and avoid unnecessary complexity! Regards, Franziska 2016-03-06 22:48 GMT+01:00 Walter Hop <mod...@spam.lifeforms.nl>: > Hi Christian, > > Some very good points! > > I agree with your assessment about the rule complexities. I agree that > keeping rules simple is extremely important, especially given our low > resources. > > But of course, a real attack will trigger 3 times. And I > do not mind that. If there is a real attack then I am > very open for anomaly score to grow at great velocity. And > in fact that is the behaviour of the 2.2.X core rules: > > > This is true, too. This unbalanced distribution of anomaly scores between > parts of the CRS is already there since CRS v2. And it’s not that big of a > problem. > > If you are paranoid, you should probably use 5 as your blocking threshold > anyway. In that case, a higher anomaly score has no difference on a blocking > decision. > > In a way, it might even be useful to an admin to get the multiple rules > logged if they run at high paranoia level. They can instantly see all the > relevant rule ID’s, there is no magic, and people can simply apply their > whitelistings so that they also cover the lower rules. > > When I read Franziska's message, I was ready to agree. But > then I thought about it and I came to the conclusion, that > alert cumulation is not ideal, but everything else is even > worse. > > Let's keep it simple even if it brings a few more alerts. > > > Good characterization. Let’s keep it simple, the drawbacks of multiple > alerts are likely not worth the added burden of reducing them. > > -- > Walter Hop | PGP key: https://lifeforms.nl/pgp > > > _______________________________________________ > 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
