mod-security-users

[mod-security-users] ModSecurity phase timing

[Gregory L. <gr...@cl...>]

Hello,

Is access to phase timing known to work in ModSecurity 3.x with Nginx?

For example, should I be able to write a SecAction in phase:5 to
log PERF_PHASE2, or PERF_ALL, etc.?

I'm using an earlier version of Nginx, and I have such rules, and lines for
them do, in fact, show up in the log, but without the performance
information. For example, this (which I include in
RESPONSE-999-EXCLUSION-RULES-AFTER-CRS.conf):

SecAction "id:90110, phase:5, pass, t:none, log, noauditlog, msg:'PERF_ALL:
%{PERF_ALL}'"

shows up in the log as:

... [id "90110"] [rev ""] [msg "PERF_ALL: "] [data ""] [severity "0"] [ver
""] [maturity "0"] [accuracy "0"] ...

Just curious whether this should be considered possible now or whether
anyone already may have had success doing so.

Thank you,

Gregory

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

[Christian F. <chr...@ne...>]

Hi Gregory,

Including modsec-dev list in my response too.

On Tue, Mar 20, 2018 at 08:19:14PM -0700, Gregory LeFevre wrote:
> Is access to phase timing known to work in ModSecurity 3.x with Nginx?

No, I do not think it is. I did not give it a through testing, but I saw the
same you did and then I also noticed that event DURATION is ignored with
3.0.0.

Ahoj,

Christian


-- 
If you have men who will only come if they know there is a good road, 
I don't want them. I want men who will come if there is no road at all.
-- David Livingstone

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

[Felipe C. <FC...@tr...>]

Hi Gregory,

Indeed, the PERF_ related variables are not supported in v3. The reason for that is the fact that you can use linux instrumentation to measure those performance numbers with better accuracy. As the PERF generation itself was already impacting on the performance.

For further info, please have a look here: https://github.com/SpiderLabs/ModSecurity/issues/1011

Br.,
Felipe “Zimmerle” Costa
Security Researcher, Lead Developer ModSecurity.

Trustwave | SMART SECURITY ON DEMAND
www.trustwave.com<http://www.trustwave.com/>

From: Gregory LeFevre <gr...@cl...>
Reply-To: "mod...@li..." <mod...@li...>
Date: Wednesday, March 21, 2018 at 12:21 AM
To: "mod...@li..." <mod...@li...>
Subject: [mod-security-users] ModSecurity phase timing


Hello,

Is access to phase timing known to work in ModSecurity 3.x with Nginx?

For example, should I be able to write a SecAction in phase:5 to log PERF_PHASE2, or PERF_ALL, etc.?

I'm using an earlier version of Nginx, and I have such rules, and lines for them do, in fact, show up in the log, but without the performance information. For example, this (which I include in RESPONSE-999-EXCLUSION-RULES-AFTER-CRS.conf):

SecAction "id:90110, phase:5, pass, t:none, log, noauditlog, msg:'PERF_ALL: %{PERF_ALL}'"

shows up in the log as:

... [id "90110"] [rev ""] [msg "PERF_ALL: "] [data ""] [severity "0"] [ver ""] [maturity "0"] [accuracy "0"] ...

Just curious whether this should be considered possible now or whether anyone already may have had success doing so.

Thank you,

Gregory

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

[Christian F. <chr...@ne...>]

Hey Zimmerle,

That makes sense, but I think it does not hold up when you look closer.

Correct me if I am wrong, but correlating stap with an individual request
is much more difficult than saving the perf-data out of ModSec directly
into the access-log (Apache / ModSec 2.9) or error-log (NGINX / ModSec 3.0).

Also, I think the DURATION variable is not yet implemented in 3.0. Or did I
make a mistake when I found it was always empty?

Best,

Christian


On Fri, Mar 23, 2018 at 01:14:04PM +0000, Felipe Costa wrote:
> Hi Gregory,
> 
> Indeed, the PERF_ related variables are not supported in v3. The reason for that is the fact that you can use linux instrumentation to measure those performance numbers with better accuracy. As the PERF generation itself was already impacting on the performance.
> 
> For further info, please have a look here: https://github.com/SpiderLabs/ModSecurity/issues/1011
> 
> Br.,
> Felipe “Zimmerle” Costa
> Security Researcher, Lead Developer ModSecurity.
> 
> Trustwave | SMART SECURITY ON DEMAND
> www.trustwave.com<http://www.trustwave.com/>
> 
> From: Gregory LeFevre <gr...@cl...>
> Reply-To: "mod...@li..." <mod...@li...>
> Date: Wednesday, March 21, 2018 at 12:21 AM
> To: "mod...@li..." <mod...@li...>
> Subject: [mod-security-users] ModSecurity phase timing
> 
> 
> Hello,
> 
> Is access to phase timing known to work in ModSecurity 3.x with Nginx?
> 
> For example, should I be able to write a SecAction in phase:5 to log PERF_PHASE2, or PERF_ALL, etc.?
> 
> I'm using an earlier version of Nginx, and I have such rules, and lines for them do, in fact, show up in the log, but without the performance information. For example, this (which I include in RESPONSE-999-EXCLUSION-RULES-AFTER-CRS.conf):
> 
> SecAction "id:90110, phase:5, pass, t:none, log, noauditlog, msg:'PERF_ALL: %{PERF_ALL}'"
> 
> shows up in the log as:
> 
> ... [id "90110"] [rev ""] [msg "PERF_ALL: "] [data ""] [severity "0"] [ver ""] [maturity "0"] [accuracy "0"] ...
> 
> Just curious whether this should be considered possible now or whether anyone already may have had success doing so.
> 
> Thank you,
> 
> Gregory
> 

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


-- 
https://www.feistyduck.com/training/modsecurity-training-course
https://www.feistyduck.com/books/modsecurity-handbook/
mailto:chr...@ne...
twitter: @ChrFolini

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

[Felipe C. <FC...@tr...>]

Hi,





> On 3/23/18, 5:29 PM, "Christian Folini" <chr...@ne...> wrote:

>

>     Hey Zimmerle,

>

>     That makes sense, but I think it does not hold up when you look closer.

>



Why do you think so?





>    Correct me if I am wrong, but correlating stap with an individual request

>    is much more difficult than saving the perf-data out of ModSec directly

>    into the access-log (Apache / ModSec 2.9) or error-log (NGINX / ModSec 3.0).

IMHO it is easy as there is no file to be parsed.



(…)





Br.,

Felipe “Zimmerle” Costa

Security Researcher, Lead Developer ModSecurity.

Trustwave | SMART SECURITY ON DEMAND

www.trustwave.com <http://www.trustwave.com/>

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

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

Yes but how do you correlate this to a specific, known request?

And what is to be done with rulesets that rely on phase timing data? Are they unsupported forever?


> On Mar 26, 2018, at 08:52, Felipe Costa <FC...@tr...> wrote:
> 
> Hi,
>  
>  
> > On 3/23/18, 5:29 PM, "Christian Folini" <chr...@ne...> wrote:
> > 
> >     Hey Zimmerle,
> >    
> >     That makes sense, but I think it does not hold up when you look closer.
> >
>  
> Why do you think so?
>  
>  
> >    Correct me if I am wrong, but correlating stap with an individual request
> >    is much more difficult than saving the perf-data out of ModSec directly
> >    into the access-log (Apache / ModSec 2.9) or error-log (NGINX / ModSec 3.0).
> 
> IMHO it is easy as there is no file to be parsed.
>     
> (…)
>  
>  
> Br.,
> Felipe “Zimmerle” Costa
> Security Researcher, Lead Developer ModSecurity.
> Trustwave | SMART SECURITY ON DEMAND
> www.trustwave.com <http://www.trustwave.com/>
>  
> ------------------------------------------------------------------------------
> 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/

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

[Felipe Z. <fe...@zi...>]

Hi,

https://github.com/SpiderLabs/ModSecurity/blob/v3/master/headers/modsecurity/transaction.h#L481-L485

Contains the id of the transaction along all the information that you may
need to know about it.

There are other means to read "timing", no need to use performance
variables for that.
https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual#DURATION

Br.,
Felipe.



On Mon, Mar 26, 2018 at 1:16 PM Robert Paprocki <
rpa...@fe...> wrote:

> Yes but how do you correlate this to a specific, known request?
>
> And what is to be done with rulesets that rely on phase timing data? Are
> they unsupported forever?
>
>
> On Mar 26, 2018, at 08:52, Felipe Costa <FC...@tr...> wrote:
>
> Hi,
>
>
>
>
>
> > On 3/23/18, 5:29 PM, "Christian Folini" <chr...@ne...>
> wrote:
>
> >
>
> >     Hey Zimmerle,
>
> >
>
> >     That makes sense, but I think it does not hold up when you look
> closer.
>
> >
>
>
>
> Why do you think so?
>
>
>
>
>
> >    Correct me if I am wrong, but correlating stap with an individual
> request
>
> >    is much more difficult than saving the perf-data out of ModSec
> directly
>
> >    into the access-log (Apache / ModSec 2.9) or error-log (NGINX /
> ModSec 3.0).
>
>
> IMHO it is easy as there is no file to be parsed.
>
>
>
> (…)
>
>
>
>
>
> Br.,
>
> Felipe “Zimmerle” Costa
>
> Security Researcher, Lead Developer ModSecurity.
>
> Trustwave | SMART SECURITY ON DEMAND
>
> www.trustwave.com <http://www.trustwave.com/>
>
>
>
>
> ------------------------------------------------------------------------------
> 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/
>

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

[Christian F. <chr...@ne...>]

Hey Felipe,

On Mon, Mar 26, 2018 at 04:45:41PM +0000, Felipe Zimmerle wrote:
> There are other means to read "timing", no need to use performance
> variables for that.
> https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual#DURATION

Does DURATION really work in 3.0 / nginx?

If that is granted, I can live with it. But digging into header-Files and
running external scripts (separate process!) because I want to get a 
Performance overview is quite demanding I think.

Christian

-- 
History allows us to see human nature in a deeper way.
-- Ian Mortimer

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

[Felipe Z. <fe...@zi...>]

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.

Indeed, running a shell script may be hard for a group of users, but i
don't think that it is a motivation to have poor optimization for all users.

Br.,
Felipe.




On Mon, Mar 26, 2018 at 1:51 PM Christian Folini <
chr...@ne...> wrote:

> Hey Felipe,
>
> On Mon, Mar 26, 2018 at 04:45:41PM +0000, Felipe Zimmerle wrote:
> > There are other means to read "timing", no need to use performance
> > variables for that.
> > https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual#DURATION
>
> Does DURATION really work in 3.0 / nginx?
>
> If that is granted, I can live with it. But digging into header-Files and
> running external scripts (separate process!) because I want to get a
> Performance overview is quite demanding I think.
>
> Christian
>
> --
> History allows us to see human nature in a deeper way.
> -- Ian Mortimer
>
>
> ------------------------------------------------------------------------------
> 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/
>

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

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

I think the point we are making is that _native_ integration of perf data
is what's missing. systemtap scripts are useful, but they are definitely
not a replacement. there are a multitude of environments where its simply
not possible to use such tooling.

And, I'm curious, why is it so expensive to generate this data? Could it
not be something as simple as a delta between two timespecs?

On Mon, Mar 26, 2018 at 10:08 AM, Felipe Zimmerle <fe...@zi...>
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.
>
> Indeed, running a shell script may be hard for a group of users, but i
> don't think that it is a motivation to have poor optimization for all users.
>
> Br.,
> Felipe.
>
>
>
>
> On Mon, Mar 26, 2018 at 1:51 PM Christian Folini <
> chr...@ne...> wrote:
>
>> Hey Felipe,
>>
>> On Mon, Mar 26, 2018 at 04:45:41PM +0000, Felipe Zimmerle wrote:
>> > There are other means to read "timing", no need to use performance
>> > variables for that.
>> > https://github.com/SpiderLabs/ModSecurity/wiki/Reference-
>> Manual#DURATION
>>
>> Does DURATION really work in 3.0 / nginx?
>>
>> If that is granted, I can live with it. But digging into header-Files and
>> running external scripts (separate process!) because I want to get a
>> Performance overview is quite demanding I think.
>>
>> Christian
>>
>> --
>> History allows us to see human nature in a deeper way.
>> -- Ian Mortimer
>>
>> ------------------------------------------------------------
>> ------------------
>> 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/
>
>

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

[Felipe Z. <fe...@zi...>]

Lets have a discussion about that on the issue on GitHub, so we can keep
that info in a fashion that everybody can easily read and follow. There is
a bug no GitHub already for that.

in the meanwhile you can collect this interesting data to share with us. I
am curious. I don't understand why you want to compute the subtraction and
not showing or saving anywhere, if there is no saving/storing what is the
point to compute in first place?

Br.,
Felipe


On Mon, Mar 26, 2018 at 2:46 PM Robert Paprocki <
rpa...@fe...> wrote:

> I think the point we are making is that _native_ integration of perf data
> is what's missing. systemtap scripts are useful, but they are definitely
> not a replacement. there are a multitude of environments where its simply
> not possible to use such tooling.
>
> And, I'm curious, why is it so expensive to generate this data? Could it
> not be something as simple as a delta between two timespecs?
>
> On Mon, Mar 26, 2018 at 10:08 AM, Felipe Zimmerle <fe...@zi...>
> 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.
>>
>> Indeed, running a shell script may be hard for a group of users, but i
>> don't think that it is a motivation to have poor optimization for all users.
>>
>> Br.,
>> Felipe.
>>
>>
>>
>>
>> On Mon, Mar 26, 2018 at 1:51 PM Christian Folini <
>> chr...@ne...> wrote:
>>
>>> Hey Felipe,
>>>
>>> On Mon, Mar 26, 2018 at 04:45:41PM +0000, Felipe Zimmerle wrote:
>>> > There are other means to read "timing", no need to use performance
>>> > variables for that.
>>> >
>>> https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual#DURATION
>>>
>>> Does DURATION really work in 3.0 / nginx?
>>>
>>> If that is granted, I can live with it. But digging into header-Files and
>>> running external scripts (separate process!) because I want to get a
>>> Performance overview is quite demanding I think.
>>>
>>> Christian
>>>
>>> --
>>> History allows us to see human nature in a deeper way.
>>> -- Ian Mortimer
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> 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/
>>
>>
>
> ------------------------------------------------------------------------------
> 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/
>

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

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

Sounds good, I will compile some use cases and previous implementations and
post them on GH. Thanks :)

On Mon, Mar 26, 2018 at 11:05 AM, Felipe Zimmerle <fe...@zi...>
wrote:

> Lets have a discussion about that on the issue on GitHub, so we can keep
> that info in a fashion that everybody can easily read and follow. There is
> a bug no GitHub already for that.
>
> in the meanwhile you can collect this interesting data to share with us. I
> am curious. I don't understand why you want to compute the subtraction and
> not showing or saving anywhere, if there is no saving/storing what is the
> point to compute in first place?
>
> Br.,
> Felipe
>
>
> On Mon, Mar 26, 2018 at 2:46 PM Robert Paprocki <rpaprocki@
> fearnothingproductions.net> wrote:
>
>> I think the point we are making is that _native_ integration of perf data
>> is what's missing. systemtap scripts are useful, but they are definitely
>> not a replacement. there are a multitude of environments where its simply
>> not possible to use such tooling.
>>
>> And, I'm curious, why is it so expensive to generate this data? Could it
>> not be something as simple as a delta between two timespecs?
>>
>> On Mon, Mar 26, 2018 at 10:08 AM, Felipe Zimmerle <fe...@zi...>
>> 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.
>>>
>>> Indeed, running a shell script may be hard for a group of users, but i
>>> don't think that it is a motivation to have poor optimization for all users.
>>>
>>> Br.,
>>> Felipe.
>>>
>>>
>>>
>>>
>>> On Mon, Mar 26, 2018 at 1:51 PM Christian Folini <
>>> chr...@ne...> wrote:
>>>
>>>> Hey Felipe,
>>>>
>>>> On Mon, Mar 26, 2018 at 04:45:41PM +0000, Felipe Zimmerle wrote:
>>>> > There are other means to read "timing", no need to use performance
>>>> > variables for that.
>>>> > https://github.com/SpiderLabs/ModSecurity/wiki/Reference-
>>>> Manual#DURATION
>>>>
>>>> Does DURATION really work in 3.0 / nginx?
>>>>
>>>> If that is granted, I can live with it. But digging into header-Files
>>>> and
>>>> running external scripts (separate process!) because I want to get a
>>>> Performance overview is quite demanding I think.
>>>>
>>>> Christian
>>>>
>>>> --
>>>> History allows us to see human nature in a deeper way.
>>>> -- Ian Mortimer
>>>>
>>>> ------------------------------------------------------------
>>>> ------------------
>>>> 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/
>>>
>>>
>> ------------------------------------------------------------
>> ------------------
>> 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/
>>
>

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

[Felipe Z. <fe...@zi...>]

Great, thanks!

On Mon, Mar 26, 2018 at 3:11 PM Robert Paprocki <
rpa...@fe...> wrote:

> Sounds good, I will compile some use cases and previous implementations
> and post them on GH. Thanks :)
>
> On Mon, Mar 26, 2018 at 11:05 AM, Felipe Zimmerle <fe...@zi...>
> wrote:
>
>> Lets have a discussion about that on the issue on GitHub, so we can keep
>> that info in a fashion that everybody can easily read and follow. There is
>> a bug no GitHub already for that.
>>
>> in the meanwhile you can collect this interesting data to share with us.
>> I am curious. I don't understand why you want to compute the subtraction
>> and not showing or saving anywhere, if there is no saving/storing what is
>> the point to compute in first place?
>>
>> Br.,
>> Felipe
>>
>>
>> On Mon, Mar 26, 2018 at 2:46 PM Robert Paprocki <
>> rpa...@fe...> wrote:
>>
>>> I think the point we are making is that _native_ integration of perf
>>> data is what's missing. systemtap scripts are useful, but they are
>>> definitely not a replacement. there are a multitude of environments where
>>> its simply not possible to use such tooling.
>>>
>>> And, I'm curious, why is it so expensive to generate this data? Could it
>>> not be something as simple as a delta between two timespecs?
>>>
>>> On Mon, Mar 26, 2018 at 10:08 AM, Felipe Zimmerle <fe...@zi...>
>>> 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.
>>>>
>>>> Indeed, running a shell script may be hard for a group of users, but i
>>>> don't think that it is a motivation to have poor optimization for all users.
>>>>
>>>> Br.,
>>>> Felipe.
>>>>
>>>>
>>>>
>>>>
>>>> On Mon, Mar 26, 2018 at 1:51 PM Christian Folini <
>>>> chr...@ne...> wrote:
>>>>
>>>>> Hey Felipe,
>>>>>
>>>>> On Mon, Mar 26, 2018 at 04:45:41PM +0000, Felipe Zimmerle wrote:
>>>>> > There are other means to read "timing", no need to use performance
>>>>> > variables for that.
>>>>> >
>>>>> https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual#DURATION
>>>>>
>>>>> Does DURATION really work in 3.0 / nginx?
>>>>>
>>>>> If that is granted, I can live with it. But digging into header-Files
>>>>> and
>>>>> running external scripts (separate process!) because I want to get a
>>>>> Performance overview is quite demanding I think.
>>>>>
>>>>> Christian
>>>>>
>>>>> --
>>>>> History allows us to see human nature in a deeper way.
>>>>> -- Ian Mortimer
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> 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/
>>>>
>>>>
>>>
>>> ------------------------------------------------------------------------------
>>> 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/
>>>
>>
>

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

[Christian F. <chr...@ne...>]

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.

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

TL&DR; DURATION kind of works, but DURATION macro expansion does not work in
msg and logdata context and the value of variable is not correct according to
description in reference handbook at
https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual#DURATION 
You are returning a float, while DURATION is described to be microseconds.

The float is a real issue. You dropped the PERF_ variables for 3.0 and
told us yesterday to work with DURATION. That means to calculate phase timings
by doing arithmetics based on interim values of DURATION. 
But now it turns out that this path is barred because ModSec arithmetics only 
works with integer numbers (-> microseconds!) but not with floats.

So again, we are stuck with a non-working implementation.

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!):

The standard questions in such situations is:
- Which requests have a performance issue?
- Is the performance issue with ModSecurity or with the backend application?

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.

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.

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.

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.

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.

Best regards,

Christian


-- 
Life would be tragic if it weren't funny. ... My expectations were
reduced to zero when I was 21. Everything since then has been a bonus.
-- Stephen Hawking

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

[Felipe Z. <fe...@zi...>]

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.

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

[Christian F. <chr...@ne...>]

Hello Felipe,

You make it seem as if I did not do my job. I think that is unjust. 

But I also realize that I did a bad job with the wording of my message.
Meanwhile Robert did a very good job with his response. So I am leaving this
discussion.

Ahoj,

Christian



On Tue, Mar 27, 2018 at 01:01:56PM +0000, Felipe Zimmerle 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/


-- 
https://www.feistyduck.com/training/modsecurity-training-course
https://www.feistyduck.com/books/modsecurity-handbook/
mailto:chr...@ne...
twitter: @ChrFolini

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

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

[Felipe Z. <fe...@zi...>]

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