mod-security-users — General discussion about mod_security

Re: [mod-security-users] Different behaviour between SecRuleEngine "On" and "DetectionOnly"

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

Hey Marco,

Thank you for reporting back. Glad you solved the problem and nice to hear
you are using CRS3.

Cheers,

Christian

On Fri, Apr 06, 2018 at 08:16:22PM +0200, Marco Pizzoli wrote:
> Hi Christian,
> 
> On Fri, Apr 6, 2018 at 4:46 PM, Christian Folini <
> chr...@ne...> wrote:
> 
> > Hey Marco,
> >
> > Good to read you here.
> >
> 
> :-)
> 
> What rule set are you using?
> >
> 
> CRS 3
> 
> 
> > But regardless of the ruleset, I think you should run a full traffic log
> > and try to reproduce the request getting a 403. If the error- and the
> > audit-log is not telling you anything, the ModSec DebugLog will.
> >
> 
> You will not believe it, but even with this simple answer I managed to find
> the culprit!
> One of my modsec rules stupidly (and hiddenly) blocking the request.
> Missing "pass" in the rule, so inheriting the SecDefaultAction... block! :-/
> 
> Sorry for the noise, I will be paying more attention in the future... be
> assured...
> 
> Thank you very much
> Marco
> 
> 
> 
> Unless it's not ModSecurity interfering.
> >
> > My 2 cents,
> >
> > Christian
> >
> > On Fri, Apr 06, 2018 at 04:36:11PM +0200, Marco Pizzoli wrote:
> > > Hi all,
> > > we are using Apache 2.4.x with ModSec 2.9.2 proxying Outlook Web Access
> > > 2016.
> > >
> > > I ran for a while in DetectionOnly, so whitelisting every necessary rule.
> > > When I switched to "On" (block), I started getting issues.
> > >
> > > During the first request the backend system answers with 401, and
> > providing
> > > 3 WWW-Authenticate headers:
> > > WWW-Authenticate: Basic realm="myhostname.mydomain"
> > > WWW-Authenticate: Negotiate
> > > WWW-Authenticate: NTLM
> > >
> > > During the following request Apache directly answers 403 without proxying
> > > the request to the backend... nor logging anything useful.
> > >
> > > I don't understand how the switching from "DetectionOnly" to "On" could
> > > interfere with the processing without logging anything.
> > >
> > > I ask you what are the undocumented settings that are changed under the
> > > hood together with that configuration switch...
> > >
> > > Thank you in advance
> > > Marco
> >
> > > ------------------------------------------------------------
> > ------------------
> > > 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
> >
> > ------------------------------------------------------------
> > ------------------
> > 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/


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

Re: [mod-security-users] Different behaviour between SecRuleEngine "On" and "DetectionOnly"

[Marco P. <mar...@gm...>]

Hi Christian,

On Fri, Apr 6, 2018 at 4:46 PM, Christian Folini <
chr...@ne...> wrote:

> Hey Marco,
>
> Good to read you here.
>

:-)

What rule set are you using?
>

CRS 3


> But regardless of the ruleset, I think you should run a full traffic log
> and try to reproduce the request getting a 403. If the error- and the
> audit-log is not telling you anything, the ModSec DebugLog will.
>

You will not believe it, but even with this simple answer I managed to find
the culprit!
One of my modsec rules stupidly (and hiddenly) blocking the request.
Missing "pass" in the rule, so inheriting the SecDefaultAction... block! :-/

Sorry for the noise, I will be paying more attention in the future... be
assured...

Thank you very much
Marco



Unless it's not ModSecurity interfering.
>
> My 2 cents,
>
> Christian
>
> On Fri, Apr 06, 2018 at 04:36:11PM +0200, Marco Pizzoli wrote:
> > Hi all,
> > we are using Apache 2.4.x with ModSec 2.9.2 proxying Outlook Web Access
> > 2016.
> >
> > I ran for a while in DetectionOnly, so whitelisting every necessary rule.
> > When I switched to "On" (block), I started getting issues.
> >
> > During the first request the backend system answers with 401, and
> providing
> > 3 WWW-Authenticate headers:
> > WWW-Authenticate: Basic realm="myhostname.mydomain"
> > WWW-Authenticate: Negotiate
> > WWW-Authenticate: NTLM
> >
> > During the following request Apache directly answers 403 without proxying
> > the request to the backend... nor logging anything useful.
> >
> > I don't understand how the switching from "DetectionOnly" to "On" could
> > interfere with the processing without logging anything.
> >
> > I ask you what are the undocumented settings that are changed under the
> > hood together with that configuration switch...
> >
> > Thank you in advance
> > Marco
>
> > ------------------------------------------------------------
> ------------------
> > 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
>
> ------------------------------------------------------------
> ------------------
> 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] Bad Performance of ModSecurity 3.0 (was: [Mod-security-users] ModSecurity version 3.0.1 announcement)

[Chaim S. <ch...@ch...>]

Guys please remember to be civil. Although I know your intention is to get
better performance numbers and improvement, remember that there are a lot
of factors going into development of v3. Try to look at the feedback you're
giving from Felipe's perspective, it does appear to be slightly aggressive
in nature. Just remember that our goal as a whole community is to produce
awesome work.

On Fri, Apr 6, 2018, 12:51 PM Robert Paprocki <
rpa...@fe...> wrote:

> Hi,
>
> On Fri, Apr 6, 2018 at 7:05 AM, Felipe Zimmerle <fe...@zi...>
> wrote:
>
>>
>> Hi,
>> [ ... ]
>>
>> I would suggest you to work an real use case. Using a real environment.
>> As you said, testing in the loop back is not good thing.
>>
>
> Felipe, with all respect I think you should go into politics :D This is a
> disingenuous non-answer. Are you saying that you'd expect to see _better_
> performance in a more complex environment? That's clearly not the goal
> here. We're not trying to simulate a realistic production workload. We're
> profiling the performance specifically of libmodsecurity. Removing
> variables induced by network connections, additional applications, etc.,
> provides _more_ reliable results when examining libmodsecurity's
> performance and behavior. And Andrei's own work and results align very
> closely with ours. Are you saying his data is unreliable as well? What
> variables do you suggest we adjust to better highlight libmodsecurity's
> performance? From what I can tell, lightweight benchmarks have clearly
> shown a behavior change based on the libmodsecurity configuration, and
> flame graphs have highlighted hot code paths that need
> optimization/refactoring. I'm not sure what more you'd like to see.
>
> I have taken the liberty of opening a few tracking issues on GitHub, since
> discussion here is going nowhere:
>
> https://github.com/SpiderLabs/ModSecurity/issues/1731
> https://github.com/SpiderLabs/ModSecurity/issues/1732
>
>
> I want to highlight that I don't think Christian or I are trying to
> sandbag anyone. But this discussion has been rather frustrating; from our
> perspective, we've provided real numbers and done benchmarking/profiling
> with modern tooling, and that data has aligned with what Andrei (who works
> for Nginx) has shown as well. And apart from vague answers like
> "performance is a very import subject which will always be discussed",
> there's been no response even acknowledging that our results are
> meaningful, or that our expectations about performance and latency are
> valid. I understand that Trustwave has it's own priorities (Felipe blink
> twice if they won't let you make performance improvements ;) ), but this
> really feels like a show-stopper for deploying at any meaningful scale. At
> this point I really don't know how to proceed. If I'm completely off-base
> then please let me know.
>
> ------------------------------------------------------------------------------
> 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] Bad Performance of ModSecurity 3.0 (was: [Mod-security-users] ModSecurity version 3.0.1 announcement)

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

Hi,

On Fri, Apr 6, 2018 at 7:05 AM, Felipe Zimmerle <fe...@zi...> wrote:

>
> Hi,
> [ ... ]
>
> I would suggest you to work an real use case. Using a real environment. As
> you said, testing in the loop back is not good thing.
>

Felipe, with all respect I think you should go into politics :D This is a
disingenuous non-answer. Are you saying that you'd expect to see _better_
performance in a more complex environment? That's clearly not the goal
here. We're not trying to simulate a realistic production workload. We're
profiling the performance specifically of libmodsecurity. Removing
variables induced by network connections, additional applications, etc.,
provides _more_ reliable results when examining libmodsecurity's
performance and behavior. And Andrei's own work and results align very
closely with ours. Are you saying his data is unreliable as well? What
variables do you suggest we adjust to better highlight libmodsecurity's
performance? From what I can tell, lightweight benchmarks have clearly
shown a behavior change based on the libmodsecurity configuration, and
flame graphs have highlighted hot code paths that need
optimization/refactoring. I'm not sure what more you'd like to see.

I have taken the liberty of opening a few tracking issues on GitHub, since
discussion here is going nowhere:

https://github.com/SpiderLabs/ModSecurity/issues/1731
https://github.com/SpiderLabs/ModSecurity/issues/1732


I want to highlight that I don't think Christian or I are trying to sandbag
anyone. But this discussion has been rather frustrating; from our
perspective, we've provided real numbers and done benchmarking/profiling
with modern tooling, and that data has aligned with what Andrei (who works
for Nginx) has shown as well. And apart from vague answers like
"performance is a very import subject which will always be discussed",
there's been no response even acknowledging that our results are
meaningful, or that our expectations about performance and latency are
valid. I understand that Trustwave has it's own priorities (Felipe blink
twice if they won't let you make performance improvements ;) ), but this
really feels like a show-stopper for deploying at any meaningful scale. At
this point I really don't know how to proceed. If I'm completely off-base
then please let me know.

Re: [mod-security-users] Different behaviour between SecRuleEngine "On" and "DetectionOnly"

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

Hey Marco,

Good to read you here.

What rule set are you using?

But regardless of the ruleset, I think you should run a full traffic log
and try to reproduce the request getting a 403. If the error- and the
audit-log is not telling you anything, the ModSec DebugLog will.

Unless it's not ModSecurity interfering.

My 2 cents,

Christian

On Fri, Apr 06, 2018 at 04:36:11PM +0200, Marco Pizzoli wrote:
> Hi all,
> we are using Apache 2.4.x with ModSec 2.9.2 proxying Outlook Web Access
> 2016.
> 
> I ran for a while in DetectionOnly, so whitelisting every necessary rule.
> When I switched to "On" (block), I started getting issues.
> 
> During the first request the backend system answers with 401, and providing
> 3 WWW-Authenticate headers:
> WWW-Authenticate: Basic realm="myhostname.mydomain"
> WWW-Authenticate: Negotiate
> WWW-Authenticate: NTLM
> 
> During the following request Apache directly answers 403 without proxying
> the request to the backend... nor logging anything useful.
> 
> I don't understand how the switching from "DetectionOnly" to "On" could
> interfere with the processing without logging anything.
> 
> I ask you what are the undocumented settings that are changed under the
> hood together with that configuration switch...
> 
> Thank you in advance
> Marco

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

[mod-security-users] Different behaviour between SecRuleEngine "On" and "DetectionOnly"

[Marco P. <mar...@gm...>]

Hi all,
we are using Apache 2.4.x with ModSec 2.9.2 proxying Outlook Web Access
2016.

I ran for a while in DetectionOnly, so whitelisting every necessary rule.
When I switched to "On" (block), I started getting issues.

During the first request the backend system answers with 401, and providing
3 WWW-Authenticate headers:
WWW-Authenticate: Basic realm="myhostname.mydomain"
WWW-Authenticate: Negotiate
WWW-Authenticate: NTLM

During the following request Apache directly answers 403 without proxying
the request to the backend... nor logging anything useful.

I don't understand how the switching from "DetectionOnly" to "On" could
interfere with the processing without logging anything.

I ask you what are the undocumented settings that are changed under the
hood together with that configuration switch...

Thank you in advance
Marco

Re: [mod-security-users] Bad Performance of ModSecurity 3.0 (was: [Mod-security-users] ModSecurity version 3.0.1 announcement)

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

Hi,

On Fri, Apr 6, 2018 at 8:07 AM Christian Folini <chr...@ne...>
wrote:

> Dear all, dear Felipe,
>
> On Thu, Apr 05, 2018 at 06:28:06PM +0000, Felipe Zimmerle wrote:
> >
> > I cannot foresee how my priorities have to do with this thread :D :)
> >

No, your past and your future priorities matter a big deal.
>
>
I said that the thread does not reflect my priorities, not otherwise.


> Various people have presented numbers about the performance of ModSec3 and
> the
> data does not look good.
>
> I continued my measurements and arrived with the following results:
>
> Apache, no ModSec2            :  5490 requests per second
>
> Apache, ModSec2, 1 rule       :  4588   - 15% (against naked webserver)
> Apache, ModSec2, 10 rules     :  4329   - 20%
> Apache, ModSec2, CRS3         :  1123   - 79%
>
> NGINX, no ModSec3             : 10104 requests per second
>
> NGINX, ModSec3.0.0, 1 rule    :  4619   - 54% (against naked webserver)
> NGINX, ModSec3.0.0, 10 rules  :  3380   - 66%
> NGINX, ModSec3.0.0, CRS3      :    36   - 99%
>
> NGINX, ModSec3.0.2,  1 rule   :  4168   - 58%
> NGINX, ModSec3.0.2, 10 rules  :  3251   - 67%
> NGINX, ModSec3.0.2, CRS3      :   255   - 97%
>
> Parameters:
> 100000 reqs: http://localhost/index.html?test=test
> 3 test runs, I took the mean of the three runs.
> Testrule used (1 time or 10 times in succession):
> SecRule REQUEST_URI "@unconditionalMatch"
> "id:1,phase:1,pass,nolog,noauditlog"
>
> [For those not familiar with ModSec Performance. The numbers look already
> quite bad on Apache but that's because we are testing locally. Over the
> net,
> the numbers for ModSec2 are acceptable.]
>
>
>
> The takeaway message of the statistic above is this:
>
> ModSec3 has a huge overhead and every additional rule makes it worse.
>
>
>
> This confirms previous messages in this discussion. Namely those of Robert.
>
> And all these confirmations contradict your words when you announced 3.0 at
>
> https://www.trustwave.com/Resources/SpiderLabs-Blog/ModSecurity-Version-3-0-Announcement/
> There you wrote: "This release represents a significant improvement to the
> ModSecurity WAF. It removes dependencies and improves performance."
>
> I knew this was only wishful thinking when ModSec3 came out, but I did not
> want to badmouth your work Felipe. So I waited for 3.0.1 and hoped for
> performance improvements.  The improvements are significant (what I
> immediately reported). Unfortunately the performance is still miles
> away from what I would expect from ModSec3 on NGINX.
>
> So on April 3, I asked about your view on future performance improvements
> and
> a possible timeline. I think that is a reasonable thing to ask.
> You did not respond, though, and when Robert pointed out where he
> sees room for substantial improvements you invited him to refactor central
> aspects of your code by himself.



>
>
We agree that it is not your job to do all the work. But please, at least
> come
> up with a plan how we can all solve this together. It's the least thing
> that we expect from a leader.
>
> I interpret your communication here as a denial of any substantial
> problem. You are the lead developer. If you do not acknowledge
> the problem and if you do not present a plan to the community how
> this problem will be fixed, then you are hurting ModSecurity.
>
>
I would suggest you to work an real use case. Using a real environment. As
you said, testing in the loop back is not good thing.


> And that's why your and Trustwave's priorities matter a big deal.
>
> Best regards,
>
> Christian Folini
>
> --
> Author of the ModSecurity Handbook, 2ed
> Author of a series of ModSecurity tutorials published at
> https://netnea.com
> Renown teacher and frequent speaker on ModSecurity topics
>
>
> ------------------------------------------------------------------------------
> 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/



Br.,
Felipe.

Re: [mod-security-users] ruleRemoveTargetByTag - am I misunderstanding how it works?

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

Yes, too bad. That would have been an elegant solution.

The coverage for macro expansion has always been punctual in ModSecurity.
I wish it was consistent and universal.

See https://github.com/SpiderLabs/ModSecurity/issues/1725
for another example.

Ahoj,

Christian

On Fri, Apr 06, 2018 at 02:45:43PM +0200, Eirik Øverby - ModSecurity wrote:
> Hi,
> 
> I'm on 3.0.2 with nginx - and I get this from modsec-rules-check:
> Expecting an action, got:  %{MATCHED_VAR_NAME},\
> 
> I think the above is enough to see that it doesn't work :)
> 
> /Eirik
> 
> > On 6 Apr 2018, at 14:40, Christian Folini <chr...@ne...> wrote:
> > 
> > Hey Eirik,
> > 
> > If it works, it would be "...attack-sqli;%{MATCHED_VAR_NAME}". I doubt this
> > works, but I have been proved wrong on Monday night with a similar question,
> > so don't trust me too much.
> > 
> > ModSec2.9 is quite talkative on DebugLogLevel 9, so you should be able to
> > tell if it worked based on the logfile.
> > 
> > Ahoj,
> > 
> > Christian
> > 
> > 
> > On Fri, Apr 06, 2018 at 02:28:09PM +0200, Eirik Øverby - ModSecurity wrote:
> >> Hi again,
> >> 
> >>> On 5 Apr 2018, at 21:19, Eirik Øverby - ModSecurity <ltn...@an...> wrote:
> >>>> SecRule REQUEST_URI "@beginsWith /mdpayacs/pareq" \
> >>>>  "phase:1,id:1003,t:none,pass,nolog,chain,\
> >>>>      ctl:ruleRemoveTargetByTag=attack-sqli;ARGS:TermURL,\
> >>>>      ctl:ruleRemoveTargetByTag=attack-rce;ARGS:TermURL,\
> >>>>      ctl:ruleRemoveTargetByTag=attack-xss;ARGS:TermURL"
> >>>>          SecRule ARGS:TermURL "@beginsWith http" "t:none"
> >>> 
> >>> before anyone comments - yes, I modified this to say phase:2 - does not make any difference..
> >> 
> >> The error, as it turned out, was that mod_security matches argument names in a case-sesnitive fashion, but our application does not. The TermURL parameter is sent to us from many different sources, with various degrees of CamelCasing and CAPItaliSation.
> >> 
> >> Question: Can I use e.g. MATCHED_VAR_NAME as argument to ruleRemoteTargetBy*? For example
> >>  SecRule ARGS:/[Vv][Aa][Rr]/ "foo" "...... ctl:ruleRemoveTargetByTag=attack-sqli;MATCHED_VAR_NAME"
> >> 
> >> I have tried this, with no success so far - also with ARGS: prefix to MATCHED_VAR_NAME. I've also tried to use it in a chained rule.
> >> 
> >> /Eirik
> >> ------------------------------------------------------------------------------
> >> 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
> > 
> > ------------------------------------------------------------------------------
> > 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/


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

Re: [mod-security-users] ruleRemoveTargetByTag - am I misunderstanding how it works?

[Eirik Ø. - M. <ltn...@an...>]

Hi,

I'm on 3.0.2 with nginx - and I get this from modsec-rules-check:
Expecting an action, got:  %{MATCHED_VAR_NAME},\

I think the above is enough to see that it doesn't work :)

/Eirik

> On 6 Apr 2018, at 14:40, Christian Folini <chr...@ne...> wrote:
> 
> Hey Eirik,
> 
> If it works, it would be "...attack-sqli;%{MATCHED_VAR_NAME}". I doubt this
> works, but I have been proved wrong on Monday night with a similar question,
> so don't trust me too much.
> 
> ModSec2.9 is quite talkative on DebugLogLevel 9, so you should be able to
> tell if it worked based on the logfile.
> 
> Ahoj,
> 
> Christian
> 
> 
> On Fri, Apr 06, 2018 at 02:28:09PM +0200, Eirik Øverby - ModSecurity wrote:
>> Hi again,
>> 
>>> On 5 Apr 2018, at 21:19, Eirik Øverby - ModSecurity <ltn...@an...> wrote:
>>>> SecRule REQUEST_URI "@beginsWith /mdpayacs/pareq" \
>>>>  "phase:1,id:1003,t:none,pass,nolog,chain,\
>>>>      ctl:ruleRemoveTargetByTag=attack-sqli;ARGS:TermURL,\
>>>>      ctl:ruleRemoveTargetByTag=attack-rce;ARGS:TermURL,\
>>>>      ctl:ruleRemoveTargetByTag=attack-xss;ARGS:TermURL"
>>>>          SecRule ARGS:TermURL "@beginsWith http" "t:none"
>>> 
>>> before anyone comments - yes, I modified this to say phase:2 - does not make any difference..
>> 
>> The error, as it turned out, was that mod_security matches argument names in a case-sesnitive fashion, but our application does not. The TermURL parameter is sent to us from many different sources, with various degrees of CamelCasing and CAPItaliSation.
>> 
>> Question: Can I use e.g. MATCHED_VAR_NAME as argument to ruleRemoteTargetBy*? For example
>>  SecRule ARGS:/[Vv][Aa][Rr]/ "foo" "...... ctl:ruleRemoveTargetByTag=attack-sqli;MATCHED_VAR_NAME"
>> 
>> I have tried this, with no success so far - also with ARGS: prefix to MATCHED_VAR_NAME. I've also tried to use it in a chained rule.
>> 
>> /Eirik
>> ------------------------------------------------------------------------------
>> 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
> 
> ------------------------------------------------------------------------------
> 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] ruleRemoveTargetByTag - am I misunderstanding how it works?

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

Hey Eirik,

If it works, it would be "...attack-sqli;%{MATCHED_VAR_NAME}". I doubt this
works, but I have been proved wrong on Monday night with a similar question,
so don't trust me too much.

ModSec2.9 is quite talkative on DebugLogLevel 9, so you should be able to
tell if it worked based on the logfile.

Ahoj,

Christian


On Fri, Apr 06, 2018 at 02:28:09PM +0200, Eirik Øverby - ModSecurity wrote:
> Hi again,
> 
> > On 5 Apr 2018, at 21:19, Eirik Øverby - ModSecurity <ltn...@an...> wrote:
> >> SecRule REQUEST_URI "@beginsWith /mdpayacs/pareq" \
> >>   "phase:1,id:1003,t:none,pass,nolog,chain,\
> >>       ctl:ruleRemoveTargetByTag=attack-sqli;ARGS:TermURL,\
> >>       ctl:ruleRemoveTargetByTag=attack-rce;ARGS:TermURL,\
> >>       ctl:ruleRemoveTargetByTag=attack-xss;ARGS:TermURL"
> >>           SecRule ARGS:TermURL "@beginsWith http" "t:none"
> > 
> > before anyone comments - yes, I modified this to say phase:2 - does not make any difference..
> 
> The error, as it turned out, was that mod_security matches argument names in a case-sesnitive fashion, but our application does not. The TermURL parameter is sent to us from many different sources, with various degrees of CamelCasing and CAPItaliSation.
> 
> Question: Can I use e.g. MATCHED_VAR_NAME as argument to ruleRemoteTargetBy*? For example
>   SecRule ARGS:/[Vv][Aa][Rr]/ "foo" "...... ctl:ruleRemoveTargetByTag=attack-sqli;MATCHED_VAR_NAME"
> 
> I have tried this, with no success so far - also with ARGS: prefix to MATCHED_VAR_NAME. I've also tried to use it in a chained rule.
> 
> /Eirik
> ------------------------------------------------------------------------------
> 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] ruleRemoveTargetByTag - am I misunderstanding how it works?

[Eirik Ø. - M. <ltn...@an...>]

Hi again,

> On 5 Apr 2018, at 21:19, Eirik Øverby - ModSecurity <ltn...@an...> wrote:
>> SecRule REQUEST_URI "@beginsWith /mdpayacs/pareq" \
>>   "phase:1,id:1003,t:none,pass,nolog,chain,\
>>       ctl:ruleRemoveTargetByTag=attack-sqli;ARGS:TermURL,\
>>       ctl:ruleRemoveTargetByTag=attack-rce;ARGS:TermURL,\
>>       ctl:ruleRemoveTargetByTag=attack-xss;ARGS:TermURL"
>>           SecRule ARGS:TermURL "@beginsWith http" "t:none"
> 
> before anyone comments - yes, I modified this to say phase:2 - does not make any difference..

The error, as it turned out, was that mod_security matches argument names in a case-sesnitive fashion, but our application does not. The TermURL parameter is sent to us from many different sources, with various degrees of CamelCasing and CAPItaliSation.

Question: Can I use e.g. MATCHED_VAR_NAME as argument to ruleRemoteTargetBy*? For example
  SecRule ARGS:/[Vv][Aa][Rr]/ "foo" "...... ctl:ruleRemoveTargetByTag=attack-sqli;MATCHED_VAR_NAME"

I have tried this, with no success so far - also with ARGS: prefix to MATCHED_VAR_NAME. I've also tried to use it in a chained rule.

/Eirik

[mod-security-users] Bad Performance of ModSecurity 3.0 (was: [Mod-security-users] ModSecurity version 3.0.1 announcement)

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

Dear all, dear Felipe,

On Thu, Apr 05, 2018 at 06:28:06PM +0000, Felipe Zimmerle wrote:
>
> I cannot foresee how my priorities have to do with this thread :D :)
>

No, your past and your future priorities matter a big deal.

Various people have presented numbers about the performance of ModSec3 and the
data does not look good.

I continued my measurements and arrived with the following results:

Apache, no ModSec2            :  5490 requests per second

Apache, ModSec2, 1 rule       :  4588   - 15% (against naked webserver)
Apache, ModSec2, 10 rules     :  4329   - 20%
Apache, ModSec2, CRS3         :  1123   - 79%

NGINX, no ModSec3             : 10104 requests per second 

NGINX, ModSec3.0.0, 1 rule    :  4619   - 54% (against naked webserver)
NGINX, ModSec3.0.0, 10 rules  :  3380   - 66%
NGINX, ModSec3.0.0, CRS3      :    36   - 99%

NGINX, ModSec3.0.2,  1 rule   :  4168   - 58%
NGINX, ModSec3.0.2, 10 rules  :  3251   - 67%
NGINX, ModSec3.0.2, CRS3      :   255   - 97%

Parameters:
100000 reqs: http://localhost/index.html?test=test
3 test runs, I took the mean of the three runs.
Testrule used (1 time or 10 times in succession):
SecRule REQUEST_URI "@unconditionalMatch" "id:1,phase:1,pass,nolog,noauditlog"

[For those not familiar with ModSec Performance. The numbers look already
quite bad on Apache but that's because we are testing locally. Over the net,
the numbers for ModSec2 are acceptable.]



The takeaway message of the statistic above is this:

ModSec3 has a huge overhead and every additional rule makes it worse.



This confirms previous messages in this discussion. Namely those of Robert.

And all these confirmations contradict your words when you announced 3.0 at
https://www.trustwave.com/Resources/SpiderLabs-Blog/ModSecurity-Version-3-0-Announcement/
There you wrote: "This release represents a significant improvement to the 
ModSecurity WAF. It removes dependencies and improves performance."

I knew this was only wishful thinking when ModSec3 came out, but I did not 
want to badmouth your work Felipe. So I waited for 3.0.1 and hoped for
performance improvements.  The improvements are significant (what I
immediately reported). Unfortunately the performance is still miles
away from what I would expect from ModSec3 on NGINX.

So on April 3, I asked about your view on future performance improvements and 
a possible timeline. I think that is a reasonable thing to ask.
You did not respond, though, and when Robert pointed out where he
sees room for substantial improvements you invited him to refactor central
aspects of your code by himself.

We agree that it is not your job to do all the work. But please, at least come 
up with a plan how we can all solve this together. It's the least thing 
that we expect from a leader.

I interpret your communication here as a denial of any substantial
problem. You are the lead developer. If you do not acknowledge
the problem and if you do not present a plan to the community how 
this problem will be fixed, then you are hurting ModSecurity.

And that's why your and Trustwave's priorities matter a big deal.

Best regards,

Christian Folini

-- 
Author of the ModSecurity Handbook, 2ed
Author of a series of ModSecurity tutorials published at https://netnea.com
Renown teacher and frequent speaker on ModSecurity topics

Re: [mod-security-users] modsecurity rpms for centos 7

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

I put modsecurity-nginx-v1.0.0.tar.gz in the SOURCES directory for an NGINX
RPM build (I can't share that particular spec file), but I include
something like:

Source1:
https://github.com/SpiderLabs/ModSecurity-nginx/releases/download/v1.0.0/modsecurity-nginx-v1.0.0.tar.gz

as a source, and I include modsecurity-devel in BuildRequires:

BuildRequires:  ...,modsecurity-devel

and have this:

%setup -T -D -a 1 -n nginx-%{version}

as part of setup, and I'm adding this to configure:

./configure \
    --add-module=./modsecurity-nginx-v1.0.0 \
.
.
.

Hope that helps!

Gregory


On Thu, Apr 5, 2018 at 11:10 PM, Eero Volotinen <eer...@ik...>
wrote:

> works. do you have also rpm spec for connector?
>
> Eero
>
> On Thu, Apr 5, 2018 at 10:53 PM, Gregory LeFevre <gr...@cl...>
> wrote:
>
>>
>> Hi Eero,
>>
>> You can make one. An RPM spec file similar to the following has been
>> known to work on CentOS7:
>>
>>
>> ================================
>>
>> Name:     modsecurity
>>
>> Version:  3.0.2
>>
>> Release:  1
>>
>> License:  Apache License, Version 2.0, January 2004
>>
>> Summary:  Library for ModSecurity, an open source, cross platform web
>> application firewall (WAF) engine
>>
>> URL:      https://modsecurity.org/
>>
>>
>> BuildRequires:  bison,curl,doxygen,flex,gcc-c+
>> +,GeoIP-devel,libcurl-devel,libxml2-devel,pcre-devel,ssdeep-
>> devel,yajl,yajl-devel,
>>
>> zlib-devel
>>
>>
>> Source0:   https://github.com/SpiderLabs/ModSecurity/releases/download/
>> v%{version}/modsecurity-v%{version}.tar.gz
>>
>>
>>
>> %description
>>
>> Libmodsecurity is one component of the ModSecurity v3 project. The library
>>
>> codebase serves as an interface to ModSecurity Connectors taking in web
>>
>> traffic and applying traditional ModSecurity processing. In general, it
>>
>> provides the capability to load/interpret rules written in the ModSecurity
>>
>> SecRules format and apply them to HTTP content provided by your
>> application
>>
>> via Connectors.
>>
>>
>>
>> %package devel
>>
>> Requires: modsecurity = %{version}-%{release}
>>
>> Summary: Header files and libraries for Libmodsecurity development
>>
>>
>>
>> %description devel
>>
>> The modsecurity-devel package contains the header files and libraries
>> needed
>>
>> to develop programs that use the Libmodsecurity library.
>>
>>
>> %prep
>>
>>
>> %setup -n %{name}-v%{version}
>>
>>
>>
>> %build
>>
>>
>> export DESTDIR=%{buildroot}
>>
>>
>> %configure \
>>
>> --with-curl=/usr/bin/curl-config \
>>
>> --with-geoip=yes \
>>
>> --with-libxml=/usr/bin/xml2-config \
>>
>> --with-lmdb=no \
>>
>> --with-lua=no \
>>
>> --with-pcre=/usr/bin/pcre-config \
>>
>> --with-ssdeep=yes \
>>
>> --with-yajl=yes
>>
>>
>> make %{?_smp_flags}
>>
>>
>>
>> %install
>>
>>
>> make install DESTDIR=%{buildroot} INSTALLDIRS=vendor
>>
>>
>>
>> %clean
>>
>>
>> rm -rf %{buildroot}
>>
>>
>> %post -p /sbin/ldconfig
>>
>>
>>
>> %postun -p /sbin/ldconfig
>>
>>
>>
>> %files
>>
>> %defattr(-,root,root,-)
>>
>> %doc AUTHORS CHANGES LICENSE README.md
>>
>> %{_bindir}/modsec-rules-check
>>
>> %{_libdir}/libmodsecurity.so.3*
>>
>>
>>
>> %files devel
>>
>> %defattr(-,root,root,-)
>>
>> %dir %{_includedir}/modsecurity
>>
>> %{_includedir}/modsecurity/*
>>
>> %{_libdir}/libmodsecurity.a
>>
>> %{_libdir}/libmodsecurity.la
>>
>> %{_libdir}/libmodsecurity.so
>>
>>
>>
>> %changelog
>>
>> * Thu Apr 5 2018 Your Name <email address>
>>
>> - initial packaging
>>
>> ================================
>>
>>
>> You can copy the files into place and build with something like this:
>>
>>
>> cp -f modsecurity-v3.0.2.tar.gz ${DIRECTORY}/SOURCES/
>>
>> cp -f modsecurity.spec ${DIRECTORY}/SPECS/
>>
>>
>> rpmbuild -bb -vvvvv --define "_topdir ${TOPDIR}"
>> ${DIRECTORY}/SPECS/modsecurity.spec
>>
>>
>>
>> Unfortunately I'm not in a position to offer support for this at this
>> time, but hope it helps.
>>
>> Good luck!
>>
>>
>> Gregory
>>
>>
>> On Thu, Apr 5, 2018 at 10:35 AM, Eero Volotinen <eer...@ik...>
>> wrote:
>>
>>> Hi,
>>>
>>> is there modsecurity v3 rpms available for centos 7
>>>
>>> Eero
>>>
>>> ------------------------------------------------------------
>>> ------------------
>>> 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 rpms for centos 7

[Eero V. <eer...@ik...>]

works. do you have also rpm spec for connector?

Eero

On Thu, Apr 5, 2018 at 10:53 PM, Gregory LeFevre <gr...@cl...> wrote:

>
> Hi Eero,
>
> You can make one. An RPM spec file similar to the following has been known
> to work on CentOS7:
>
>
> ================================
>
> Name:     modsecurity
>
> Version:  3.0.2
>
> Release:  1
>
> License:  Apache License, Version 2.0, January 2004
>
> Summary:  Library for ModSecurity, an open source, cross platform web
> application firewall (WAF) engine
>
> URL:      https://modsecurity.org/
>
>
> BuildRequires:  bison,curl,doxygen,flex,gcc-c++,GeoIP-devel,libcurl-devel,
> libxml2-devel,pcre-devel,ssdeep-devel,yajl,yajl-devel,
>
> zlib-devel
>
>
> Source0:   https://github.com/SpiderLabs/ModSecurity/releases/download/
> v%{version}/modsecurity-v%{version}.tar.gz
>
>
>
> %description
>
> Libmodsecurity is one component of the ModSecurity v3 project. The library
>
> codebase serves as an interface to ModSecurity Connectors taking in web
>
> traffic and applying traditional ModSecurity processing. In general, it
>
> provides the capability to load/interpret rules written in the ModSecurity
>
> SecRules format and apply them to HTTP content provided by your application
>
> via Connectors.
>
>
>
> %package devel
>
> Requires: modsecurity = %{version}-%{release}
>
> Summary: Header files and libraries for Libmodsecurity development
>
>
>
> %description devel
>
> The modsecurity-devel package contains the header files and libraries
> needed
>
> to develop programs that use the Libmodsecurity library.
>
>
> %prep
>
>
> %setup -n %{name}-v%{version}
>
>
>
> %build
>
>
> export DESTDIR=%{buildroot}
>
>
> %configure \
>
> --with-curl=/usr/bin/curl-config \
>
> --with-geoip=yes \
>
> --with-libxml=/usr/bin/xml2-config \
>
> --with-lmdb=no \
>
> --with-lua=no \
>
> --with-pcre=/usr/bin/pcre-config \
>
> --with-ssdeep=yes \
>
> --with-yajl=yes
>
>
> make %{?_smp_flags}
>
>
>
> %install
>
>
> make install DESTDIR=%{buildroot} INSTALLDIRS=vendor
>
>
>
> %clean
>
>
> rm -rf %{buildroot}
>
>
> %post -p /sbin/ldconfig
>
>
>
> %postun -p /sbin/ldconfig
>
>
>
> %files
>
> %defattr(-,root,root,-)
>
> %doc AUTHORS CHANGES LICENSE README.md
>
> %{_bindir}/modsec-rules-check
>
> %{_libdir}/libmodsecurity.so.3*
>
>
>
> %files devel
>
> %defattr(-,root,root,-)
>
> %dir %{_includedir}/modsecurity
>
> %{_includedir}/modsecurity/*
>
> %{_libdir}/libmodsecurity.a
>
> %{_libdir}/libmodsecurity.la
>
> %{_libdir}/libmodsecurity.so
>
>
>
> %changelog
>
> * Thu Apr 5 2018 Your Name <email address>
>
> - initial packaging
>
> ================================
>
>
> You can copy the files into place and build with something like this:
>
>
> cp -f modsecurity-v3.0.2.tar.gz ${DIRECTORY}/SOURCES/
>
> cp -f modsecurity.spec ${DIRECTORY}/SPECS/
>
>
> rpmbuild -bb -vvvvv --define "_topdir ${TOPDIR}" ${DIRECTORY}/SPECS/
> modsecurity.spec
>
>
>
> Unfortunately I'm not in a position to offer support for this at this
> time, but hope it helps.
>
> Good luck!
>
>
> Gregory
>
>
> On Thu, Apr 5, 2018 at 10:35 AM, Eero Volotinen <eer...@ik...>
> wrote:
>
>> Hi,
>>
>> is there modsecurity v3 rpms available for centos 7
>>
>> Eero
>>
>> ------------------------------------------------------------
>> ------------------
>> 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] [Mod-security-developers] Question regarding transaction::processConnection()

[Jai H. <jai...@mu...>]

I hate to keep bringing this up, but I still don't see how my problem can
be addressed.
I will rephrase my question in the form of an example:

StartLine is received:    Post /Post HTTP/1.1
 -> Invoke ModSec->ProcessConnection() with client IP which is available at
this time to my application.
     For a request that is forwarded, this client IP will identify the load
balancer, and not the true client.
 -> Invoke ModSec to parse the start line.

Header is received:    host: localhost
 -> Invoke ModSec to parse header.

Header is received:    X-Forwarded-For: 172.23.116.55
 -> What should be done?
     Should I re-invoke ModSec->ProcessConnection() with this true client
IP = 172.23.116.55?
     Is there an alternative way to inform ModSec of this is the true
client IP?
     Should I delay the call to ModSec->ProcessConnection() until all
headers are parsed and then call it with either
       the original client IP or an XFF IP if one was received?
     Any other options?  None of the above seem like good ones.

Seems like this should be a typical scenario that already has a solution.

On Thu, Mar 8, 2018 at 8:42 AM, Jai Harpalani <jai...@mu...>
wrote:

> Sounds like it is a good idea to always call ProcessConnection(). If this
> is the case, then I'm still confused on how I can do this for the XFF case.
> My application has ModSec built into it. So, if I want to call
> ProcessConnection() from my application, I believe I must:
>
>  1 - Invoke it early in the transaction phase (before processing request
> headers, body, etc).
>  2 - Pass it serverIP/serverPort which identifies my application that has
> ModSec built into it.
>  3 - Pass it clientIP/clientPort which identifies the client making the
> request.
>
> For #3, an earlier email stated:
>
> In that case, it is safe to use the ip that initiated the request (tcp
> request). That is the same scenario as having ModSecurity behind a reverse
> proxy of some sort.
>
> For XFF requests, the ip that initiated the request will not accurately
> identify the client. Instead, it may identify a load balancer or similar
> entity which is in front of my application. If this ip is used to identify
> the client, it is not accurate, and all rules will be operating against a
> load balancer or similar entity rather than the true client.
>
>
>
> On Thu, Mar 8, 2018 at 8:03 AM, Felipe Costa <FC...@tr...> wrote:
>
>> Hi Jai,
>>
>>
>>
>> That is an assumption that may be true on a given time frame. The library
>> can do something else in a near future and it will assume that this method
>> is being called from whomever is consume it. That is one of the reasons
>> that calling this method is important.
>>
>>
>>
>> Br.,
>>
>> *Felipe “Zimmerle” Costa*
>>
>> Security Researcher, Lead Developer ModSecurity.
>>
>>
>>
>> *Trustwave* | SMART SECURITY ON DEMAND
>>
>> *www.trustwave.com <http://www.trustwave.com/>*
>>
>>
>>
>> *From: *Jai Harpalani <jai...@mu...>
>> *Date: *Thursday, March 8, 2018 at 1:53 AM
>> *To: *Felipe Costa <FC...@tr...>
>> *Cc: *Robert Paprocki <rpa...@fe...>, "
>> mod...@li..." <
>> mod...@li...>
>> *Subject: *Re: [Mod-security-developers] Question regarding
>> transaction::processConnection()
>>
>>
>>
>> Searching through the CRS rules, I see that real_ip is used for DOS and
>> IP_REPUTATION rules. I am excluding those rules for my specific
>> application. Due to these exclusions, it seems like the call to
>> ProcessConnection() is required only to set the uniqueID. Is this an
>> accurate statement?
>>
>>
>>
>> (…)
>>
>
>

Re: [mod-security-users] [Mod-security-developers] ModSecurity version 3.0.1 announcement

[Jai H. <jai...@mu...>]

"Yes of course. Again, what I'm highlighting here is the very substantial
difference between Nginx with and without ModSecurity. A two-order of
magnitude drop is simply unacceptable for operators that need to handle
requests at any significant scale. If there was a 10-20% drop in
performance, that would be completely understandable. But the current
benchmarks highlight a much larger gap. This is the key point I'm trying to
drive home. I apologize if I'm failing to make this clear."

Using the data from the results I previously attached, I see a slowdown
factor of 35-140 times, depending on the size of the request body. For
example, with ModSecurity disabled, I am able to process a single Json
request with 32M body in ~11 ms. With ModSecurity v3.0.1 enabled, it takes
~1476 ms to process this same request. That's 140 times as long with
ModSecurity enabled vs disabled.

On Thu, Apr 5, 2018 at 2:25 PM, Robert Paprocki <
rpa...@fe...> wrote:

> Hi,
>
> On Thu, Apr 5, 2018 at 11:28 AM, Felipe Zimmerle <fe...@zi...>
> wrote:
>
>> Hi,
>>
>> Not sure if i understood but, that sounds about right to me. That is also
>> valid for any script language.
>>
>> [a] for (i = 0; i < 10; i++) { echo "a"; }
>> [b] for (i = 0; i < 100; i++) { echo "b"; }
>> [c] for (i = 0; i < 10; i++) { for (j = 0; j < 10; j++) { echo "b"; } }
>>
>> In that case, [a] will be faster than [b]. [b] is likely to run on the
>> same time of [c].
>>
>> The response time is directly proportional to the task that needs to be
>> computed. That is pretty much it from anything that runs on computer.
>>
>
>
> Yes. I'm not saying this is unexpected behavior. I'm simply highlighting
> the nature of my (very quick and imperfect) tests. I'm also highlighting
> the fact that the contents of the rule itself (like a very complex regex
> with many transformations) is not necessarily a major burden; it's simply
> the introduction of more rules that has a considerable impact on
> performance. And libmodsecurity's performance is so limited in these cases
> that it's worth this discussion. Of course, more complex rules will induce
> more performance delay. But the base processing of rules, regardless of
> their design, is a major bottleneck in libmodsecurity. Quite frankly I
> would expect a very simple rule like
>
> SecRules ARGS:test "@streq foo" "id:12345,phase:1,deny,t:none"
>
> To not perform so very poorly. And it doesn't. When you run many dozens or
> hundreds of these rules though, that's when things slow to a crawl. And
> that is a result of the design of the core libmodsecurity code, not the
> rule itself.
>
>
>
>> I think you meant that nginx by its own can delivery more content than
>> nginx with ModSecurity. Which can be considered true regardless how good or
>> bad the performance of ModSecurity is. Considers ModSec load "B" and nginx
>> load "A".
>>
>> A < A + B.
>>
>> Please correct me if I understood it wrong.
>>
>
>
> Yes of course. Again, what I'm highlighting here is the very substantial
> difference between Nginx with and without ModSecurity. A two-order of
> magnitude drop is simply unacceptable for operators that need to handle
> requests at any significant scale. If there was a 10-20% drop in
> performance, that would be completely understandable. But the current
> benchmarks highlight a much larger gap. This is the key point I'm trying to
> drive home. I apologize if I'm failing to make this clear.
>
>
>
>> [...]
>>>
>>
>
>
>> As a matter of fact, there are a lot of room for improvements. Myself,
>> and [i think] everybody which uses ModSecurity will be very happy and
>> welcome to receive your contribution. As we already receive a lot of
>> contributions from Andrei. You just have to send the patches. As I
>> mentioned before, I am anxious for that. I think everybody that you
>> mentioned wants to see those improvements as well.
>>
>> When do you think you can share something with us?
>>
>> Is that anything that I can do to help you?
>>
>
>
> Unfortunately I'm not in a position to make significant contributions at
> this time. I can chat, build some simple tests, write small patches here
> and there. I have a full time job that does not allow me to do meaningful
> development for functionality like this. And I have two small children and
> home responsibilities that preclude me from investing significant personal
> time (though I would love to be able to do that). I love that
> libmodsecurity continues to remain an open source project. I truly wish I
> had more personal time to invest in it.
>
> TBH it would be great if you could review the flamegraphs I've left in
> this thread, and let me know if those are of any use. I would also be very
> interested in hearing from other ModSecurity operators their experiences
> with libmodsecurity's performance. Perhaps I've just made a giant error and
> the simple test harness results I see are not an accurate reflection of
> reality.
>
> And if I need to adjust my expectations, then we should settle on that. My
> expectation is coming from an environment where running Nginx (OpenResty)
> on moderate hardware and leveraging the logic made available by the CRS
> allowed for ~15000 req/s (https://github.com/p0pr0ck5/l
> ua-resty-waf#performance; this was an older test but should still old
> up). I assumed that, without a Lua/OpenResty abstraction layer, we would
> see even better performance with a native Nginx module + integration.
> Running the same ruleset with libmodsecurity 3.0.2, I see roughly 1/10th
> the performance. If this is what we should expect from libmodsecurity, then
> I will not make any more noise here :)
>
> ------------------------------------------------------------
> ------------------
> 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 rpms for centos 7

[Eero V. <eer...@ik...>]

thanks.

to 5. huhtik. 2018 klo 22.54 Gregory LeFevre <gr...@cl...> kirjoitti:

>
> Hi Eero,
>
> You can make one. An RPM spec file similar to the following has been known
> to work on CentOS7:
>
>
> ================================
>
> Name:     modsecurity
>
> Version:  3.0.2
>
> Release:  1
>
> License:  Apache License, Version 2.0, January 2004
>
> Summary:  Library for ModSecurity, an open source, cross platform web
> application firewall (WAF) engine
>
> URL:      https://modsecurity.org/
>
>
> BuildRequires:
> bison,curl,doxygen,flex,gcc-c++,GeoIP-devel,libcurl-devel,libxml2-devel,pcre-devel,ssdeep-devel,yajl,yajl-devel,
>
> zlib-devel
>
>
> Source0:
> https://github.com/SpiderLabs/ModSecurity/releases/download/v%{version}/modsecurity-v%{version}.tar.gz
>
>
>
> %description
>
> Libmodsecurity is one component of the ModSecurity v3 project. The library
>
> codebase serves as an interface to ModSecurity Connectors taking in web
>
> traffic and applying traditional ModSecurity processing. In general, it
>
> provides the capability to load/interpret rules written in the ModSecurity
>
> SecRules format and apply them to HTTP content provided by your application
>
> via Connectors.
>
>
>
> %package devel
>
> Requires: modsecurity = %{version}-%{release}
>
> Summary: Header files and libraries for Libmodsecurity development
>
>
>
> %description devel
>
> The modsecurity-devel package contains the header files and libraries
> needed
>
> to develop programs that use the Libmodsecurity library.
>
>
> %prep
>
>
> %setup -n %{name}-v%{version}
>
>
>
> %build
>
>
> export DESTDIR=%{buildroot}
>
>
> %configure \
>
> --with-curl=/usr/bin/curl-config \
>
> --with-geoip=yes \
>
> --with-libxml=/usr/bin/xml2-config \
>
> --with-lmdb=no \
>
> --with-lua=no \
>
> --with-pcre=/usr/bin/pcre-config \
>
> --with-ssdeep=yes \
>
> --with-yajl=yes
>
>
> make %{?_smp_flags}
>
>
>
> %install
>
>
> make install DESTDIR=%{buildroot} INSTALLDIRS=vendor
>
>
>
> %clean
>
>
> rm -rf %{buildroot}
>
>
> %post -p /sbin/ldconfig
>
>
>
> %postun -p /sbin/ldconfig
>
>
>
> %files
>
> %defattr(-,root,root,-)
>
> %doc AUTHORS CHANGES LICENSE README.md
>
> %{_bindir}/modsec-rules-check
>
> %{_libdir}/libmodsecurity.so.3*
>
>
>
> %files devel
>
> %defattr(-,root,root,-)
>
> %dir %{_includedir}/modsecurity
>
> %{_includedir}/modsecurity/*
>
> %{_libdir}/libmodsecurity.a
>
> %{_libdir}/libmodsecurity.la
>
> %{_libdir}/libmodsecurity.so
>
>
>
> %changelog
>
> * Thu Apr 5 2018 Your Name <email address>
>
> - initial packaging
>
> ================================
>
>
> You can copy the files into place and build with something like this:
>
>
> cp -f modsecurity-v3.0.2.tar.gz ${DIRECTORY}/SOURCES/
>
> cp -f modsecurity.spec ${DIRECTORY}/SPECS/
>
>
> rpmbuild -bb -vvvvv --define "_topdir ${TOPDIR}"
> ${DIRECTORY}/SPECS/modsecurity.spec
>
>
>
> Unfortunately I'm not in a position to offer support for this at this
> time, but hope it helps.
>
> Good luck!
>
>
> Gregory
>
>
> On Thu, Apr 5, 2018 at 10:35 AM, Eero Volotinen <eer...@ik...>
> wrote:
>
>> Hi,
>>
>> is there modsecurity v3 rpms available for centos 7
>>
>> Eero
>>
>>
>> ------------------------------------------------------------------------------
>> 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 rpms for centos 7

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

Hi Eero,

You can make one. An RPM spec file similar to the following has been known
to work on CentOS7:


================================

Name:     modsecurity

Version:  3.0.2

Release:  1

License:  Apache License, Version 2.0, January 2004

Summary:  Library for ModSecurity, an open source, cross platform web
application firewall (WAF) engine

URL:      https://modsecurity.org/


BuildRequires:
bison,curl,doxygen,flex,gcc-c++,GeoIP-devel,libcurl-devel,libxml2-devel,pcre-devel,ssdeep-devel,yajl,yajl-devel,

zlib-devel


Source0:
https://github.com/SpiderLabs/ModSecurity/releases/download/v%{version}/modsecurity-v%{version}.tar.gz



%description

Libmodsecurity is one component of the ModSecurity v3 project. The library

codebase serves as an interface to ModSecurity Connectors taking in web

traffic and applying traditional ModSecurity processing. In general, it

provides the capability to load/interpret rules written in the ModSecurity

SecRules format and apply them to HTTP content provided by your application

via Connectors.



%package devel

Requires: modsecurity = %{version}-%{release}

Summary: Header files and libraries for Libmodsecurity development



%description devel

The modsecurity-devel package contains the header files and libraries needed

to develop programs that use the Libmodsecurity library.


%prep


%setup -n %{name}-v%{version}



%build


export DESTDIR=%{buildroot}


%configure \

--with-curl=/usr/bin/curl-config \

--with-geoip=yes \

--with-libxml=/usr/bin/xml2-config \

--with-lmdb=no \

--with-lua=no \

--with-pcre=/usr/bin/pcre-config \

--with-ssdeep=yes \

--with-yajl=yes


make %{?_smp_flags}



%install


make install DESTDIR=%{buildroot} INSTALLDIRS=vendor



%clean


rm -rf %{buildroot}


%post -p /sbin/ldconfig



%postun -p /sbin/ldconfig



%files

%defattr(-,root,root,-)

%doc AUTHORS CHANGES LICENSE README.md

%{_bindir}/modsec-rules-check

%{_libdir}/libmodsecurity.so.3*



%files devel

%defattr(-,root,root,-)

%dir %{_includedir}/modsecurity

%{_includedir}/modsecurity/*

%{_libdir}/libmodsecurity.a

%{_libdir}/libmodsecurity.la

%{_libdir}/libmodsecurity.so



%changelog

* Thu Apr 5 2018 Your Name <email address>

- initial packaging

================================


You can copy the files into place and build with something like this:


cp -f modsecurity-v3.0.2.tar.gz ${DIRECTORY}/SOURCES/

cp -f modsecurity.spec ${DIRECTORY}/SPECS/


rpmbuild -bb -vvvvv --define "_topdir ${TOPDIR}"
${DIRECTORY}/SPECS/modsecurity.spec



Unfortunately I'm not in a position to offer support for this at this time,
but hope it helps.

Good luck!


Gregory


On Thu, Apr 5, 2018 at 10:35 AM, Eero Volotinen <eer...@ik...>
wrote:

> Hi,
>
> is there modsecurity v3 rpms available for centos 7
>
> Eero
>
> ------------------------------------------------------------
> ------------------
> 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] [Mod-security-developers] ModSecurity version 3.0.1 announcement

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

Hi William/Felipe,

On Thu, Apr 5, 2018 at 11:34 AM, Felipe Zimmerle <fe...@zi...>
wrote:

>
> Hi William,
>
> Apart from the "-DNO_LOG" there is also the compilation flag:
> "--disable-debug-logs". This is meant to be used in headless servers, such
> as a CDN. That completely disables the debugging log generation. That speed
> up things a little bit.
>
> Br.,
> Felipe
>

Yes, I have compiled with that flag. I noticed about a 10% improvement in
some basic harness testing- noticeable, but certainly not the bottleneck
that I've highlighted previously. Thanks for this suggestion.

Re: [mod-security-users] [Mod-security-developers] ModSecurity version 3.0.1 announcement

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

Hi,

On Thu, Apr 5, 2018 at 11:28 AM, Felipe Zimmerle <fe...@zi...>
wrote:

> Hi,
>
> Not sure if i understood but, that sounds about right to me. That is also
> valid for any script language.
>
> [a] for (i = 0; i < 10; i++) { echo "a"; }
> [b] for (i = 0; i < 100; i++) { echo "b"; }
> [c] for (i = 0; i < 10; i++) { for (j = 0; j < 10; j++) { echo "b"; } }
>
> In that case, [a] will be faster than [b]. [b] is likely to run on the
> same time of [c].
>
> The response time is directly proportional to the task that needs to be
> computed. That is pretty much it from anything that runs on computer.
>


Yes. I'm not saying this is unexpected behavior. I'm simply highlighting
the nature of my (very quick and imperfect) tests. I'm also highlighting
the fact that the contents of the rule itself (like a very complex regex
with many transformations) is not necessarily a major burden; it's simply
the introduction of more rules that has a considerable impact on
performance. And libmodsecurity's performance is so limited in these cases
that it's worth this discussion. Of course, more complex rules will induce
more performance delay. But the base processing of rules, regardless of
their design, is a major bottleneck in libmodsecurity. Quite frankly I
would expect a very simple rule like

SecRules ARGS:test "@streq foo" "id:12345,phase:1,deny,t:none"

To not perform so very poorly. And it doesn't. When you run many dozens or
hundreds of these rules though, that's when things slow to a crawl. And
that is a result of the design of the core libmodsecurity code, not the
rule itself.



> I think you meant that nginx by its own can delivery more content than
> nginx with ModSecurity. Which can be considered true regardless how good or
> bad the performance of ModSecurity is. Considers ModSec load "B" and nginx
> load "A".
>
> A < A + B.
>
> Please correct me if I understood it wrong.
>


Yes of course. Again, what I'm highlighting here is the very substantial
difference between Nginx with and without ModSecurity. A two-order of
magnitude drop is simply unacceptable for operators that need to handle
requests at any significant scale. If there was a 10-20% drop in
performance, that would be completely understandable. But the current
benchmarks highlight a much larger gap. This is the key point I'm trying to
drive home. I apologize if I'm failing to make this clear.



> [...]
>>
>


> As a matter of fact, there are a lot of room for improvements. Myself, and
> [i think] everybody which uses ModSecurity will be very happy and welcome
> to receive your contribution. As we already receive a lot of contributions
> from Andrei. You just have to send the patches. As I mentioned before, I am
> anxious for that. I think everybody that you mentioned wants to see those
> improvements as well.
>
> When do you think you can share something with us?
>
> Is that anything that I can do to help you?
>


Unfortunately I'm not in a position to make significant contributions at
this time. I can chat, build some simple tests, write small patches here
and there. I have a full time job that does not allow me to do meaningful
development for functionality like this. And I have two small children and
home responsibilities that preclude me from investing significant personal
time (though I would love to be able to do that). I love that
libmodsecurity continues to remain an open source project. I truly wish I
had more personal time to invest in it.

TBH it would be great if you could review the flamegraphs I've left in this
thread, and let me know if those are of any use. I would also be very
interested in hearing from other ModSecurity operators their experiences
with libmodsecurity's performance. Perhaps I've just made a giant error and
the simple test harness results I see are not an accurate reflection of
reality.

And if I need to adjust my expectations, then we should settle on that. My
expectation is coming from an environment where running Nginx (OpenResty)
on moderate hardware and leveraging the logic made available by the CRS
allowed for ~15000 req/s (https://github.com/p0pr0ck5/
lua-resty-waf#performance; this was an older test but should still old up).
I assumed that, without a Lua/OpenResty abstraction layer, we would see
even better performance with a native Nginx module + integration. Running
the same ruleset with libmodsecurity 3.0.2, I see roughly 1/10th the
performance. If this is what we should expect from libmodsecurity, then I
will not make any more noise here :)

Re: [mod-security-users] ruleRemoveTargetByTag - am I misunderstanding how it works?

[Eirik Ø. - M. <ltn...@an...>]

All,

> On 5 Apr 2018, at 16:19, Eirik Øverby - ModSecurity <ltn...@an...> wrote:
...
> SecRule REQUEST_URI "@beginsWith /mdpayacs/pareq" \
>    "phase:1,id:1003,t:none,pass,nolog,chain,\
>        ctl:ruleRemoveTargetByTag=attack-sqli;ARGS:TermURL,\
>        ctl:ruleRemoveTargetByTag=attack-rce;ARGS:TermURL,\
>        ctl:ruleRemoveTargetByTag=attack-xss;ARGS:TermURL"
>            SecRule ARGS:TermURL "@beginsWith http" "t:none"

before anyone comments - yes, I modified this to say phase:2 - does not make any difference..

/Eirik

Re: [mod-security-users] [Mod-security-developers] ModSecurity version 3.0.1 announcement

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

Hi William,

Apart from the "-DNO_LOG" there is also the compilation flag:
"--disable-debug-logs". This is meant to be used in headless servers, such
as a CDN. That completely disables the debugging log generation. That speed
up things a little bit.

Br.,
Felipe

On Thu, Apr 5, 2018 at 3:12 PM William Case <wil...@mu...>
wrote:

> Robert - Curious, were you building with -DNO_LOG ?
>
> The MuleSoft numbers Jai provided were with ModSec calls to debug log
> compiled out. In its current form, it is way to expensive performance wise.
> Probably worth a separate logging oriented discussion.
>
> Regards - Jay Case
>
> On Thu, Apr 5, 2018 at 12:08 PM, Robert Paprocki <
> rpa...@fe...> wrote:
>
>> Hi Felipe,
>>
>> On Thu, Apr 5, 2018 at 6:33 AM, Felipe Zimmerle <fe...@zi...>
>> wrote:
>>
>>> Hi,
>>>
>>> There are few things in the code that can be improved. There are even
>>> "TODO:" marking. But at certain point you may want to look at the rules.
>>> That is very important.
>>>
>>
>> I'm not sure if I emphasized my last point well enough. Yes, the design
>> of the rules impacts performance (that's a given in a data-driven model),
>> but the engine itself suffers from some severe limitations at this point.
>>
>> I created a very dumb, sizeable set of rules:
>> https://gist.github.com/p0pr0ck5/e0c73606f0be8ab93edb729e6cb56c5d
>>
>> Using the simple harness I mentioned earlier (
>> https://gist.github.com/p0pr0ck5/9b2c414641c9b03d527679d0c8cb7d86), we
>> see a sizeable decrease in performance as the number of dumb rules
>> increases. With 200 rules, a single process can evaluate around 800 full
>> transactions per second. When we double the number of rules processed
>> (remaining equally distributed throughout phases 1-5), around 450
>> transactions are processed, and another doubling in rule size (to 800
>> rules) results in a throughput of about 200 transactions/sec.
>>
>> Of course, this simple example does a lot of unnecessary memory
>> transactions with ModSecurity objects; the Nginx connector is a bit more
>> performant. With 800 rules, a single worker process reports still only
>> triple-digit RPS:
>>
>> $ wrk -t 5 -c 50 -d 5s http://localhost:8080/index.html
>> Running 5s test @ http://localhost:8080/index.html
>>   5 threads and 50 connections
>>   Thread Stats   Avg      Stdev     Max   +/- Stdev
>>     Latency   133.28ms  230.40ms   1.92s    92.92%
>>     Req/Sec   133.53     53.89   410.00     77.39%
>>   3085 requests in 5.03s, 2.50MB read
>> Requests/sec:    612.94
>> Transfer/sec:    508.79KB
>>
>> Yes, this is better than the CRS performance, but it's still orders of
>> magnitude from what Nginx is capable of processing on its own. So we cannot
>> say that such poor performance with the CRS is related to the design of the
>> ruleset itself. There is a clear relationship between the *number* of
>> rules that lobmodsecurity has to process, and performance. This further
>> confirms my original assertions, that there are fundamental limitations in
>> core ModSecurity code that hinders performance. Furthermore there are no
>> TODO comments regarding the performance of Rule object evaluation:
>>
>> poprocks@mini-vm:~/src/ModSecurity/src$ git grep TODO
>> parser/seclang-scanner.cc:/* TODO: this is always defined, so inline it */
>> parser/seclang-scanner.cc:            /** TODO: Implement the server
>> logging mechanism. */
>> parser/seclang-scanner.cc:      /* TODO. We should be able to replace
>> this entire function body
>> parser/seclang-scanner.ll:            /** TODO: Implement the server
>> logging mechanism. */
>> request_body_processor/json.cc:     * TODO: make UTF8 validation
>> optional, as it depends on Content-Encoding
>> transaction.cc:    /** TODO: Check variable */
>> transaction.cc:    /** TODO: Check variable */
>> transaction.cc:    /** TODO: Check variable */
>> transaction.cc:    /** TODO: Check variable */
>> transaction.cc:        /** TODO: write audit_log D part. */
>> transaction.cc:        /** TODO: write audit_log G part. */
>> transaction.cc:        /** TODO: write audit_log H part. */
>> transaction.cc:        /** TODO: write audit_log I part. */
>> transaction.cc:        /** TODO: write audit_log J part. */
>> transaction.cc:        /** TODO: write audit_log K part. */
>> utils/acmp.cc: * TODO: This code comes from ModSecurity 2.9.0 there are
>> two memory leaks here
>> utils/msc_tree.h: * TODO: This is an improved copy of the ModSecurity 2.9
>> file, this may need
>>
>> There is a lot of needlessly repeated work done in Rule::evaluate.
>> Collection values, exemptions, transformations, etc., these can all be
>> cached based on some key relevant to the rule. I implemented a lot of these
>> design patterns for lua-resty-waf, and it's really helped with performance;
>> I'd love to share some detailed thoughts on this in a development
>> discussion setting. And, as flamegraphs show, there's a lot of std
>> container allocation/management that's done that I suspect could be
>> optimized away. But these are fundamental design changes that would have a
>> major impact, and would require careful study and planning. This is
>> something I doubt could be handled by a community contribution. Ultimately
>> we're talking about a refactor of some significant hot path code. And
>> Felipe, please understand that I and the community deeply respect the work
>> that's been done on this project, but frankly this doesn't seem to be a
>> priority for you, based on the responses in this thread. And if in your
>> view I'm way off base in my assumptions, I'd love to hear it, and review
>> some data and example execution that contradicts what I, Christian, Jai,
>> and Andrei have shown here, and if not, at least an acknowledgement from
>> either Trustwave or Nginx that the inclusion of Modsecurity into Nginx
>> results in a substantial, meaningful variance in throughput capacity.
>>
>>
>>
>> ------------------------------------------------------------------------------
>> 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] [Mod-security-developers] ModSecurity version 3.0.1 announcement

[William C. <wil...@mu...>]

Robert - Curious, were you building with -DNO_LOG ?

The MuleSoft numbers Jai provided were with ModSec calls to debug log
compiled out. In its current form, it is way to expensive performance wise.
Probably worth a separate logging oriented discussion.

Regards - Jay Case

On Thu, Apr 5, 2018 at 12:08 PM, Robert Paprocki <
rpa...@fe...> wrote:

> Hi Felipe,
>
> On Thu, Apr 5, 2018 at 6:33 AM, Felipe Zimmerle <fe...@zi...>
> wrote:
>
>> Hi,
>>
>> There are few things in the code that can be improved. There are even
>> "TODO:" marking. But at certain point you may want to look at the rules.
>> That is very important.
>>
>
> I'm not sure if I emphasized my last point well enough. Yes, the design of
> the rules impacts performance (that's a given in a data-driven model), but
> the engine itself suffers from some severe limitations at this point.
>
> I created a very dumb, sizeable set of rules: https://gist.github.com
> /p0pr0ck5/e0c73606f0be8ab93edb729e6cb56c5d
>
> Using the simple harness I mentioned earlier (
> https://gist.github.com/p0pr0ck5/9b2c414641c9b03d527679d0c8cb7d86), we
> see a sizeable decrease in performance as the number of dumb rules
> increases. With 200 rules, a single process can evaluate around 800 full
> transactions per second. When we double the number of rules processed
> (remaining equally distributed throughout phases 1-5), around 450
> transactions are processed, and another doubling in rule size (to 800
> rules) results in a throughput of about 200 transactions/sec.
>
> Of course, this simple example does a lot of unnecessary memory
> transactions with ModSecurity objects; the Nginx connector is a bit more
> performant. With 800 rules, a single worker process reports still only
> triple-digit RPS:
>
> $ wrk -t 5 -c 50 -d 5s http://localhost:8080/index.html
> Running 5s test @ http://localhost:8080/index.html
>   5 threads and 50 connections
>   Thread Stats   Avg      Stdev     Max   +/- Stdev
>     Latency   133.28ms  230.40ms   1.92s    92.92%
>     Req/Sec   133.53     53.89   410.00     77.39%
>   3085 requests in 5.03s, 2.50MB read
> Requests/sec:    612.94
> Transfer/sec:    508.79KB
>
> Yes, this is better than the CRS performance, but it's still orders of
> magnitude from what Nginx is capable of processing on its own. So we cannot
> say that such poor performance with the CRS is related to the design of the
> ruleset itself. There is a clear relationship between the *number* of
> rules that lobmodsecurity has to process, and performance. This further
> confirms my original assertions, that there are fundamental limitations in
> core ModSecurity code that hinders performance. Furthermore there are no
> TODO comments regarding the performance of Rule object evaluation:
>
> poprocks@mini-vm:~/src/ModSecurity/src$ git grep TODO
> parser/seclang-scanner.cc:/* TODO: this is always defined, so inline it */
> parser/seclang-scanner.cc:            /** TODO: Implement the server
> logging mechanism. */
> parser/seclang-scanner.cc:      /* TODO. We should be able to replace this
> entire function body
> parser/seclang-scanner.ll:            /** TODO: Implement the server
> logging mechanism. */
> request_body_processor/json.cc:     * TODO: make UTF8 validation
> optional, as it depends on Content-Encoding
> transaction.cc:    /** TODO: Check variable */
> transaction.cc:    /** TODO: Check variable */
> transaction.cc:    /** TODO: Check variable */
> transaction.cc:    /** TODO: Check variable */
> transaction.cc:        /** TODO: write audit_log D part. */
> transaction.cc:        /** TODO: write audit_log G part. */
> transaction.cc:        /** TODO: write audit_log H part. */
> transaction.cc:        /** TODO: write audit_log I part. */
> transaction.cc:        /** TODO: write audit_log J part. */
> transaction.cc:        /** TODO: write audit_log K part. */
> utils/acmp.cc: * TODO: This code comes from ModSecurity 2.9.0 there are
> two memory leaks here
> utils/msc_tree.h: * TODO: This is an improved copy of the ModSecurity 2.9
> file, this may need
>
> There is a lot of needlessly repeated work done in Rule::evaluate.
> Collection values, exemptions, transformations, etc., these can all be
> cached based on some key relevant to the rule. I implemented a lot of these
> design patterns for lua-resty-waf, and it's really helped with performance;
> I'd love to share some detailed thoughts on this in a development
> discussion setting. And, as flamegraphs show, there's a lot of std
> container allocation/management that's done that I suspect could be
> optimized away. But these are fundamental design changes that would have a
> major impact, and would require careful study and planning. This is
> something I doubt could be handled by a community contribution. Ultimately
> we're talking about a refactor of some significant hot path code. And
> Felipe, please understand that I and the community deeply respect the work
> that's been done on this project, but frankly this doesn't seem to be a
> priority for you, based on the responses in this thread. And if in your
> view I'm way off base in my assumptions, I'd love to hear it, and review
> some data and example execution that contradicts what I, Christian, Jai,
> and Andrei have shown here, and if not, at least an acknowledgement from
> either Trustwave or Nginx that the inclusion of Modsecurity into Nginx
> results in a substantial, meaningful variance in throughput capacity.
>
>
> ------------------------------------------------------------
> ------------------
> 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] [Mod-security-developers] ModSecurity version 3.0.1 announcement

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

Hi,

On Thu, Apr 5, 2018 at 2:08 PM Robert Paprocki <
rpa...@fe...> wrote:

> Hi Felipe,
>
> On Thu, Apr 5, 2018 at 6:33 AM, Felipe Zimmerle <fe...@zi...>
> wrote:
>
>> Hi,
>>
>> There are few things in the code that can be improved. There are even
>> "TODO:" marking. But at certain point you may want to look at the rules.
>> That is very important.
>>
>
> I'm not sure if I emphasized my last point well enough. Yes, the design of
> the rules impacts performance (that's a given in a data-driven model), but
> the engine itself suffers from some severe limitations at this point.
>
> I created a very dumb, sizeable set of rules:
> https://gist.github.com/p0pr0ck5/e0c73606f0be8ab93edb729e6cb56c5d
>
> Using the simple harness I mentioned earlier (
> https://gist.github.com/p0pr0ck5/9b2c414641c9b03d527679d0c8cb7d86), we
> see a sizeable decrease in performance as the number of dumb rules
> increases. With 200 rules, a single process can evaluate around 800 full
> transactions per second. When we double the number of rules processed
> (remaining equally distributed throughout phases 1-5), around 450
> transactions are processed, and another doubling in rule size (to 800
> rules) results in a throughput of about 200 transactions/sec.
>
>
Not sure if i understood but, that sounds about right to me. That is also
valid for any script language.

[a] for (i = 0; i < 10; i++) { echo "a"; }
[b] for (i = 0; i < 100; i++) { echo "b"; }
[c] for (i = 0; i < 10; i++) { for (j = 0; j < 10; j++) { echo "b"; } }

In that case, [a] will be faster than [b]. [b] is likely to run on the same
time of [c].

The response time is directly proportional to the task that needs to be
computed. That is pretty much it from anything that runs on computer.

Of course, this simple example does a lot of unnecessary memory
> transactions with ModSecurity objects; the Nginx connector is a bit more
> performant. With 800 rules, a single worker process reports still only
> triple-digit RPS:
>
> $ wrk -t 5 -c 50 -d 5s http://localhost:8080/index.html
> Running 5s test @ http://localhost:8080/index.html
>   5 threads and 50 connections
>   Thread Stats   Avg      Stdev     Max   +/- Stdev
>     Latency   133.28ms  230.40ms   1.92s    92.92%
>     Req/Sec   133.53     53.89   410.00     77.39%
>   3085 requests in 5.03s, 2.50MB read
> Requests/sec:    612.94
> Transfer/sec:    508.79KB
>
> Yes, this is better than the CRS performance, but it's still orders of
> magnitude from what Nginx is capable of processing on its own. So we cannot
> say that such poor performance with the CRS is related to the design of the
> ruleset itself. There is a clear relationship between the *number* of
> rules that lobmodsecurity has to process, and performance. This further
> confirms my original assertions, that there are fundamental limitations in
> core ModSecurity code that hinders performance. Furthermore there are no
> TODO comments regarding the performance of Rule object evaluation:
>
>
I think you meant that nginx by its own can delivery more content than
nginx with ModSecurity. Which can be considered true regardless how good or
bad the performance of ModSecurity is. Considers ModSec load "B" and nginx
load "A".

A < A + B.

Please correct me if I understood it wrong.

poprocks@mini-vm:~/src/ModSecurity/src$ git grep TODO
> parser/seclang-scanner.cc:/* TODO: this is always defined, so inline it */
> parser/seclang-scanner.cc:            /** TODO: Implement the server
> logging mechanism. */
> parser/seclang-scanner.cc:      /* TODO. We should be able to replace this
> entire function body
> parser/seclang-scanner.ll:            /** TODO: Implement the server
> logging mechanism. */
> request_body_processor/json.cc:     * TODO: make UTF8 validation optional,
> as it depends on Content-Encoding
> transaction.cc:    /** TODO: Check variable */
> transaction.cc:    /** TODO: Check variable */
> transaction.cc:    /** TODO: Check variable */
> transaction.cc:    /** TODO: Check variable */
> transaction.cc:        /** TODO: write audit_log D part. */
> transaction.cc:        /** TODO: write audit_log G part. */
> transaction.cc:        /** TODO: write audit_log H part. */
> transaction.cc:        /** TODO: write audit_log I part. */
> transaction.cc:        /** TODO: write audit_log J part. */
> transaction.cc:        /** TODO: write audit_log K part. */
> utils/acmp.cc: * TODO: This code comes from ModSecurity 2.9.0 there are
> two memory leaks here
> utils/msc_tree.h: * TODO: This is an improved copy of the ModSecurity 2.9
> file, this may need
>
>
Sure. I will investigate.


> There is a lot of needlessly repeated work done in Rule::evaluate.
> Collection values, exemptions, transformations, etc., these can all be
> cached based on some key relevant to the rule. I implemented a lot of these
> design patterns for lua-resty-waf, and it's really helped with performance;
> I'd love to share some detailed thoughts on this in a development
> discussion setting. And, as flamegraphs show, there's a lot of std
> container allocation/management that's done that I suspect could be
> optimized away. But these are fundamental design changes that would have a
> major impact, and would require careful study and planning. This is
> something I doubt could be handled by a community contribution.
>

How so? I don't understand why a cache is that difficult to implement. As a
matter of fact, we used cache for transformations because sounds to be a
popular solution and we move back to not have cache as it shown to be bad
for performance.

As illustrared here:
https://github.com/SpiderLabs/ModSecurity/commit/37619bae778183159beee455a5f0d2a0fe02a883#diff-0fae944d3cf096e2fbb8e0063ce0b585



> Ultimately we're talking about a refactor of some significant hot path
> code. And Felipe, please understand that I and the community deeply respect
> the work that's been done on this project, but frankly this doesn't seem to
> be a priority for you, based on the responses in this thread. And if in
> your view I'm way off base in my assumptions, I'd love to hear it, and
> review some data and example execution that contradicts what I, Christian,
> Jai, and Andrei have shown here, and if not, at least an acknowledgement
> from either Trustwave or Nginx that the inclusion of Modsecurity into Nginx
> results in a substantial, meaningful variance in throughput capacity.
>

I cannot foresee how my priorities have to do with this thread :D :)

Performance is a very important subject which have being, and will be, in
discussion forever. It is correct to say that it will always a improvements
to be made. And count on my attention to that.

As a matter of fact, there are a lot of room for improvements. Myself, and
[i think] everybody which uses ModSecurity will be very happy and welcome
to receive your contribution. As we already receive a lot of contributions
from Andrei. You just have to send the patches. As I mentioned before, I am
anxious for that. I think everybody that you mentioned wants to see those
improvements as well.

When do you think you can share something with us?

Is that anything that I can do to help you?

Br.,
Felipe

[mod-security-users] modsecurity rpms for centos 7

[Eero V. <eer...@ik...>]

Hi,

is there modsecurity v3 rpms available for centos 7

Eero