Re: [mod-security-users] ModSecurity phase timing
Brought to you by:
victorhora,
zimmerletw
Menu
▾
▴
Re: [mod-security-users] ModSecurity phase timing
|
From: Felipe Z. <fe...@zi...> - 2018-03-27 23:22:11
|
Hi, On Tue, Mar 27, 2018 at 5:17 PM Robert Paprocki < rpa...@fe...> wrote: > It's encouraging to see this discussion taking place. A few observations, > as a member of the community who has not had time for significant > engagement in either the CRS or libmodsecurity projects in the last year or > so: > > First, https://github.com/SpiderLabs/ModSecurity/issues/1011 looks like a > placeholder card to mark that a feature has not been implemented. Up until > its closure in October 2017, there was no discussion or notation to > indicate that this feature *would not* be implemented. Indeed, most other > cards with this issue tag do not have any discussion, only a note that > indicating their completion, so there's nothing in this issue, apart from > an abrupt note and closure, that the community can reference that would > indicate that the feature will not make it into libmodsecurity. I don't > call seeing any solicitation from developers to the community about the > usefulness of PERF_*, and I don't think its reasonable to say that there > has been no community care about these variables until now, because the > card in question wasn't a call for discussion- it was a placeholder. So, > with all respect, it seems a little disingenuous to claim "no one cared > about this we're not going to support it"- from an outside observation, > there has *always* been an expectation that this feature would be > available someday. > I canot change your perspective, all I can tell is that there are members of this community that thinks otherwise, as the example of: https://github.com/SpiderLabs/ModSecurity/issues/1139 > Second, stap and friends simply are not an equivalent replacement for > PERF_*. For one, deploying and using systemtap isn't an option for > technical reasons. It is a complex, nuanced tool that takes substantial > effort to use, and trying to troubleshoot stap errors or malfunctions for > less-advanced users is, put lightly, a daunting task. Yes, having a working > set of systemtap scripts designed to introspect libmodsecurity is useful. > It's a wonderful opportunity. But comparing systemtap output and natively > integrated SecRules DSL is apples and oranges. PERF_* provides the ability > to extend and alter ruleset functionality; systemtap introspection is a > passive output. These are fundamentally different approaches. > The version 3 is a complete rewrite. The motivations are written here - https://www.trustwave.com/Resources/SpiderLabs-Blog/An-Overview-of-the-Upcoming-libModSecurity/ There are fundamental changes all around the place. All of them is meant to be for benefit of the user. Comparing v3 to v2 is kind compare a orange to an apple :) And I failed to see why the systemtap is not a replacement. Can you share with us your concerns? The performance was treatedd on the very first announcement altogether with SystemTap and others ideas there are new and change the way that the old ModSecurity works (v2). We don't want to loose performance unless it is extremely necessary. Also, there is always the v2. There is not point to make v3 equals to v2. Better use v2 instead don't you agree? Regarding the openresty-systemtap-toolkit, this is a wonderful repository > of examples and targeted scripts. It is a useful reference point, but it's > just that- a reference point. It is not actively maintained at this time, > and several of the scripts do not work with even modestly recent releases > of OpenResty. Certainly I mean no disrespect to agentzh (or Felipe!) here, > but simply pointing libmodsecurity users to this repo without further > instruction or discussion is not a useful answer, IMHO. > > Finally, and I'm sure I'm missing something here, but I fail to see the > substantial technical challenges in porting PERF_* to libmodsecurity. Yes, > stap can be a useful tool, and I think the community would love to see more > official stap scripts for libmodsecurity (I would love to have the time to > work on these myself!). But I just don't understand why implementing PERF_* > in v3 is a blocking problem. The v2 implementation is quite very simply, at > least for the combined and per-phase members ( > https://github.com/SpiderLabs/ModSecurity/blob/v2/master/apache2/re_variables.c#L1668-L1680). > @Felipe, would you consider a community-contributed implemention of PERF_* > for libmodsecurity? > Community contribution is always welcome in many aspects. If you are willing to add a feature that doesn't negatively impact ModSecurity and it's something that the fullfills the needs of the community (and not just one single user needs) you're more then welcome to submit a pull request and we will carefully evaluate it. As I mentioned the big loss is to report the numbers. Enable logging to measure performance does not sounds right. I/O is expensive, but there is no need for a discussion on this. The numbers can talk by itself. Again, I'm very encouraged by this discussion. It's good to see community > involvement and responses from Felipe. I look forward to continued > engagement on this. Cheers. > We are discussing stuff on Slack and on GitHub. We are in a very good momentum, I would like to invite all of you to join. Br., Felipe On Tue, Mar 27, 2018 at 6:01 AM, Felipe Zimmerle <fe...@zi...> > wrote: > >> Hi, >> >> On Tue, Mar 27, 2018 at 8:56 AM Christian Folini < >> chr...@ne...> wrote: >> >>> Hello Felipe, >>> >>> Thank you for your openness to discuss this on github in detail. Still, >>> I'd like to continue in this thread because it has already started and >>> because it interests a wider audience due of certain implications that >>> have to do with the way you handle our concerns. >>> >>> >> The issue is open for discussion on GitHub since "Dec 9, 2015" no one >> seems to care about till yesterday. On GitHub we have more audience and >> everything is indexed. Please use the 2015 issue to discuss this. >> >> In case you missed something: >> https://github.com/SpiderLabs/ModSecurity/issues/1011 >> >> >> On Mon, Mar 26, 2018 at 05:08:50PM +0000, Felipe Zimmerle wrote: >>> > I have no bug report saying that DURATION is not working and a >>> regression >>> > test that leads me to believe that it is working. Thus, I am assuming >>> that >>> > it is working Ok. >>> >>> Here is your new bug report: >>> >>> https://github.com/SpiderLabs/ModSecurity/issues/1725 >>> >>> >> That is a good way to work in a open source project. Report a bug that >> was found. Thank you in the name of the community. >> >> (...) >>> >> >> >>> I have just been commissioned to come up with a decent approach to do >>> performance analysis of existing services on libModSecurity / NGINX. >>> This is >>> great for me, because it means business. But it is bad for ModSecurity >>> because >>> people should be able to do this without Christian Folini coming up with >>> a >>> smart method. It should be easier than this (and it should be >>> documented!): >>> >>> >> There is a difference in between run ModSecurity and code ModSecurity. In >> the same way that there is a difference in create a script and run a >> script. We have published the script here: >> https://github.com/SpiderLabs/ModSecurity-nginx/commits/master/ngx-modsec.stp >> since 20 Sep 2015. We dind't charge nobody for it. The decision to ask >> for money is ours. >> >> Maybe the script is not in the shape that you like but it is working and >> 100% compatible with our current user base. May advice to you in to study >> the current proposed method before complain about it. There are huge >> advantages in this new approach. It is in fact a good thing for our users. >> Having said that, can you provide a solid argument pointing towards stap >> not be good? >> >> >>> The standard questions in such situations is: >>> - Which requests have a performance issue? >>> - Is the performance issue with ModSecurity or with the backend >>> application? >>> >>> >> Here you can find answers to all your questions: >> https://github.com/openresty/openresty-systemtap-toolkit >> >> >> With ModSecurity 2.9.2 this is easy to find out. See my tutorials >>> https://www.netnea.com/cms/apache-tutorial-5_extending-access-log/ >>> https://www.netnea.com/cms/apache-tutorial-6_embedding-modsecurity/ >>> that describe an access log format that brings this performance data for >>> every request and the ModSec rules necessary to fill the variables. >>> This settles 90% of all performance issues immediately. >>> >>> >> I understand that the new version outdated your tutorials, etc... I am >> sorry for that. >> >> >>> Now NGINX does not allow to display env variables easily in the access >>> log >>> and libModSecurity does not yet support env variables anyways. So I >>> assumed >>> I would have to take a different path. Now it looks like I would need to >>> write everything into the error log and _then_ calculate the timings >>> externally with a new tool / script that works with floating point >>> numbers. >>> >>> And additionally I will look into systemtap because you told us to do so >>> and because the example you give may be useful for experienced stap >>> users, >>> but it's beyond the knowledge level of the average ModSecurity user. >>> >>> >> It is just about execute a script. Nothing more. Still: >> >> a) The discussion from 2015 still open. I am not telling what to do. >> Happy users are using stap. >> b) The version 2.x is still maintained; If you don't want to learn >> something new, you can keep using v2. >> >> >>> I am sorry if this message is a bit rude. I usually try to remain calm >>> and >>> diplomatic. But this time, it did not work out and sleeping it over did >>> not work either. >>> >>> >> Feel free to share your feelings. >> >> >>> We are all together on this ModSecurity ship. You are the captain and you >>> steer the ship based on the decisions you think are best. The rest of the >>> community only notices the decision once the ship starts to turn. You >>> stated libModSecurity would be feature compatible to 2.9.x. Now we learn >>> it >>> is not and we have to make fundamental changes to our setups and >>> methodology. >>> >>> >> Like a said too many times: We started a discussion back in 2015. If you >> are part of this community, why I we didn't have a comment from you? >> >> >>> I am totally open for a discussion on the need for the PERF_ variables. >>> If they mean a performance hit, then tell us how much and tell us why you >>> think it is not acceptable. How is the libModSecurity 3.0 performance >>> stacking up against 2.9.x? Is it really so good, that you want to squeeze >>> out the last few cpu cycles to the very limit and PERF_ is the last >>> remaining target? >>> Having to calculate performance via arithemtics >>> and DURATION also has a performance hit, and maybe one could make the >>> PERF_ variables optional (compile time flag or directive that is off by >>> default). But please do not take these decisions silently and then brush >>> away our concerns. >>> >>> >> Since 2015: >> https://github.com/SpiderLabs/ModSecurity/issues/1011 >> >> Br., >> Felipe. >> >> >> >> ------------------------------------------------------------------------------ >> Check out the vibrant tech community on one of the world's most >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >> _______________________________________________ >> mod-security-users mailing list >> mod...@li... >> https://lists.sourceforge.net/lists/listinfo/mod-security-users >> Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs: >> http://www.modsecurity.org/projects/commercial/rules/ >> http://www.modsecurity.org/projects/commercial/support/ >> >> > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > mod-security-users mailing list > mod...@li... > https://lists.sourceforge.net/lists/listinfo/mod-security-users > Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs: > http://www.modsecurity.org/projects/commercial/rules/ > http://www.modsecurity.org/projects/commercial/support/ > |
