Hi Christian, I’m absolutely interested in this. I’ve wanted to look at CRS v3, but I’ve been hesitant to try it, mostly because I actually like the paranoia of v2. I think it would be very good to facilitate both modes of operation:
1) General virtual hosting scenario where the admin doesn’t control the enduser webapps and doesn’t necessarily have high-level ModSecurity knowledge. You want to be conservative on false positives and you want very few knobs to tweak. If there is enough confidence that this would protect against almost all attacks, it should probably be the default in order to make the CRS more useful to more people. 2) Users who control the complete web app, have a good feedback loop/in-depth monitoring, and have the knowledge and processes to do good whitelisting of false positives. This is mostly my scenario and so I want the WAF to really be as strict as it possibly could be, and I’ll deal with the fallout. So I think this idea is awesome, maybe I can help some bit, let me know. Some notes: - An advantage of adding optional stricter rules, by keeping the CRS v2 SQL/XSS rules, is that they could possibly run earlier than the libinjection rules (including a blocking decision), and this might actually prevent bypasses or exploits against libinjection if you’re concerned about it, for example by blocking input that’s totally unreasonable. - I wouldn’t even call ‘2’ paranoia mode. I think of it more as “relaxed mode” and “strict mode”. I think this naming would motivate people more to experiment with the strict mode. I think it’s absolutely reasonable to run in this mode and people who know their apps and have the resources to babysit the WAF a bit should not be demotivated to try it. Cheers! WH > On 27 Dec 2015, at 09:45, Christian Folini <christian.fol...@netnea.com> > wrote: > > Dear all, > > Following discussions here on the list and my recent blogpost, > Chaim and I talked things through and I will develop a pull request > to introduce a paranoia mode into the core rule set. > > The paranoia mode will be enabled by setting a special variable, > which will then execute a bunch of additional rules for added security > but with the disadvantage of a higher rate of false positives when > left untuned. > > Some rules, which did not make the cut into the 3.0.0-dev tree, will > reappear in this setting as will some new rules. > > The details are not clear so far and a fair bunch of work still has > to be done. Therefore, I am looking to recruit 2-3 people who are > interested in this feature set. This is a nice task to dive deeper > into the inner workings of the core rules and it is an option to > help directing the development of the next major release. > > I am ok with working with core rule newbies, as long as you have a > basic unferstanding of ModSecurity. > > Please respond here or via private mail. > > Best, > > Christian Folini > > -- > If you have men who will only come if they know there is a good road, > I don't want them. I want men who will come if there is no road at all. > -- David Livingstone > _______________________________________________ > 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
