Re: [mod-security-users] ModSecurity phase timing

[Robert P. <rpa...@fe...>]

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.

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.

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?

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.

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/
>
>