Wow! You won me over. Your message summarizes all my uneasiness with the 0-40 idea, which I was not quite able to express but did not go away even after it sounded like there was growing consensus for 0-40.
Let's stick with 0-4! And if we ever need a bigger namespace, we can easily map 0->0 1->10 2->20 3->30 4->40 in an early rule as the spaces are distinct where it matters. Your proposed table looks like the missing core of the whole core rules documentation. We totally need this and hopefully the python bindings will help us come with this in an more or less automatic manner (I knew they would be useful as soon as I read about them). Definitions and default value. I agree on the need for good criteria for the individual levels. However, I think we are not in a position to define the criteria as strictly as you do. I have a criteria proposal in my blogpost too, but it is less strict. I think we should introduce and paranoia mode and then sharpen the criteria as me grow in experience. With that being said, I still think that "1" should be the default level and 80% of the existing rules in 3.0.0rc1 should remain on this level. For the time being that is. I would rather have too many false positives on a standard install then a fatal false negative on the same install. Your criteria make it look like a lot of the existing rules would land on level 1 and 2 while the default installation would set the level at 0. This may have to do with my preference for the anomaly scoring mode of ModSec, while the strict-blocking mode of operation is be more likely to block on minimal indicators of an attack. If we start at default level 1 and most rules on that level (outside of the ~45 candidates which we will move to level 2-4). We can then sharpen our toolset and keep a very close eye on the rules in level 1 and their false positive rate. If we learn that some rules never really trigger false positives, then let's move them to 0. If there are rules, which happen to trigger too many FPs, then we can we can shift them to level 2. But I think this process will take a year or two to play out. We need experience. Best, Christian On Tue, Feb 09, 2016 at 09:05:34PM +0100, Walter Hop wrote: > It’s a bit of a bikeshed subject, but I think a few levels is better. I think > it would be a tricky future if we'd have to say things like: “hmmm, this rule > is too heavy for 10 but too light for 15, let’s put it at 13”. How would a > novice user ever guess the effects? Most people will pick one number and then > troubleshoot. > > We are brainstorming a lot about rules and parameters but we don’t have > consensus on definitions first. If we have an integer scale with so many > levels it might be very hard to describe what happens at a level. If we have > just a few levels, we can provide definitions. What about this: > > paranoia level 0: we try blocking definite attacks with small chance of false > positives (default) > paranoia level 1: we will be strict about protocol anomalies, this might > cause some special clients like loadbalancers and scanners to cause false > positives > paranoia level 2: we will start blocking on suspicious heuristics which > aren’t indicative of a certain attack but can be suspicious (e.g. use of MANY > special characters; low-value PHP keywords and OS commands) > paranoia level 3: the CRS will apply stricter heuristics (e.g. use of SOME > special characters) > paranoia level 4: the CRS will be the most strict > > Then, we could easily document and maintain our paranoia decisions. > We could make a table like this, so sysadmins know exactly what is happening: > > ruleId > 0 > 1 > 2 > 3 > 4 > what would trigger? > 920300 > allowed > warning > warning > block > block > no Accept header > 920350 > allowed > warning > warning > block > block > Host is IP4 address > 931130 > allowed > allowed > block > block > block > /?url=http://example.com > 9123456 > allowed > allowed > block on 40 chars > block on 10 chars > block on 1 char > /?id=%00blah > > This clarity is something you lose if you can go to 40 levels. > > Cheers, > WH > > > On 08 Feb 2016, at 22:12, Christian Folini <christian.fol...@netnea.com> > > wrote: > > > > Thanks Chaim and Lukas! > > > > I got positive feedback via private messages too. > > > > The one question, where I am still unsure (and the > > feedback / criticism is also split) is the question > > of the good integer range for the paranoia level. > > 0-4 or rather 0-40. > > > > Still not sure. > > > > Thoughts on this question are thus very welcome. > > > > Ahoj, > > > > Christian > > > > > > On Mon, Feb 08, 2016 at 02:31:47PM +0000, Chaim Sanders wrote: > >> Good writeup Christian! > >> > >> On 2/8/16, 2:59 AM, > >> "owasp-modsecurity-core-rule-set-boun...@lists.owasp.org on behalf of > >> Funk, Lukas" <owasp-modsecurity-core-rule-set-boun...@lists.owasp.org on > >> behalf of lukas.f...@united-security-providers.ch> wrote: > >> > >>> Hi Christian and all, > >>> > >>> I follow the discussion about the paranoia mode with great interest. I > >>> think it could be a good starting point for ModSecurity users which do > >>> not have the expert knowledge of the rules. > >>> > >>> Looking at your proposed structure of the paranoia mode setup, I think > >>> it's on a good track. The structure is easy to understand! > >>> Unfortunately I can't comment the different rules, as I don't have much > >>> experience with them. > >>> > >>> Thanks to all of you putting such great effort to the CRS and I'm really > >>> looking forward to version 3! > >>> > >>> Cheers, Lukas > >>> > >>> > >>>>> Dear all, > >>>>> > >>>>> With the progress we are making on the rules front, it is time to talk > >>>>> about > >>>>> the way it could be implemented. > >>>>> It's time for the show-me-the-code. He you go: > >>>>> > >>>>> > >>>>> http://scanmail.trustwave.com/?c=4062&d=tN-41hG4qCjBMKf0XEE90boFBx23NXMA > >>>>> 8kit7zcE9Q&s=5&u=https%3a%2f%2fwww%2enetnea%2ecom%2fcms%2f2016%2f02%2f04 > >>>>> %2fowasp-modsecurity-core-rules- > >>>>> paranoia-mode-mechanics-proposal/ > >>>>> > >>>>> Feedback welcome! > >>>>> > >>>>> Christian > >> > >> > >> ________________________________ > >> > >> This transmission may contain information that is privileged, > >> confidential, and/or exempt from disclosure under applicable law. If you > >> are not the intended recipient, you are hereby notified that any > >> disclosure, copying, distribution, or use of the information contained > >> herein (including any reliance thereon) is strictly prohibited. If you > >> received this transmission in error, please immediately contact the sender > >> and destroy the material in its entirety, whether in electronic or hard > >> copy format. > >> _______________________________________________ > >> 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 > > > > -- > > mailto:christian.fol...@netnea.com > > http://www.christian-folini.ch > > twitter: @ChrFolini > > _______________________________________________ > > 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 > > -- > 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 -- mailto:christian.fol...@netnea.com http://www.christian-folini.ch twitter: @ChrFolini _______________________________________________ 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
