mod-security-developers — Development discussion about mod_security

Re: [Mod-security-developers] Finding triggered RuleIds

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

Hi Jai,

For the current public supported connectors, the rule id altogether with logging text is enough. There is no data structure except for char pointer that point towards the logging string [for the logging attached to the disruptive events]. Is my understanding that it may be useful for your application,  to have an specific field that held to rule id (may other information regarding the rule as well). Having that in mind, we can change the API the make it more useful to your application. Sorry for the inconvenience. Lets discuss out-of-band the specific characteristics of your use case, so we can make the API suits you better.

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

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


From: Jai Harpalani via mod-security-developers <mod...@li...>
Reply-To: "mod...@li..." <mod...@li...>
Date: Thursday, March 21, 2019 at 5:38 PM
To: "mod-security-d." <mod...@li...>
Cc: Jai Harpalani <jai...@mu...>
Subject: Re: [Mod-security-developers] Finding triggered RuleIds

Ervin,

The log callback function approach is what we used with ModSec 3.0.2 and it worked well. Unfortunately, that approach no longer works for ModSec 3.0.3 because not all rule triggers invoke the log callback. Reason for this was provided by Felipe:
Sometimes logging is a consequence of a disruptive action; sometimes the logging is just a warning. On 3.0.2 the logging for disruptive (aka error on 2.x) was being generated as a warning as well. To avoid creating the same message twice, we have changed 3.0.3 to produce only warnings, and give access to error message along with the disruptive structure.

So, I'm trying to determine the recommended approach for acquiring the triggered ruleId(s) in ModSec 3.0.3.

Thanks,

Jai


On Thu, Mar 21, 2019 at 10:29 AM Ervin Hegedüs <ai...@gm...<mailto:ai...@gm...>> wrote:
Hi Jai,

once upon I've discussed about this with @zimmerle, and he helped me with this links:

https://github.com/SpiderLabs/ModSecurity/blob/1ecd9713061c3534626bf6a5f59d1c928c0c52bb/examples/reading_logs_via_rule_message/reading_logs_via_rule_message.h#L141-L142<https://scanmail.trustwave.com/?c=4062&d=4PaT3Ib8KCgqsgIHe59jxLZMn7cvRuyxwHopdLzlMA&s=5&u=https%3a%2f%2fgithub%2ecom%2fSpiderLabs%2fModSecurity%2fblob%2f1ecd9713061c3534626bf6a5f59d1c928c0c52bb%2fexamples%2freading%5flogs%5fvia%5frule%5fmessage%2freading%5flogs%5fvia%5frule%5fmessage%2eh%23L141-L142>
https://github.com/SpiderLabs/ModSecurity/blob/f77db2cc2eff4808ad59118f1a11baea8f849b04/headers/modsecurity/modsecurity.h#L242-L267<https://scanmail.trustwave.com/?c=4062&d=4PaT3Ib8KCgqsgIHe59jxLZMn7cvRuyxwCooce-yMw&s=5&u=https%3a%2f%2fgithub%2ecom%2fSpiderLabs%2fModSecurity%2fblob%2ff77db2cc2eff4808ad59118f1a11baea8f849b04%2fheaders%2fmodsecurity%2fmodsecurity%2eh%23L242-L267>
https://github.com/SpiderLabs/ModSecurity/blob/ad28de4f14e47d3c6b479a1d043f2bd0b7a17706/headers/modsecurity/rule_message.h<https://scanmail.trustwave.com/?c=4062&d=4PaT3Ib8KCgqsgIHe59jxLZMn7cvRuyxwHgrde_mMw&s=5&u=https%3a%2f%2fgithub%2ecom%2fSpiderLabs%2fModSecurity%2fblob%2fad28de4f14e47d3c6b479a1d043f2bd0b7a17706%2fheaders%2fmodsecurity%2frule%5fmessage%2eh>

You can set up a log callbck function, which will got a structure, and you don't need to parse the logfile.

Try this and let me know what you got.


a.


On Thu, Mar 21, 2019 at 3:29 PM Jai Harpalani via mod-security-developers <mod...@li...<mailto:mod...@li...>> wrote:
We are integrating ModSecurity into our product as a library, and using it to evaluate owasp crs rules.

For anyone else doing this, can you explain how your calling code is determining which ruleId(s) were triggered as a result of calling processRequestHeaders(), processRequestBody(), processResponseHeaders(), processResponseBody()?

Curious how this is being done in ModSec 3.0.2 and if it is done differently with version 3.0.3.
_______________________________________________
mod-security-developers mailing list
mod...@li...<mailto:mod...@li...>
https://lists.sourceforge.net/lists/listinfo/mod-security-developers<https://scanmail.trustwave.com/?c=4062&d=4PaT3Ib8KCgqsgIHe59jxLZMn7cvRuyxwH4tKOzmYQ&s=5&u=https%3a%2f%2flists%2esourceforge%2enet%2flists%2flistinfo%2fmod-security-developers>
ModSecurity Services from Trustwave's SpiderLabs:
https://www.trustwave.com/spiderLabs.php
_______________________________________________
mod-security-developers mailing list
mod...@li...<mailto:mod...@li...>
https://lists.sourceforge.net/lists/listinfo/mod-security-developers<https://scanmail.trustwave.com/?c=4062&d=4PaT3Ib8KCgqsgIHe59jxLZMn7cvRuyxwH4tKOzmYQ&s=5&u=https%3a%2f%2flists%2esourceforge%2enet%2flists%2flistinfo%2fmod-security-developers>
ModSecurity Services from Trustwave's SpiderLabs:
https://www.trustwave.com/spiderLabs.php

Re: [Mod-security-developers] Finding triggered RuleIds

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

Ervin,

The log callback function approach is what we used with ModSec 3.0.2 and it
worked well. Unfortunately, that approach no longer works for ModSec 3.0.3
because not all rule triggers invoke the log callback. Reason for this was
provided by Felipe:

Sometimes logging is a consequence of a disruptive action; sometimes the
> logging is just a warning. On 3.0.2 the logging for disruptive (aka error
> on 2.x) was being generated as a warning as well. To avoid creating the
> same message twice, we have changed 3.0.3 to produce only warnings, and
> give access to error message along with the disruptive structure.


So, I'm trying to determine the recommended approach for acquiring the
triggered ruleId(s) in ModSec 3.0.3.

Thanks,

Jai


On Thu, Mar 21, 2019 at 10:29 AM Ervin Hegedüs <ai...@gm...> wrote:

> Hi Jai,
>
> once upon I've discussed about this with @zimmerle, and he helped me with
> this links:
>
>
> https://github.com/SpiderLabs/ModSecurity/blob/1ecd9713061c3534626bf6a5f59d1c928c0c52bb/examples/reading_logs_via_rule_message/reading_logs_via_rule_message.h#L141-L142
>
> https://github.com/SpiderLabs/ModSecurity/blob/f77db2cc2eff4808ad59118f1a11baea8f849b04/headers/modsecurity/modsecurity.h#L242-L267
>
> https://github.com/SpiderLabs/ModSecurity/blob/ad28de4f14e47d3c6b479a1d043f2bd0b7a17706/headers/modsecurity/rule_message.h
>
> You can set up a log callbck function, which will got a structure, and you
> don't need to parse the logfile.
>
> Try this and let me know what you got.
>
>
> a.
>
>
> On Thu, Mar 21, 2019 at 3:29 PM Jai Harpalani via mod-security-developers <
> mod...@li...> wrote:
>
>> We are integrating ModSecurity into our product as a library, and using
>> it to evaluate owasp crs rules.
>>
>> For anyone else doing this, can you explain how your calling code is
>> determining which ruleId(s) were triggered as a result of
>> calling processRequestHeaders(), processRequestBody(),
>> processResponseHeaders(), processResponseBody()?
>>
>> Curious how this is being done in ModSec 3.0.2 and if it is done
>> differently with version 3.0.3.
>> _______________________________________________
>> mod-security-developers mailing list
>> mod...@li...
>> https://lists.sourceforge.net/lists/listinfo/mod-security-developers
>> ModSecurity Services from Trustwave's SpiderLabs:
>> https://www.trustwave.com/spiderLabs.php
>
> _______________________________________________
> mod-security-developers mailing list
> mod...@li...
> https://lists.sourceforge.net/lists/listinfo/mod-security-developers
> ModSecurity Services from Trustwave's SpiderLabs:
> https://www.trustwave.com/spiderLabs.php

Re: [Mod-security-developers] Finding triggered RuleIds

[Ervin H. <ai...@gm...>]

Hi Jai,

once upon I've discussed about this with @zimmerle, and he helped me with
this links:

https://github.com/SpiderLabs/ModSecurity/blob/1ecd9713061c3534626bf6a5f59d1c928c0c52bb/examples/reading_logs_via_rule_message/reading_logs_via_rule_message.h#L141-L142
https://github.com/SpiderLabs/ModSecurity/blob/f77db2cc2eff4808ad59118f1a11baea8f849b04/headers/modsecurity/modsecurity.h#L242-L267
https://github.com/SpiderLabs/ModSecurity/blob/ad28de4f14e47d3c6b479a1d043f2bd0b7a17706/headers/modsecurity/rule_message.h

You can set up a log callbck function, which will got a structure, and you
don't need to parse the logfile.

Try this and let me know what you got.


a.


On Thu, Mar 21, 2019 at 3:29 PM Jai Harpalani via mod-security-developers <
mod...@li...> wrote:

> We are integrating ModSecurity into our product as a library, and using it
> to evaluate owasp crs rules.
>
> For anyone else doing this, can you explain how your calling code is
> determining which ruleId(s) were triggered as a result of
> calling processRequestHeaders(), processRequestBody(),
> processResponseHeaders(), processResponseBody()?
>
> Curious how this is being done in ModSec 3.0.2 and if it is done
> differently with version 3.0.3.
> _______________________________________________
> mod-security-developers mailing list
> mod...@li...
> https://lists.sourceforge.net/lists/listinfo/mod-security-developers
> ModSecurity Services from Trustwave's SpiderLabs:
> https://www.trustwave.com/spiderLabs.php

[Mod-security-developers] Fwd: Question regarding calls to serverLog()

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

---------- Forwarded message ---------
From: Jai Harpalani <jai...@mu...>
Date: Wed, Mar 20, 2019 at 10:29 AM
Subject: Re: [Mod-security-developers] Question regarding calls to
serverLog()
To: Felipe Costa <FC...@tr...>


Felipe,

I looked through the ngx_http_modsecurity_process_intervention (Transaction
*transaction, ngx_http_request_t *r) nginx connector code that you
referenced.

In this code, how does one determine which rule(s) were triggered?

Thanks,

Jai


On Mon, Feb 25, 2019 at 6:46 AM Felipe Costa <FC...@tr...> wrote:

> Hi Jai,
>
> Sometimes logging is a consequence of a disruptive action; sometimes the
> logging is just a warning. On 3.0.2 the logging for disruptive (aka error
> on 2.x) was being generated as a warning as well. To avoid creating the
> same message twice, we have changed 3.0.3 to produce only warnings, and
> give access to error message along with the disruptive structure.
>
> Here is how the ngnix connector is handling it:
>
> https://github.com/SpiderLabs/ModSecurity-nginx/blob/master/src/ngx_http_modsecurity_module.c#L139
>
>
> Yes, performance is better and will be even better for the upcoming
> releases :)
>
> Br.,
>
> *Felipe "Zimmerle" Costa*
>
> Security Researcher, Lead Developer ModSecurity
>
> m: +55 81.98706.5547
>
>
>
> [image: signature_480191669]
>
> *www.trustwave.com <http://www.trustwave.com/>*
>
>
>
> *Recognized by industry analysts as a leader in managed security services.
> <https://www.trustwave.com/company/about-us/accolades/>*
>
> ------------------------------
> *From:* Jai Harpalani via mod-security-developers <
> mod...@li...>
> *Sent:* Wednesday, February 20, 2019 8:32 PM
> *To:* mod-security-d.
> *Cc:* Jai Harpalani
> *Subject:* [Mod-security-developers] Question regarding calls to
> serverLog()
>
> We are integrating ModSecurity into our product as a library, and using it
> to evaluate owasp crs rules. With version 3.0.2, all was working relatively
> well. With version 3.0.3, we are encountering problems. Details below.
>
> We invoke setServerLogCb(ourCallbackMethod) and expect that
> ourCallbackMethod() will be invoked whenever a rule is triggered. This is
> the only way we know a rule has triggered, and this was working with
> version 3.0.2. With 3.0.3, this scheme does not work for all rules.
>
> Looking at the code in rule.cc,
> <http://scanmail.trustwave.com/?c=4062&d=9urt3IzQGylflGxIvXzdwpsVsyjoMmRH3TE5HVEtqg&s=5&u=http%3a%2f%2frule%2ecc>
> I notice that logic surrounding the invocation of trans->serverLog() which
> eventually invokes ourCallbackMethod() has changed. Due to these changes,
> ourCallbackMethod() is not called for all rules.
>
> First question: Why were these changes made, and can they be reverted?
> Second question: Are there other ways for our product-specific code to
> know that a rule has been triggered along with all the information in
> modsecurity::RuleMessage? In other words, are there any other hooks into
> ModSecurity that our product-specific code can use to get this information?
>
> BTW, I am seeing a 2x speedup with version 3.0.3 vs 3.0.2 which is great.
> Good job on making ModSecurity more performant!
>

[Mod-security-developers] Finding triggered RuleIds

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

We are integrating ModSecurity into our product as a library, and using it
to evaluate owasp crs rules.

For anyone else doing this, can you explain how your calling code is
determining which ruleId(s) were triggered as a result of
calling processRequestHeaders(), processRequestBody(),
processResponseHeaders(), processResponseBody()?

Curious how this is being done in ModSec 3.0.2 and if it is done
differently with version 3.0.3.

Re: [Mod-security-developers] HTTPD24 rh sclo availability

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

Good to hear that you managed to hake it working __

Br.,
Felipe “Zimmerle” Costa
Security Researcher, Lead Developer ModSecurity.
 
Trustwave | SMART SECURITY ON DEMAND
www.trustwave.com <http://www.trustwave.com/>
 

On 3/15/19, 2:24 PM, "Brad Zynda via mod-security-developers" <mod...@li...> wrote:

    Sorry meant no dep'ing them in.. need more coffee.
    
    On 3/15/19 12:55 PM, Brad Zynda via mod-security-developers wrote:
    > We seem to have figured these out by rpm no dev'ing them in and creating
    > symlinks.
    > 
    > Seems to work just don't use yum/dnf
    > 
    > Thanks,
    > Brad
    > 
    > On 3/14/19 11:17 AM, Brad Zynda via mod-security-developers wrote:
    >> Hi Felipe,
    >>
    >> It appears Jonathan is no longer the maintainer of mod-evasive per their
    >> documentation:
    >>
    >> <jon...@nu...>: host mail.visionunit.net[148.251.110.67]
    >> said:
    >>     554 5.7.1 <jon...@nu...>: Relay access denied (in
    >> reply to
    >>     RCPT TO command)
    >>
    >> Thanks,
    >> Brad
    >>
    >>
    >> On 3/14/19 10:46 AM, Brad Zynda via mod-security-developers wrote:
    >>> Hi Felipe,
    >>>
    >>> I reviewed the documentation on GIT and see it only supports 1.3 and 2.0
    >>> apache.
    >>>
    >>> I have sent a note to the maintainer as well for documentation or a
    >>> version that will work similar to this one for mod security.
    >>>
    >>> Thanks,
    >>> Brad
    >>>
    >>> On 3/14/19 10:39 AM, Brad Zynda via mod-security-developers wrote:
    >>>> Hi Felipe,
    >>>>
    >>>> Thanks for the info on mod-evasive, I will dig through their changelog.
    >>>> Do you happen to have any info on mod security as well?
    >>>>
    >>>> Thanks,
    >>>> Brad
    >>>>
    >>>> On 3/14/19 10:26 AM, Felipe Zimmerle wrote:
    >>>>> Hi Brad,
    >>>>>
    >>>>> Regarding mod evasive, you may get a better answer here:
    >>>>> https://scanmail.trustwave.com/?c=4062&d=tt-L3BLIlDap5jjVwkeWeq7vVmAiekl9t_xPlGwPFA&s=5&u=https%3a%2f%2furldefense%2eproofpoint%2ecom%2fv2%2furl%3fu%3dhttps-3A%5f%5fgithub%2ecom%5fjzdziarski%5fmod-5Fevasive%26d%3dDwIBaQ%26c%3dApwzowJNAKKw3xye91w7BE1XMRKi2LN9kiMk5Csz9Zk%26r%3dfdpjFOxiMCMp-y3vo7z7JUA9YdTgrS2RUK-LJ49taQg%26m%3dE504AKky7p0c2VO1C0ZNOZutSYcF3qne4p1k85oRxto%26s%3d-Ua99gz93o9R0kAm3HYfihR7oFKlNLtIZLCwv%5fD9twA%26e%3d
    >>>>>
    >>>>> Although, issues related to packing are generally a concern of the
    >>>>> distribution and their contributors.
    >>>>>
    >>>>>
    >>>>> On Wed, Mar 13, 2019 at 12:25 PM Brad Zynda via mod-security-developers <
    >>>>> mod...@li...> wrote:
    >>>>>
    >>>>>> Hello,
    >>>>>>
    >>>>>> Not seeing it listed in the update info specifically and also not seeing
    >>>>>> a mod evasive on a yum search specific to httpd24-mod-*.
    >>>>>>
    >>>>>> Is there a current work around or milestone? Had to update to run the
    >>>>>> latest php7.2.
    >>>>>>
    >>>>>> Thanks,
    >>>>>> Brad
    >>>>>>
    >>>>>>
    >>>>>> _______________________________________________
    >>>>>> mod-security-developers mailing list
    >>>>>> mod...@li...
    >>>>>> https://scanmail.trustwave.com/?c=4062&d=tt-L3BLIlDap5jjVwkeWeq7vVmAiekl9t_0ewjQGFA&s=5&u=https%3a%2f%2furldefense%2eproofpoint%2ecom%2fv2%2furl%3fu%3dhttps-3A%5f%5flists%2esourceforge%2enet%5flists%5flistinfo%5fmod-2Dsecurity-2Ddevelopers%26d%3dDwIBaQ%26c%3dApwzowJNAKKw3xye91w7BE1XMRKi2LN9kiMk5Csz9Zk%26r%3dfdpjFOxiMCMp-y3vo7z7JUA9YdTgrS2RUK-LJ49taQg%26m%3dE504AKky7p0c2VO1C0ZNOZutSYcF3qne4p1k85oRxto%26s%3d8DtYlpg2Y9ztl9KPSY-5T0mPPsj99vWFW6Pvv%5fz2M-k%26e%3d
    >>>>>> ModSecurity Services from Trustwave's SpiderLabs:
    >>>>>> https://scanmail.trustwave.com/?c=4062&d=tt-L3BLIlDap5jjVwkeWeq7vVmAiekl9t6tOwWZWFQ&s=5&u=https%3a%2f%2furldefense%2eproofpoint%2ecom%2fv2%2furl%3fu%3dhttps-3A%5f%5fwww%2etrustwave%2ecom%5fspiderLabs%2ephp%26d%3dDwIBaQ%26c%3dApwzowJNAKKw3xye91w7BE1XMRKi2LN9kiMk5Csz9Zk%26r%3dfdpjFOxiMCMp-y3vo7z7JUA9YdTgrS2RUK-LJ49taQg%26m%3dE504AKky7p0c2VO1C0ZNOZutSYcF3qne4p1k85oRxto%26s%3dn0JFSyzjZE-I-XoEP0m9yVjjCYWwXrpLPDcKVcJaAPI%26e%3d
    >>>>>>
    >>>>>
    >>>>>
    >>>>>
    >>>>>
    >>>>> _______________________________________________
    >>>>> mod-security-developers mailing list
    >>>>> mod...@li...
    >>>>> https://scanmail.trustwave.com/?c=4062&d=tt-L3BLIlDap5jjVwkeWeq7vVmAiekl9t69IljcAEw&s=5&u=https%3a%2f%2furldefense%2eproofpoint%2ecom%2fv2%2furl%3fu%3dhttps-3A%5f%5flists%2esourceforge%2enet%5flists%5flistinfo%5fmod-2Dsecurity-2Ddevelopers%26d%3dDwICAg%26c%3dApwzowJNAKKw3xye91w7BE1XMRKi2LN9kiMk5Csz9Zk%26r%3dfdpjFOxiMCMp-y3vo7z7JUA9YdTgrS2RUK-LJ49taQg%26m%3dE504AKky7p0c2VO1C0ZNOZutSYcF3qne4p1k85oRxto%26s%3d8DtYlpg2Y9ztl9KPSY-5T0mPPsj99vWFW6Pvv%5fz2M-k%26e%3d
    >>>>> ModSecurity Services from Trustwave's SpiderLabs:
    >>>>> https://scanmail.trustwave.com/?c=4062&d=tt-L3BLIlDap5jjVwkeWeq7vVmAiekl9t61Ox2APQw&s=5&u=https%3a%2f%2furldefense%2eproofpoint%2ecom%2fv2%2furl%3fu%3dhttps-3A%5f%5fwww%2etrustwave%2ecom%5fspiderLabs%2ephp%26d%3dDwICAg%26c%3dApwzowJNAKKw3xye91w7BE1XMRKi2LN9kiMk5Csz9Zk%26r%3dfdpjFOxiMCMp-y3vo7z7JUA9YdTgrS2RUK-LJ49taQg%26m%3dE504AKky7p0c2VO1C0ZNOZutSYcF3qne4p1k85oRxto%26s%3dn0JFSyzjZE-I-XoEP0m9yVjjCYWwXrpLPDcKVcJaAPI%26e%3d
    >>>>>
    >>>>
    >>>>
    >>>> _______________________________________________
    >>>> mod-security-developers mailing list
    >>>> mod...@li...
    >>>> https://scanmail.trustwave.com/?c=4062&d=tt-L3BLIlDap5jjVwkeWeq7vVmAiekl9t69GljMAQQ&s=5&u=https%3a%2f%2furldefense%2eproofpoint%2ecom%2fv2%2furl%3fu%3dhttps-3A%5f%5flists%2esourceforge%2enet%5flists%5flistinfo%5fmod-2Dsecurity-2Ddevelopers%26d%3dDwICAg%26c%3dApwzowJNAKKw3xye91w7BE1XMRKi2LN9kiMk5Csz9Zk%26r%3dfdpjFOxiMCMp-y3vo7z7JUA9YdTgrS2RUK-LJ49taQg%26m%3dDFJ7aSlNcy3E31fLniEr318DA5rySzBGNaMZb2BvcdI%26s%3dnorEMduzsoMGhfPb3t71uubJGs4LXOgZaxf2tLj5wJ0%26e%3d
    >>>> ModSecurity Services from Trustwave's SpiderLabs:
    >>>> https://scanmail.trustwave.com/?c=4062&d=tt-L3BLIlDap5jjVwkeWeq7vVmAiekl9t_xHxTdSQw&s=5&u=https%3a%2f%2furldefense%2eproofpoint%2ecom%2fv2%2furl%3fu%3dhttps-3A%5f%5fwww%2etrustwave%2ecom%5fspiderLabs%2ephp%26d%3dDwICAg%26c%3dApwzowJNAKKw3xye91w7BE1XMRKi2LN9kiMk5Csz9Zk%26r%3dfdpjFOxiMCMp-y3vo7z7JUA9YdTgrS2RUK-LJ49taQg%26m%3dDFJ7aSlNcy3E31fLniEr318DA5rySzBGNaMZb2BvcdI%26s%3dvM8CSs7i0ybefnmAa%5fSosdUpOOlVCIQex0GhMYmtVX4%26e%3d
    >>>>
    >>>
    >>>
    >>> _______________________________________________
    >>> mod-security-developers mailing list
    >>> mod...@li...
    >>> https://scanmail.trustwave.com/?c=4062&d=tt-L3BLIlDap5jjVwkeWeq7vVmAiekl9t_xKlTYGFA&s=5&u=https%3a%2f%2furldefense%2eproofpoint%2ecom%2fv2%2furl%3fu%3dhttps-3A%5f%5flists%2esourceforge%2enet%5flists%5flistinfo%5fmod-2Dsecurity-2Ddevelopers%26d%3dDwICAg%26c%3dApwzowJNAKKw3xye91w7BE1XMRKi2LN9kiMk5Csz9Zk%26r%3dfdpjFOxiMCMp-y3vo7z7JUA9YdTgrS2RUK-LJ49taQg%26m%3ddq-NVbVWC5ZYihVMmk086tTXFngd9jW4ZVAoVP7vMEE%26s%3d31ndn4faJoA7NQfKsAqof93wvK2A28SrfwQXVlsN1SU%26e%3d
    >>> ModSecurity Services from Trustwave's SpiderLabs:
    >>> https://scanmail.trustwave.com/?c=4062&d=tt-L3BLIlDap5jjVwkeWeq7vVmAiekl9t60anDFTTw&s=5&u=https%3a%2f%2furldefense%2eproofpoint%2ecom%2fv2%2furl%3fu%3dhttps-3A%5f%5fwww%2etrustwave%2ecom%5fspiderLabs%2ephp%26d%3dDwICAg%26c%3dApwzowJNAKKw3xye91w7BE1XMRKi2LN9kiMk5Csz9Zk%26r%3dfdpjFOxiMCMp-y3vo7z7JUA9YdTgrS2RUK-LJ49taQg%26m%3ddq-NVbVWC5ZYihVMmk086tTXFngd9jW4ZVAoVP7vMEE%26s%3dyI0fsEarHTCnGI48LAJ7bLIYMccAM5LzjIhRFhwIl5M%26e%3d
    >>>
    >>
    >>
    >> _______________________________________________
    >> mod-security-developers mailing list
    >> mod...@li...
    >> https://scanmail.trustwave.com/?c=4062&d=tt-L3BLIlDap5jjVwkeWeq7vVmAiekl9t_0ekmVRTg&s=5&u=https%3a%2f%2furldefense%2eproofpoint%2ecom%2fv2%2furl%3fu%3dhttps-3A%5f%5flists%2esourceforge%2enet%5flists%5flistinfo%5fmod-2Dsecurity-2Ddevelopers%26d%3dDwICAg%26c%3dApwzowJNAKKw3xye91w7BE1XMRKi2LN9kiMk5Csz9Zk%26r%3dfdpjFOxiMCMp-y3vo7z7JUA9YdTgrS2RUK-LJ49taQg%26m%3dZ-xC%5fDGF5YRkY9btoMTaQSvLRKJDLKUhUekM7PG7Wzk%26s%3da-FFAK2lhinw3pX4P2-NjdFpB%5f1wMeJbeiwz3Ty7iq0%26e%3d
    >> ModSecurity Services from Trustwave's SpiderLabs:
    >> https://scanmail.trustwave.com/?c=4062&d=tt-L3BLIlDap5jjVwkeWeq7vVmAiekl9t6lGxTRVFQ&s=5&u=https%3a%2f%2furldefense%2eproofpoint%2ecom%2fv2%2furl%3fu%3dhttps-3A%5f%5fwww%2etrustwave%2ecom%5fspiderLabs%2ephp%26d%3dDwICAg%26c%3dApwzowJNAKKw3xye91w7BE1XMRKi2LN9kiMk5Csz9Zk%26r%3dfdpjFOxiMCMp-y3vo7z7JUA9YdTgrS2RUK-LJ49taQg%26m%3dZ-xC%5fDGF5YRkY9btoMTaQSvLRKJDLKUhUekM7PG7Wzk%26s%3dn7oSuZP0InKRnXJqILXY7-v9KxxI%5fCRJmnQ-7VPkvQA%26e%3d
    >>
    > 
    > 
    > _______________________________________________
    > mod-security-developers mailing list
    > mod...@li...
    > https://scanmail.trustwave.com/?c=4062&d=tt-L3BLIlDap5jjVwkeWeq7vVmAiekl9t_xMnGMBFQ&s=5&u=https%3a%2f%2furldefense%2eproofpoint%2ecom%2fv2%2furl%3fu%3dhttps-3A%5f%5flists%2esourceforge%2enet%5flists%5flistinfo%5fmod-2Dsecurity-2Ddevelopers%26d%3dDwICAg%26c%3dApwzowJNAKKw3xye91w7BE1XMRKi2LN9kiMk5Csz9Zk%26r%3dfdpjFOxiMCMp-y3vo7z7JUA9YdTgrS2RUK-LJ49taQg%26m%3dDsvYbWMsfs9G%5ftOgu6ofJ9QDZjEny9YtSQvnQ1VAtgc%26s%3dAAgVBtihTgiXFWGKvginiS1Z9n1wfVX2LlgBH0CXPHM%26e%3d
    > ModSecurity Services from Trustwave's SpiderLabs:
    > https://scanmail.trustwave.com/?c=4062&d=tt-L3BLIlDap5jjVwkeWeq7vVmAiekl9t_sex21TRQ&s=5&u=https%3a%2f%2furldefense%2eproofpoint%2ecom%2fv2%2furl%3fu%3dhttps-3A%5f%5fwww%2etrustwave%2ecom%5fspiderLabs%2ephp%26d%3dDwICAg%26c%3dApwzowJNAKKw3xye91w7BE1XMRKi2LN9kiMk5Csz9Zk%26r%3dfdpjFOxiMCMp-y3vo7z7JUA9YdTgrS2RUK-LJ49taQg%26m%3dDsvYbWMsfs9G%5ftOgu6ofJ9QDZjEny9YtSQvnQ1VAtgc%26s%3dHjV5XFYZVYRBgWELQanl86xwyK2ZTW6nD5g9VS8GTaY%26e%3d
    > 
    
    
    _______________________________________________
    mod-security-developers mailing list
    mod...@li...
    https://scanmail.trustwave.com/?c=4062&d=tt-L3BLIlDap5jjVwkeWeq7vVmAiekl9t6hMnGEAEw&s=5&u=https%3a%2f%2flists%2esourceforge%2enet%2flists%2flistinfo%2fmod-security-developers
    ModSecurity Services from Trustwave's SpiderLabs:
    https://www.trustwave.com/spiderLabs.php
    

Re: [Mod-security-developers] HTTPD24 rh sclo availability

[Brad Z. <bra...@na...>]

Sorry meant no dep'ing them in.. need more coffee.

On 3/15/19 12:55 PM, Brad Zynda via mod-security-developers wrote:
> We seem to have figured these out by rpm no dev'ing them in and creating
> symlinks.
> 
> Seems to work just don't use yum/dnf
> 
> Thanks,
> Brad
> 
> On 3/14/19 11:17 AM, Brad Zynda via mod-security-developers wrote:
>> Hi Felipe,
>>
>> It appears Jonathan is no longer the maintainer of mod-evasive per their
>> documentation:
>>
>> <jon...@nu...>: host mail.visionunit.net[148.251.110.67]
>> said:
>>     554 5.7.1 <jon...@nu...>: Relay access denied (in
>> reply to
>>     RCPT TO command)
>>
>> Thanks,
>> Brad
>>
>>
>> On 3/14/19 10:46 AM, Brad Zynda via mod-security-developers wrote:
>>> Hi Felipe,
>>>
>>> I reviewed the documentation on GIT and see it only supports 1.3 and 2.0
>>> apache.
>>>
>>> I have sent a note to the maintainer as well for documentation or a
>>> version that will work similar to this one for mod security.
>>>
>>> Thanks,
>>> Brad
>>>
>>> On 3/14/19 10:39 AM, Brad Zynda via mod-security-developers wrote:
>>>> Hi Felipe,
>>>>
>>>> Thanks for the info on mod-evasive, I will dig through their changelog.
>>>> Do you happen to have any info on mod security as well?
>>>>
>>>> Thanks,
>>>> Brad
>>>>
>>>> On 3/14/19 10:26 AM, Felipe Zimmerle wrote:
>>>>> Hi Brad,
>>>>>
>>>>> Regarding mod evasive, you may get a better answer here:
>>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_jzdziarski_mod-5Fevasive&d=DwIBaQ&c=ApwzowJNAKKw3xye91w7BE1XMRKi2LN9kiMk5Csz9Zk&r=fdpjFOxiMCMp-y3vo7z7JUA9YdTgrS2RUK-LJ49taQg&m=E504AKky7p0c2VO1C0ZNOZutSYcF3qne4p1k85oRxto&s=-Ua99gz93o9R0kAm3HYfihR7oFKlNLtIZLCwv_D9twA&e=
>>>>>
>>>>> Although, issues related to packing are generally a concern of the
>>>>> distribution and their contributors.
>>>>>
>>>>>
>>>>> On Wed, Mar 13, 2019 at 12:25 PM Brad Zynda via mod-security-developers <
>>>>> mod...@li...> wrote:
>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> Not seeing it listed in the update info specifically and also not seeing
>>>>>> a mod evasive on a yum search specific to httpd24-mod-*.
>>>>>>
>>>>>> Is there a current work around or milestone? Had to update to run the
>>>>>> latest php7.2.
>>>>>>
>>>>>> Thanks,
>>>>>> Brad
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> mod-security-developers mailing list
>>>>>> mod...@li...
>>>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.sourceforge.net_lists_listinfo_mod-2Dsecurity-2Ddevelopers&d=DwIBaQ&c=ApwzowJNAKKw3xye91w7BE1XMRKi2LN9kiMk5Csz9Zk&r=fdpjFOxiMCMp-y3vo7z7JUA9YdTgrS2RUK-LJ49taQg&m=E504AKky7p0c2VO1C0ZNOZutSYcF3qne4p1k85oRxto&s=8DtYlpg2Y9ztl9KPSY-5T0mPPsj99vWFW6Pvv_z2M-k&e=
>>>>>> ModSecurity Services from Trustwave's SpiderLabs:
>>>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.trustwave.com_spiderLabs.php&d=DwIBaQ&c=ApwzowJNAKKw3xye91w7BE1XMRKi2LN9kiMk5Csz9Zk&r=fdpjFOxiMCMp-y3vo7z7JUA9YdTgrS2RUK-LJ49taQg&m=E504AKky7p0c2VO1C0ZNOZutSYcF3qne4p1k85oRxto&s=n0JFSyzjZE-I-XoEP0m9yVjjCYWwXrpLPDcKVcJaAPI&e=
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> mod-security-developers mailing list
>>>>> mod...@li...
>>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.sourceforge.net_lists_listinfo_mod-2Dsecurity-2Ddevelopers&d=DwICAg&c=ApwzowJNAKKw3xye91w7BE1XMRKi2LN9kiMk5Csz9Zk&r=fdpjFOxiMCMp-y3vo7z7JUA9YdTgrS2RUK-LJ49taQg&m=E504AKky7p0c2VO1C0ZNOZutSYcF3qne4p1k85oRxto&s=8DtYlpg2Y9ztl9KPSY-5T0mPPsj99vWFW6Pvv_z2M-k&e=
>>>>> ModSecurity Services from Trustwave's SpiderLabs:
>>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.trustwave.com_spiderLabs.php&d=DwICAg&c=ApwzowJNAKKw3xye91w7BE1XMRKi2LN9kiMk5Csz9Zk&r=fdpjFOxiMCMp-y3vo7z7JUA9YdTgrS2RUK-LJ49taQg&m=E504AKky7p0c2VO1C0ZNOZutSYcF3qne4p1k85oRxto&s=n0JFSyzjZE-I-XoEP0m9yVjjCYWwXrpLPDcKVcJaAPI&e=
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> mod-security-developers mailing list
>>>> mod...@li...
>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.sourceforge.net_lists_listinfo_mod-2Dsecurity-2Ddevelopers&d=DwICAg&c=ApwzowJNAKKw3xye91w7BE1XMRKi2LN9kiMk5Csz9Zk&r=fdpjFOxiMCMp-y3vo7z7JUA9YdTgrS2RUK-LJ49taQg&m=DFJ7aSlNcy3E31fLniEr318DA5rySzBGNaMZb2BvcdI&s=norEMduzsoMGhfPb3t71uubJGs4LXOgZaxf2tLj5wJ0&e=
>>>> ModSecurity Services from Trustwave's SpiderLabs:
>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.trustwave.com_spiderLabs.php&d=DwICAg&c=ApwzowJNAKKw3xye91w7BE1XMRKi2LN9kiMk5Csz9Zk&r=fdpjFOxiMCMp-y3vo7z7JUA9YdTgrS2RUK-LJ49taQg&m=DFJ7aSlNcy3E31fLniEr318DA5rySzBGNaMZb2BvcdI&s=vM8CSs7i0ybefnmAa_SosdUpOOlVCIQex0GhMYmtVX4&e=
>>>>
>>>
>>>
>>> _______________________________________________
>>> mod-security-developers mailing list
>>> mod...@li...
>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.sourceforge.net_lists_listinfo_mod-2Dsecurity-2Ddevelopers&d=DwICAg&c=ApwzowJNAKKw3xye91w7BE1XMRKi2LN9kiMk5Csz9Zk&r=fdpjFOxiMCMp-y3vo7z7JUA9YdTgrS2RUK-LJ49taQg&m=dq-NVbVWC5ZYihVMmk086tTXFngd9jW4ZVAoVP7vMEE&s=31ndn4faJoA7NQfKsAqof93wvK2A28SrfwQXVlsN1SU&e=
>>> ModSecurity Services from Trustwave's SpiderLabs:
>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.trustwave.com_spiderLabs.php&d=DwICAg&c=ApwzowJNAKKw3xye91w7BE1XMRKi2LN9kiMk5Csz9Zk&r=fdpjFOxiMCMp-y3vo7z7JUA9YdTgrS2RUK-LJ49taQg&m=dq-NVbVWC5ZYihVMmk086tTXFngd9jW4ZVAoVP7vMEE&s=yI0fsEarHTCnGI48LAJ7bLIYMccAM5LzjIhRFhwIl5M&e=
>>>
>>
>>
>> _______________________________________________
>> mod-security-developers mailing list
>> mod...@li...
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.sourceforge.net_lists_listinfo_mod-2Dsecurity-2Ddevelopers&d=DwICAg&c=ApwzowJNAKKw3xye91w7BE1XMRKi2LN9kiMk5Csz9Zk&r=fdpjFOxiMCMp-y3vo7z7JUA9YdTgrS2RUK-LJ49taQg&m=Z-xC_DGF5YRkY9btoMTaQSvLRKJDLKUhUekM7PG7Wzk&s=a-FFAK2lhinw3pX4P2-NjdFpB_1wMeJbeiwz3Ty7iq0&e=
>> ModSecurity Services from Trustwave's SpiderLabs:
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.trustwave.com_spiderLabs.php&d=DwICAg&c=ApwzowJNAKKw3xye91w7BE1XMRKi2LN9kiMk5Csz9Zk&r=fdpjFOxiMCMp-y3vo7z7JUA9YdTgrS2RUK-LJ49taQg&m=Z-xC_DGF5YRkY9btoMTaQSvLRKJDLKUhUekM7PG7Wzk&s=n7oSuZP0InKRnXJqILXY7-v9KxxI_CRJmnQ-7VPkvQA&e=
>>
> 
> 
> _______________________________________________
> mod-security-developers mailing list
> mod...@li...
> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.sourceforge.net_lists_listinfo_mod-2Dsecurity-2Ddevelopers&d=DwICAg&c=ApwzowJNAKKw3xye91w7BE1XMRKi2LN9kiMk5Csz9Zk&r=fdpjFOxiMCMp-y3vo7z7JUA9YdTgrS2RUK-LJ49taQg&m=DsvYbWMsfs9G_tOgu6ofJ9QDZjEny9YtSQvnQ1VAtgc&s=AAgVBtihTgiXFWGKvginiS1Z9n1wfVX2LlgBH0CXPHM&e=
> ModSecurity Services from Trustwave's SpiderLabs:
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.trustwave.com_spiderLabs.php&d=DwICAg&c=ApwzowJNAKKw3xye91w7BE1XMRKi2LN9kiMk5Csz9Zk&r=fdpjFOxiMCMp-y3vo7z7JUA9YdTgrS2RUK-LJ49taQg&m=DsvYbWMsfs9G_tOgu6ofJ9QDZjEny9YtSQvnQ1VAtgc&s=HjV5XFYZVYRBgWELQanl86xwyK2ZTW6nD5g9VS8GTaY&e=
> 

Re: [Mod-security-developers] HTTPD24 rh sclo availability

[Brad Z. <bra...@na...>]

We seem to have figured these out by rpm no dev'ing them in and creating
symlinks.

Seems to work just don't use yum/dnf

Thanks,
Brad

On 3/14/19 11:17 AM, Brad Zynda via mod-security-developers wrote:
> Hi Felipe,
> 
> It appears Jonathan is no longer the maintainer of mod-evasive per their
> documentation:
> 
> <jon...@nu...>: host mail.visionunit.net[148.251.110.67]
> said:
>     554 5.7.1 <jon...@nu...>: Relay access denied (in
> reply to
>     RCPT TO command)
> 
> Thanks,
> Brad
> 
> 
> On 3/14/19 10:46 AM, Brad Zynda via mod-security-developers wrote:
>> Hi Felipe,
>>
>> I reviewed the documentation on GIT and see it only supports 1.3 and 2.0
>> apache.
>>
>> I have sent a note to the maintainer as well for documentation or a
>> version that will work similar to this one for mod security.
>>
>> Thanks,
>> Brad
>>
>> On 3/14/19 10:39 AM, Brad Zynda via mod-security-developers wrote:
>>> Hi Felipe,
>>>
>>> Thanks for the info on mod-evasive, I will dig through their changelog.
>>> Do you happen to have any info on mod security as well?
>>>
>>> Thanks,
>>> Brad
>>>
>>> On 3/14/19 10:26 AM, Felipe Zimmerle wrote:
>>>> Hi Brad,
>>>>
>>>> Regarding mod evasive, you may get a better answer here:
>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_jzdziarski_mod-5Fevasive&d=DwIBaQ&c=ApwzowJNAKKw3xye91w7BE1XMRKi2LN9kiMk5Csz9Zk&r=fdpjFOxiMCMp-y3vo7z7JUA9YdTgrS2RUK-LJ49taQg&m=E504AKky7p0c2VO1C0ZNOZutSYcF3qne4p1k85oRxto&s=-Ua99gz93o9R0kAm3HYfihR7oFKlNLtIZLCwv_D9twA&e=
>>>>
>>>> Although, issues related to packing are generally a concern of the
>>>> distribution and their contributors.
>>>>
>>>>
>>>> On Wed, Mar 13, 2019 at 12:25 PM Brad Zynda via mod-security-developers <
>>>> mod...@li...> wrote:
>>>>
>>>>> Hello,
>>>>>
>>>>> Not seeing it listed in the update info specifically and also not seeing
>>>>> a mod evasive on a yum search specific to httpd24-mod-*.
>>>>>
>>>>> Is there a current work around or milestone? Had to update to run the
>>>>> latest php7.2.
>>>>>
>>>>> Thanks,
>>>>> Brad
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> mod-security-developers mailing list
>>>>> mod...@li...
>>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.sourceforge.net_lists_listinfo_mod-2Dsecurity-2Ddevelopers&d=DwIBaQ&c=ApwzowJNAKKw3xye91w7BE1XMRKi2LN9kiMk5Csz9Zk&r=fdpjFOxiMCMp-y3vo7z7JUA9YdTgrS2RUK-LJ49taQg&m=E504AKky7p0c2VO1C0ZNOZutSYcF3qne4p1k85oRxto&s=8DtYlpg2Y9ztl9KPSY-5T0mPPsj99vWFW6Pvv_z2M-k&e=
>>>>> ModSecurity Services from Trustwave's SpiderLabs:
>>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.trustwave.com_spiderLabs.php&d=DwIBaQ&c=ApwzowJNAKKw3xye91w7BE1XMRKi2LN9kiMk5Csz9Zk&r=fdpjFOxiMCMp-y3vo7z7JUA9YdTgrS2RUK-LJ49taQg&m=E504AKky7p0c2VO1C0ZNOZutSYcF3qne4p1k85oRxto&s=n0JFSyzjZE-I-XoEP0m9yVjjCYWwXrpLPDcKVcJaAPI&e=
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> mod-security-developers mailing list
>>>> mod...@li...
>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.sourceforge.net_lists_listinfo_mod-2Dsecurity-2Ddevelopers&d=DwICAg&c=ApwzowJNAKKw3xye91w7BE1XMRKi2LN9kiMk5Csz9Zk&r=fdpjFOxiMCMp-y3vo7z7JUA9YdTgrS2RUK-LJ49taQg&m=E504AKky7p0c2VO1C0ZNOZutSYcF3qne4p1k85oRxto&s=8DtYlpg2Y9ztl9KPSY-5T0mPPsj99vWFW6Pvv_z2M-k&e=
>>>> ModSecurity Services from Trustwave's SpiderLabs:
>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.trustwave.com_spiderLabs.php&d=DwICAg&c=ApwzowJNAKKw3xye91w7BE1XMRKi2LN9kiMk5Csz9Zk&r=fdpjFOxiMCMp-y3vo7z7JUA9YdTgrS2RUK-LJ49taQg&m=E504AKky7p0c2VO1C0ZNOZutSYcF3qne4p1k85oRxto&s=n0JFSyzjZE-I-XoEP0m9yVjjCYWwXrpLPDcKVcJaAPI&e=
>>>>
>>>
>>>
>>> _______________________________________________
>>> mod-security-developers mailing list
>>> mod...@li...
>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.sourceforge.net_lists_listinfo_mod-2Dsecurity-2Ddevelopers&d=DwICAg&c=ApwzowJNAKKw3xye91w7BE1XMRKi2LN9kiMk5Csz9Zk&r=fdpjFOxiMCMp-y3vo7z7JUA9YdTgrS2RUK-LJ49taQg&m=DFJ7aSlNcy3E31fLniEr318DA5rySzBGNaMZb2BvcdI&s=norEMduzsoMGhfPb3t71uubJGs4LXOgZaxf2tLj5wJ0&e=
>>> ModSecurity Services from Trustwave's SpiderLabs:
>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.trustwave.com_spiderLabs.php&d=DwICAg&c=ApwzowJNAKKw3xye91w7BE1XMRKi2LN9kiMk5Csz9Zk&r=fdpjFOxiMCMp-y3vo7z7JUA9YdTgrS2RUK-LJ49taQg&m=DFJ7aSlNcy3E31fLniEr318DA5rySzBGNaMZb2BvcdI&s=vM8CSs7i0ybefnmAa_SosdUpOOlVCIQex0GhMYmtVX4&e=
>>>
>>
>>
>> _______________________________________________
>> mod-security-developers mailing list
>> mod...@li...
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.sourceforge.net_lists_listinfo_mod-2Dsecurity-2Ddevelopers&d=DwICAg&c=ApwzowJNAKKw3xye91w7BE1XMRKi2LN9kiMk5Csz9Zk&r=fdpjFOxiMCMp-y3vo7z7JUA9YdTgrS2RUK-LJ49taQg&m=dq-NVbVWC5ZYihVMmk086tTXFngd9jW4ZVAoVP7vMEE&s=31ndn4faJoA7NQfKsAqof93wvK2A28SrfwQXVlsN1SU&e=
>> ModSecurity Services from Trustwave's SpiderLabs:
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.trustwave.com_spiderLabs.php&d=DwICAg&c=ApwzowJNAKKw3xye91w7BE1XMRKi2LN9kiMk5Csz9Zk&r=fdpjFOxiMCMp-y3vo7z7JUA9YdTgrS2RUK-LJ49taQg&m=dq-NVbVWC5ZYihVMmk086tTXFngd9jW4ZVAoVP7vMEE&s=yI0fsEarHTCnGI48LAJ7bLIYMccAM5LzjIhRFhwIl5M&e=
>>
> 
> 
> _______________________________________________
> mod-security-developers mailing list
> mod...@li...
> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.sourceforge.net_lists_listinfo_mod-2Dsecurity-2Ddevelopers&d=DwICAg&c=ApwzowJNAKKw3xye91w7BE1XMRKi2LN9kiMk5Csz9Zk&r=fdpjFOxiMCMp-y3vo7z7JUA9YdTgrS2RUK-LJ49taQg&m=Z-xC_DGF5YRkY9btoMTaQSvLRKJDLKUhUekM7PG7Wzk&s=a-FFAK2lhinw3pX4P2-NjdFpB_1wMeJbeiwz3Ty7iq0&e=
> ModSecurity Services from Trustwave's SpiderLabs:
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.trustwave.com_spiderLabs.php&d=DwICAg&c=ApwzowJNAKKw3xye91w7BE1XMRKi2LN9kiMk5Csz9Zk&r=fdpjFOxiMCMp-y3vo7z7JUA9YdTgrS2RUK-LJ49taQg&m=Z-xC_DGF5YRkY9btoMTaQSvLRKJDLKUhUekM7PG7Wzk&s=n7oSuZP0InKRnXJqILXY7-v9KxxI_CRJmnQ-7VPkvQA&e=
> 

Re: [Mod-security-developers] Request body processed when blocking in phase 1

[Marc S. <mar...@ap...>]

Everything is compiled with the same version of VS.
Same result on CentOS 7 fully update with the platform httpd and only MS custom compiled.

If I compile without --enable-request-early, phase 1 rules will actually run in phase 2, so the request body will indeed be received by httpd. This is the expected behaviour, no?

On 14-03-19 15:18, Felipe Zimmerle wrote:
Great, so we have:

Apache on Windows running a customized version ModSecurity compiled with VisualStudio.

Let me ask you this: are the libApr, Apache and ModSecurity compiled with the same VisualStudio family?

Do the Apache binaries cames from Apache Lounge? Without the "--enable-request-early"  but, yet, with a custom windows compilation, did you manage to see a different result?

Br.,
Felipe.


On Wed, Mar 13, 2019 at 5:24 AM Marc Stern <mar...@ap...<mailto:mar...@ap...>> wrote:
I'm using the Apache version (also) under Windows.
I defined REQUEST_EARLY in Visual Studio.

Marc

On 13-03-19 03:01, Felipe Costa wrote:
How you have recompiled the windows version with enable-request-early? What is your IIS version?

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

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


From: Marc Stern <mar...@ap...><mailto:mar...@ap...>
Reply-To: Marc Stern <mar...@ap...><mailto:mar...@ap...>
Date: Tuesday, March 12, 2019 at 12:39 PM
To: Felipe Costa <FC...@tr...><mailto:FC...@tr...>, "mod...@li..."<mailto:mod...@li...> <mod...@li...><mailto:mod...@li...>
Subject: Re: Request body processed when blocking in phase 1

I reproduced this behaviour even in Windows with everything compiled together

Marc
On 11-03-19 14:22, Felipe Costa wrote:
I have seemed the behavior that you have described in servers with APR version mismatch. Other than that, I did not manage to emulate such behavior.


Br.,

Felipe "Zimmerle" Costa

Security Researcher, Lead Developer ModSecurity

m: +55 81.98706.5547



[signature_480191669]

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



Recognized by industry analysts as a leader in managed security services.<https://www.trustwave.com/company/about-us/accolades/>

________________________________
From: Marc Stern <mar...@ap...><mailto:mar...@ap...>
Sent: Thursday, February 28, 2019 11:49 AM
To: mod...@li...<mailto:mod...@li...>
Subject: [Mod-security-developers] Request body processed when blocking in phase 1

I'm running v 2.9.3 built with --enable-request-early to have phase 1
rules running before receiving the body.
If I sent a huge body, the request is well blocked in phase 1 but
there's a huge processing time (10 min for 1.5 MB) on a strong machine
after hook_insert_error_filter()
Can somebody explain me what could happen and/or how to troubleshoot that.
Isn't the phase 1 rule (with --enable-request-early) supposed to run
before the request body is received by httpd?

Here's the debug log (max level):
[28/Feb/2019:14:27:50 +0100] [...][4] Ctl: Set requestBodyAccess to 0.
[...]
[28/Feb/2019:14:27:50 +0100] [...][4] Access denied with code 404 (phase
1). [...]
[28/Feb/2019:14:27:50 +0100] [...][4] Hook insert_error_filter: Adding
output filter (r 248029de120).
[28/Feb/2019:14:37:20 +0100] [...][9] Output filter: Receiving output (f
24802c82a38, r 248029de120).
[28/Feb/2019:14:37:20 +0100] [...][4] Skipping phase 3 as request was
already intercepted.

error log:
[Thu Feb 28 14:27:50.864432 2019] [core:trace5] [pid 6060:tid 2008]
protocol.c(614): [client ...] Request received from client: POST /...
HTTP/1.1
[Thu Feb 28 14:37:20.529622 2019] [headers:debug] [pid 6060:tid 2008]
mod_headers.c(908): AH01503: headers: ap_headers_error_filter()

Marc

_______________________________________________
mod-security-developers mailing list
mod...@li...<mailto:mod...@li...>
https://scanmail.trustwave.com/?c=4062&d=kv333Abx-vXiIBZ1YneBxeM0MfaUkB_XCXnlDQQiBg&s=5&u=https%3a%2f%2flists%2esourceforge%2enet%2flists%2flistinfo%2fmod-security-developers<https://scanmail.trustwave.com/?c=4062&d=yNKH3MMlr2fvDpZSllszGJ_gvfkIiM0oQRMGgD8iLQ&s=5&u=https%3a%2f%2flists%2esourceforge%2enet%2flists%2flistinfo%2fmod-security-developers>
ModSecurity Services from Trustwave's SpiderLabs:
https://www.trustwave.com/spiderLabs.php



_______________________________________________
mod-security-developers mailing list
mod...@li...<mailto:mod...@li...>
https://lists.sourceforge.net/lists/listinfo/mod-security-developers
ModSecurity Services from Trustwave's SpiderLabs:
https://www.trustwave.com/spiderLabs.php


--
Br.,
Felipe Zimmerle

Re: [Mod-security-developers] HTTPD24 rh sclo availability

[Brad Z. <bra...@na...>]

Hi Felipe,

It appears Jonathan is no longer the maintainer of mod-evasive per their
documentation:

<jon...@nu...>: host mail.visionunit.net[148.251.110.67]
said:
    554 5.7.1 <jon...@nu...>: Relay access denied (in
reply to
    RCPT TO command)

Thanks,
Brad


On 3/14/19 10:46 AM, Brad Zynda via mod-security-developers wrote:
> Hi Felipe,
> 
> I reviewed the documentation on GIT and see it only supports 1.3 and 2.0
> apache.
> 
> I have sent a note to the maintainer as well for documentation or a
> version that will work similar to this one for mod security.
> 
> Thanks,
> Brad
> 
> On 3/14/19 10:39 AM, Brad Zynda via mod-security-developers wrote:
>> Hi Felipe,
>>
>> Thanks for the info on mod-evasive, I will dig through their changelog.
>> Do you happen to have any info on mod security as well?
>>
>> Thanks,
>> Brad
>>
>> On 3/14/19 10:26 AM, Felipe Zimmerle wrote:
>>> Hi Brad,
>>>
>>> Regarding mod evasive, you may get a better answer here:
>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_jzdziarski_mod-5Fevasive&d=DwIBaQ&c=ApwzowJNAKKw3xye91w7BE1XMRKi2LN9kiMk5Csz9Zk&r=fdpjFOxiMCMp-y3vo7z7JUA9YdTgrS2RUK-LJ49taQg&m=E504AKky7p0c2VO1C0ZNOZutSYcF3qne4p1k85oRxto&s=-Ua99gz93o9R0kAm3HYfihR7oFKlNLtIZLCwv_D9twA&e=
>>>
>>> Although, issues related to packing are generally a concern of the
>>> distribution and their contributors.
>>>
>>>
>>> On Wed, Mar 13, 2019 at 12:25 PM Brad Zynda via mod-security-developers <
>>> mod...@li...> wrote:
>>>
>>>> Hello,
>>>>
>>>> Not seeing it listed in the update info specifically and also not seeing
>>>> a mod evasive on a yum search specific to httpd24-mod-*.
>>>>
>>>> Is there a current work around or milestone? Had to update to run the
>>>> latest php7.2.
>>>>
>>>> Thanks,
>>>> Brad
>>>>
>>>>
>>>> _______________________________________________
>>>> mod-security-developers mailing list
>>>> mod...@li...
>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.sourceforge.net_lists_listinfo_mod-2Dsecurity-2Ddevelopers&d=DwIBaQ&c=ApwzowJNAKKw3xye91w7BE1XMRKi2LN9kiMk5Csz9Zk&r=fdpjFOxiMCMp-y3vo7z7JUA9YdTgrS2RUK-LJ49taQg&m=E504AKky7p0c2VO1C0ZNOZutSYcF3qne4p1k85oRxto&s=8DtYlpg2Y9ztl9KPSY-5T0mPPsj99vWFW6Pvv_z2M-k&e=
>>>> ModSecurity Services from Trustwave's SpiderLabs:
>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.trustwave.com_spiderLabs.php&d=DwIBaQ&c=ApwzowJNAKKw3xye91w7BE1XMRKi2LN9kiMk5Csz9Zk&r=fdpjFOxiMCMp-y3vo7z7JUA9YdTgrS2RUK-LJ49taQg&m=E504AKky7p0c2VO1C0ZNOZutSYcF3qne4p1k85oRxto&s=n0JFSyzjZE-I-XoEP0m9yVjjCYWwXrpLPDcKVcJaAPI&e=
>>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> mod-security-developers mailing list
>>> mod...@li...
>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.sourceforge.net_lists_listinfo_mod-2Dsecurity-2Ddevelopers&d=DwICAg&c=ApwzowJNAKKw3xye91w7BE1XMRKi2LN9kiMk5Csz9Zk&r=fdpjFOxiMCMp-y3vo7z7JUA9YdTgrS2RUK-LJ49taQg&m=E504AKky7p0c2VO1C0ZNOZutSYcF3qne4p1k85oRxto&s=8DtYlpg2Y9ztl9KPSY-5T0mPPsj99vWFW6Pvv_z2M-k&e=
>>> ModSecurity Services from Trustwave's SpiderLabs:
>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.trustwave.com_spiderLabs.php&d=DwICAg&c=ApwzowJNAKKw3xye91w7BE1XMRKi2LN9kiMk5Csz9Zk&r=fdpjFOxiMCMp-y3vo7z7JUA9YdTgrS2RUK-LJ49taQg&m=E504AKky7p0c2VO1C0ZNOZutSYcF3qne4p1k85oRxto&s=n0JFSyzjZE-I-XoEP0m9yVjjCYWwXrpLPDcKVcJaAPI&e=
>>>
>>
>>
>> _______________________________________________
>> mod-security-developers mailing list
>> mod...@li...
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.sourceforge.net_lists_listinfo_mod-2Dsecurity-2Ddevelopers&d=DwICAg&c=ApwzowJNAKKw3xye91w7BE1XMRKi2LN9kiMk5Csz9Zk&r=fdpjFOxiMCMp-y3vo7z7JUA9YdTgrS2RUK-LJ49taQg&m=DFJ7aSlNcy3E31fLniEr318DA5rySzBGNaMZb2BvcdI&s=norEMduzsoMGhfPb3t71uubJGs4LXOgZaxf2tLj5wJ0&e=
>> ModSecurity Services from Trustwave's SpiderLabs:
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.trustwave.com_spiderLabs.php&d=DwICAg&c=ApwzowJNAKKw3xye91w7BE1XMRKi2LN9kiMk5Csz9Zk&r=fdpjFOxiMCMp-y3vo7z7JUA9YdTgrS2RUK-LJ49taQg&m=DFJ7aSlNcy3E31fLniEr318DA5rySzBGNaMZb2BvcdI&s=vM8CSs7i0ybefnmAa_SosdUpOOlVCIQex0GhMYmtVX4&e=
>>
> 
> 
> _______________________________________________
> mod-security-developers mailing list
> mod...@li...
> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.sourceforge.net_lists_listinfo_mod-2Dsecurity-2Ddevelopers&d=DwICAg&c=ApwzowJNAKKw3xye91w7BE1XMRKi2LN9kiMk5Csz9Zk&r=fdpjFOxiMCMp-y3vo7z7JUA9YdTgrS2RUK-LJ49taQg&m=dq-NVbVWC5ZYihVMmk086tTXFngd9jW4ZVAoVP7vMEE&s=31ndn4faJoA7NQfKsAqof93wvK2A28SrfwQXVlsN1SU&e=
> ModSecurity Services from Trustwave's SpiderLabs:
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.trustwave.com_spiderLabs.php&d=DwICAg&c=ApwzowJNAKKw3xye91w7BE1XMRKi2LN9kiMk5Csz9Zk&r=fdpjFOxiMCMp-y3vo7z7JUA9YdTgrS2RUK-LJ49taQg&m=dq-NVbVWC5ZYihVMmk086tTXFngd9jW4ZVAoVP7vMEE&s=yI0fsEarHTCnGI48LAJ7bLIYMccAM5LzjIhRFhwIl5M&e=
> 

Re: [Mod-security-developers] Request body processed when blocking in phase 1

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

Great, so we have:

Apache on Windows running a customized version ModSecurity compiled with
VisualStudio.

Let me ask you this: are the libApr, Apache and ModSecurity compiled with
the same VisualStudio family?

Do the Apache binaries cames from Apache Lounge? Without the
"--enable-request-early"  but, yet, with a custom windows compilation, did
you manage to see a different result?

Br.,
Felipe.


On Wed, Mar 13, 2019 at 5:24 AM Marc Stern <mar...@ap...> wrote:

> I'm using the Apache version (also) under Windows.
> I defined REQUEST_EARLY in Visual Studio.
>
> Marc
>
> On 13-03-19 03:01, Felipe Costa wrote:
>
> How you have recompiled the windows version with enable-request-early?
> What is your IIS version?
>
>
>
> Br.,
>
> *Felipe “Zimmerle” Costa*
>
> Security Researcher, Lead Developer ModSecurity.
>
>
>
> *Trustwave* | SMART SECURITY ON DEMAND
>
> *www.trustwave.com <http://www.trustwave.com/>*
>
>
>
>
>
> *From: *Marc Stern <mar...@ap...> <mar...@ap...>
> *Reply-To: *Marc Stern <mar...@ap...> <mar...@ap...>
> *Date: *Tuesday, March 12, 2019 at 12:39 PM
> *To: *Felipe Costa <FC...@tr...> <FC...@tr...>,
> "mod...@li..."
> <mod...@li...>
> <mod...@li...>
> <mod...@li...>
> *Subject: *Re: Request body processed when blocking in phase 1
>
>
>
> I reproduced this behaviour even in Windows with everything compiled
> together
>
> Marc
>
> On 11-03-19 14:22, Felipe Costa wrote:
>
> I have seemed the behavior that you have described in servers with APR
> version mismatch. Other than that, I did not manage to emulate such
> behavior.
>
>
>
>
>
> Br.,
>
> *Felipe "Zimmerle" Costa*
>
> Security Researcher, Lead Developer ModSecurity
>
> m: +55 81.98706.5547
>
>
>
> [image: signature_480191669]
>
> *www.trustwave.com <http://www.trustwave.com/>*
>
>
>
> *Recognized by industry analysts as a leader in managed security services.
> <https://www.trustwave.com/company/about-us/accolades/>*
>
>
> ------------------------------
>
> *From:* Marc Stern <mar...@ap...> <mar...@ap...>
> *Sent:* Thursday, February 28, 2019 11:49 AM
> *To:* mod...@li...
> *Subject:* [Mod-security-developers] Request body processed when blocking
> in phase 1
>
>
>
> I'm running v 2.9.3 built with --enable-request-early to have phase 1
> rules running before receiving the body.
> If I sent a huge body, the request is well blocked in phase 1 but
> there's a huge processing time (10 min for 1.5 MB) on a strong machine
> after hook_insert_error_filter()
> Can somebody explain me what could happen and/or how to troubleshoot that.
> Isn't the phase 1 rule (with --enable-request-early) supposed to run
> before the request body is received by httpd?
>
> Here's the debug log (max level):
> [28/Feb/2019:14:27:50 +0100] [...][4] Ctl: Set requestBodyAccess to 0.
> [...]
> [28/Feb/2019:14:27:50 +0100] [...][4] Access denied with code 404 (phase
> 1). [...]
> [28/Feb/2019:14:27:50 +0100] [...][4] Hook insert_error_filter: Adding
> output filter (r 248029de120).
> [28/Feb/2019:14:37:20 +0100] [...][9] Output filter: Receiving output (f
> 24802c82a38, r 248029de120).
> [28/Feb/2019:14:37:20 +0100] [...][4] Skipping phase 3 as request was
> already intercepted.
>
> error log:
> [Thu Feb 28 14:27:50.864432 2019] [core:trace5] [pid 6060:tid 2008]
> protocol.c(614): [client ...] Request received from client: POST /...
> HTTP/1.1
> [Thu Feb 28 14:37:20.529622 2019] [headers:debug] [pid 6060:tid 2008]
> mod_headers.c(908): AH01503: headers: ap_headers_error_filter()
>
> Marc
>
> _______________________________________________
> mod-security-developers mailing list
> mod...@li...
>
> https://scanmail.trustwave.com/?c=4062&d=kv333Abx-vXiIBZ1YneBxeM0MfaUkB_XCXnlDQQiBg&s=5&u=https%3a%2f%2flists%2esourceforge%2enet%2flists%2flistinfo%2fmod-security-developers
> <https://scanmail.trustwave.com/?c=4062&d=yNKH3MMlr2fvDpZSllszGJ_gvfkIiM0oQRMGgD8iLQ&s=5&u=https%3a%2f%2flists%2esourceforge%2enet%2flists%2flistinfo%2fmod-security-developers>
> ModSecurity Services from Trustwave's SpiderLabs:
> https://www.trustwave.com/spiderLabs.php
>
>
>
>
> _______________________________________________
> mod-security-developers mailing list
> mod...@li...
> https://lists.sourceforge.net/lists/listinfo/mod-security-developers
> ModSecurity Services from Trustwave's SpiderLabs:
> https://www.trustwave.com/spiderLabs.php



-- 
Br.,
Felipe Zimmerle

Re: [Mod-security-developers] HTTPD24 rh sclo availability

[Brad Z. <bra...@na...>]

Hi Felipe,

I reviewed the documentation on GIT and see it only supports 1.3 and 2.0
apache.

I have sent a note to the maintainer as well for documentation or a
version that will work similar to this one for mod security.

Thanks,
Brad

On 3/14/19 10:39 AM, Brad Zynda via mod-security-developers wrote:
> Hi Felipe,
> 
> Thanks for the info on mod-evasive, I will dig through their changelog.
> Do you happen to have any info on mod security as well?
> 
> Thanks,
> Brad
> 
> On 3/14/19 10:26 AM, Felipe Zimmerle wrote:
>> Hi Brad,
>>
>> Regarding mod evasive, you may get a better answer here:
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_jzdziarski_mod-5Fevasive&d=DwIBaQ&c=ApwzowJNAKKw3xye91w7BE1XMRKi2LN9kiMk5Csz9Zk&r=fdpjFOxiMCMp-y3vo7z7JUA9YdTgrS2RUK-LJ49taQg&m=E504AKky7p0c2VO1C0ZNOZutSYcF3qne4p1k85oRxto&s=-Ua99gz93o9R0kAm3HYfihR7oFKlNLtIZLCwv_D9twA&e=
>>
>> Although, issues related to packing are generally a concern of the
>> distribution and their contributors.
>>
>>
>> On Wed, Mar 13, 2019 at 12:25 PM Brad Zynda via mod-security-developers <
>> mod...@li...> wrote:
>>
>>> Hello,
>>>
>>> Not seeing it listed in the update info specifically and also not seeing
>>> a mod evasive on a yum search specific to httpd24-mod-*.
>>>
>>> Is there a current work around or milestone? Had to update to run the
>>> latest php7.2.
>>>
>>> Thanks,
>>> Brad
>>>
>>>
>>> _______________________________________________
>>> mod-security-developers mailing list
>>> mod...@li...
>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.sourceforge.net_lists_listinfo_mod-2Dsecurity-2Ddevelopers&d=DwIBaQ&c=ApwzowJNAKKw3xye91w7BE1XMRKi2LN9kiMk5Csz9Zk&r=fdpjFOxiMCMp-y3vo7z7JUA9YdTgrS2RUK-LJ49taQg&m=E504AKky7p0c2VO1C0ZNOZutSYcF3qne4p1k85oRxto&s=8DtYlpg2Y9ztl9KPSY-5T0mPPsj99vWFW6Pvv_z2M-k&e=
>>> ModSecurity Services from Trustwave's SpiderLabs:
>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.trustwave.com_spiderLabs.php&d=DwIBaQ&c=ApwzowJNAKKw3xye91w7BE1XMRKi2LN9kiMk5Csz9Zk&r=fdpjFOxiMCMp-y3vo7z7JUA9YdTgrS2RUK-LJ49taQg&m=E504AKky7p0c2VO1C0ZNOZutSYcF3qne4p1k85oRxto&s=n0JFSyzjZE-I-XoEP0m9yVjjCYWwXrpLPDcKVcJaAPI&e=
>>>
>>
>>
>>
>>
>> _______________________________________________
>> mod-security-developers mailing list
>> mod...@li...
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.sourceforge.net_lists_listinfo_mod-2Dsecurity-2Ddevelopers&d=DwICAg&c=ApwzowJNAKKw3xye91w7BE1XMRKi2LN9kiMk5Csz9Zk&r=fdpjFOxiMCMp-y3vo7z7JUA9YdTgrS2RUK-LJ49taQg&m=E504AKky7p0c2VO1C0ZNOZutSYcF3qne4p1k85oRxto&s=8DtYlpg2Y9ztl9KPSY-5T0mPPsj99vWFW6Pvv_z2M-k&e=
>> ModSecurity Services from Trustwave's SpiderLabs:
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.trustwave.com_spiderLabs.php&d=DwICAg&c=ApwzowJNAKKw3xye91w7BE1XMRKi2LN9kiMk5Csz9Zk&r=fdpjFOxiMCMp-y3vo7z7JUA9YdTgrS2RUK-LJ49taQg&m=E504AKky7p0c2VO1C0ZNOZutSYcF3qne4p1k85oRxto&s=n0JFSyzjZE-I-XoEP0m9yVjjCYWwXrpLPDcKVcJaAPI&e=
>>
> 
> 
> _______________________________________________
> mod-security-developers mailing list
> mod...@li...
> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.sourceforge.net_lists_listinfo_mod-2Dsecurity-2Ddevelopers&d=DwICAg&c=ApwzowJNAKKw3xye91w7BE1XMRKi2LN9kiMk5Csz9Zk&r=fdpjFOxiMCMp-y3vo7z7JUA9YdTgrS2RUK-LJ49taQg&m=DFJ7aSlNcy3E31fLniEr318DA5rySzBGNaMZb2BvcdI&s=norEMduzsoMGhfPb3t71uubJGs4LXOgZaxf2tLj5wJ0&e=
> ModSecurity Services from Trustwave's SpiderLabs:
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.trustwave.com_spiderLabs.php&d=DwICAg&c=ApwzowJNAKKw3xye91w7BE1XMRKi2LN9kiMk5Csz9Zk&r=fdpjFOxiMCMp-y3vo7z7JUA9YdTgrS2RUK-LJ49taQg&m=DFJ7aSlNcy3E31fLniEr318DA5rySzBGNaMZb2BvcdI&s=vM8CSs7i0ybefnmAa_SosdUpOOlVCIQex0GhMYmtVX4&e=
> 

Re: [Mod-security-developers] HTTPD24 rh sclo availability

[Brad Z. <bra...@na...>]

Hi Felipe,

Thanks for the info on mod-evasive, I will dig through their changelog.
Do you happen to have any info on mod security as well?

Thanks,
Brad

On 3/14/19 10:26 AM, Felipe Zimmerle wrote:
> Hi Brad,
> 
> Regarding mod evasive, you may get a better answer here:
> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_jzdziarski_mod-5Fevasive&d=DwIBaQ&c=ApwzowJNAKKw3xye91w7BE1XMRKi2LN9kiMk5Csz9Zk&r=fdpjFOxiMCMp-y3vo7z7JUA9YdTgrS2RUK-LJ49taQg&m=E504AKky7p0c2VO1C0ZNOZutSYcF3qne4p1k85oRxto&s=-Ua99gz93o9R0kAm3HYfihR7oFKlNLtIZLCwv_D9twA&e=
> 
> Although, issues related to packing are generally a concern of the
> distribution and their contributors.
> 
> 
> On Wed, Mar 13, 2019 at 12:25 PM Brad Zynda via mod-security-developers <
> mod...@li...> wrote:
> 
>> Hello,
>>
>> Not seeing it listed in the update info specifically and also not seeing
>> a mod evasive on a yum search specific to httpd24-mod-*.
>>
>> Is there a current work around or milestone? Had to update to run the
>> latest php7.2.
>>
>> Thanks,
>> Brad
>>
>>
>> _______________________________________________
>> mod-security-developers mailing list
>> mod...@li...
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.sourceforge.net_lists_listinfo_mod-2Dsecurity-2Ddevelopers&d=DwIBaQ&c=ApwzowJNAKKw3xye91w7BE1XMRKi2LN9kiMk5Csz9Zk&r=fdpjFOxiMCMp-y3vo7z7JUA9YdTgrS2RUK-LJ49taQg&m=E504AKky7p0c2VO1C0ZNOZutSYcF3qne4p1k85oRxto&s=8DtYlpg2Y9ztl9KPSY-5T0mPPsj99vWFW6Pvv_z2M-k&e=
>> ModSecurity Services from Trustwave's SpiderLabs:
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.trustwave.com_spiderLabs.php&d=DwIBaQ&c=ApwzowJNAKKw3xye91w7BE1XMRKi2LN9kiMk5Csz9Zk&r=fdpjFOxiMCMp-y3vo7z7JUA9YdTgrS2RUK-LJ49taQg&m=E504AKky7p0c2VO1C0ZNOZutSYcF3qne4p1k85oRxto&s=n0JFSyzjZE-I-XoEP0m9yVjjCYWwXrpLPDcKVcJaAPI&e=
>>
> 
> 
> 
> 
> _______________________________________________
> mod-security-developers mailing list
> mod...@li...
> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.sourceforge.net_lists_listinfo_mod-2Dsecurity-2Ddevelopers&d=DwICAg&c=ApwzowJNAKKw3xye91w7BE1XMRKi2LN9kiMk5Csz9Zk&r=fdpjFOxiMCMp-y3vo7z7JUA9YdTgrS2RUK-LJ49taQg&m=E504AKky7p0c2VO1C0ZNOZutSYcF3qne4p1k85oRxto&s=8DtYlpg2Y9ztl9KPSY-5T0mPPsj99vWFW6Pvv_z2M-k&e=
> ModSecurity Services from Trustwave's SpiderLabs:
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.trustwave.com_spiderLabs.php&d=DwICAg&c=ApwzowJNAKKw3xye91w7BE1XMRKi2LN9kiMk5Csz9Zk&r=fdpjFOxiMCMp-y3vo7z7JUA9YdTgrS2RUK-LJ49taQg&m=E504AKky7p0c2VO1C0ZNOZutSYcF3qne4p1k85oRxto&s=n0JFSyzjZE-I-XoEP0m9yVjjCYWwXrpLPDcKVcJaAPI&e=
> 

Re: [Mod-security-developers] HTTPD24 rh sclo availability

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

Hi Brad,

Regarding mod evasive, you may get a better answer here:
https://github.com/jzdziarski/mod_evasive

Although, issues related to packing are generally a concern of the
distribution and their contributors.


On Wed, Mar 13, 2019 at 12:25 PM Brad Zynda via mod-security-developers <
mod...@li...> wrote:

> Hello,
>
> Not seeing it listed in the update info specifically and also not seeing
> a mod evasive on a yum search specific to httpd24-mod-*.
>
> Is there a current work around or milestone? Had to update to run the
> latest php7.2.
>
> Thanks,
> Brad
>
>
> _______________________________________________
> mod-security-developers mailing list
> mod...@li...
> https://lists.sourceforge.net/lists/listinfo/mod-security-developers
> ModSecurity Services from Trustwave's SpiderLabs:
> https://www.trustwave.com/spiderLabs.php
>


-- 
Br.,
Felipe Zimmerle

[Mod-security-developers] HTTPD24 rh sclo availability

[Brad Z. <bra...@na...>]

Hello,

Not seeing it listed in the update info specifically and also not seeing
a mod evasive on a yum search specific to httpd24-mod-*.

Is there a current work around or milestone? Had to update to run the
latest php7.2.

Thanks,
Brad

Re: [Mod-security-developers] Request body processed when blocking in phase 1

[Marc S. <mar...@ap...>]

I'm using the Apache version (also) under Windows.
I defined REQUEST_EARLY in Visual Studio.

Marc

On 13-03-19 03:01, Felipe Costa wrote:
How you have recompiled the windows version with enable-request-early? What is your IIS version?

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

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


From: Marc Stern <mar...@ap...><mailto:mar...@ap...>
Reply-To: Marc Stern <mar...@ap...><mailto:mar...@ap...>
Date: Tuesday, March 12, 2019 at 12:39 PM
To: Felipe Costa <FC...@tr...><mailto:FC...@tr...>, "mod...@li..."<mailto:mod...@li...> <mod...@li...><mailto:mod...@li...>
Subject: Re: Request body processed when blocking in phase 1

I reproduced this behaviour even in Windows with everything compiled together

Marc
On 11-03-19 14:22, Felipe Costa wrote:
I have seemed the behavior that you have described in servers with APR version mismatch. Other than that, I did not manage to emulate such behavior.


Br.,

Felipe "Zimmerle" Costa

Security Researcher, Lead Developer ModSecurity

m: +55 81.98706.5547



[signature_480191669]

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



Recognized by industry analysts as a leader in managed security services.<https://www.trustwave.com/company/about-us/accolades/>

________________________________
From: Marc Stern <mar...@ap...><mailto:mar...@ap...>
Sent: Thursday, February 28, 2019 11:49 AM
To: mod...@li...<mailto:mod...@li...>
Subject: [Mod-security-developers] Request body processed when blocking in phase 1

I'm running v 2.9.3 built with --enable-request-early to have phase 1
rules running before receiving the body.
If I sent a huge body, the request is well blocked in phase 1 but
there's a huge processing time (10 min for 1.5 MB) on a strong machine
after hook_insert_error_filter()
Can somebody explain me what could happen and/or how to troubleshoot that.
Isn't the phase 1 rule (with --enable-request-early) supposed to run
before the request body is received by httpd?

Here's the debug log (max level):
[28/Feb/2019:14:27:50 +0100] [...][4] Ctl: Set requestBodyAccess to 0.
[...]
[28/Feb/2019:14:27:50 +0100] [...][4] Access denied with code 404 (phase
1). [...]
[28/Feb/2019:14:27:50 +0100] [...][4] Hook insert_error_filter: Adding
output filter (r 248029de120).
[28/Feb/2019:14:37:20 +0100] [...][9] Output filter: Receiving output (f
24802c82a38, r 248029de120).
[28/Feb/2019:14:37:20 +0100] [...][4] Skipping phase 3 as request was
already intercepted.

error log:
[Thu Feb 28 14:27:50.864432 2019] [core:trace5] [pid 6060:tid 2008]
protocol.c(614): [client ...] Request received from client: POST /...
HTTP/1.1
[Thu Feb 28 14:37:20.529622 2019] [headers:debug] [pid 6060:tid 2008]
mod_headers.c(908): AH01503: headers: ap_headers_error_filter()

Marc

_______________________________________________
mod-security-developers mailing list
mod...@li...<mailto:mod...@li...>
https://scanmail.trustwave.com/?c=4062&d=kv333Abx-vXiIBZ1YneBxeM0MfaUkB_XCXnlDQQiBg&s=5&u=https%3a%2f%2flists%2esourceforge%2enet%2flists%2flistinfo%2fmod-security-developers<https://scanmail.trustwave.com/?c=4062&d=yNKH3MMlr2fvDpZSllszGJ_gvfkIiM0oQRMGgD8iLQ&s=5&u=https%3a%2f%2flists%2esourceforge%2enet%2flists%2flistinfo%2fmod-security-developers>
ModSecurity Services from Trustwave's SpiderLabs:
https://www.trustwave.com/spiderLabs.php

Re: [Mod-security-developers] Request body processed when blocking in phase 1

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

How you have recompiled the windows version with enable-request-early? What is your IIS version?

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

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


From: Marc Stern <mar...@ap...>
Reply-To: Marc Stern <mar...@ap...>
Date: Tuesday, March 12, 2019 at 12:39 PM
To: Felipe Costa <FC...@tr...>, "mod...@li..." <mod...@li...>
Subject: Re: Request body processed when blocking in phase 1

I reproduced this behaviour even in Windows with everything compiled together

Marc
On 11-03-19 14:22, Felipe Costa wrote:
I have seemed the behavior that you have described in servers with APR version mismatch. Other than that, I did not manage to emulate such behavior.


Br.,

Felipe "Zimmerle" Costa

Security Researcher, Lead Developer ModSecurity

m: +55 81.98706.5547



[signature_480191669]

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



Recognized by industry analysts as a leader in managed security services.<https://www.trustwave.com/company/about-us/accolades/>

________________________________
From: Marc Stern <mar...@ap...><mailto:mar...@ap...>
Sent: Thursday, February 28, 2019 11:49 AM
To: mod...@li...<mailto:mod...@li...>
Subject: [Mod-security-developers] Request body processed when blocking in phase 1

I'm running v 2.9.3 built with --enable-request-early to have phase 1
rules running before receiving the body.
If I sent a huge body, the request is well blocked in phase 1 but
there's a huge processing time (10 min for 1.5 MB) on a strong machine
after hook_insert_error_filter()
Can somebody explain me what could happen and/or how to troubleshoot that.
Isn't the phase 1 rule (with --enable-request-early) supposed to run
before the request body is received by httpd?

Here's the debug log (max level):
[28/Feb/2019:14:27:50 +0100] [...][4] Ctl: Set requestBodyAccess to 0.
[...]
[28/Feb/2019:14:27:50 +0100] [...][4] Access denied with code 404 (phase
1). [...]
[28/Feb/2019:14:27:50 +0100] [...][4] Hook insert_error_filter: Adding
output filter (r 248029de120).
[28/Feb/2019:14:37:20 +0100] [...][9] Output filter: Receiving output (f
24802c82a38, r 248029de120).
[28/Feb/2019:14:37:20 +0100] [...][4] Skipping phase 3 as request was
already intercepted.

error log:
[Thu Feb 28 14:27:50.864432 2019] [core:trace5] [pid 6060:tid 2008]
protocol.c(614): [client ...] Request received from client: POST /...
HTTP/1.1
[Thu Feb 28 14:37:20.529622 2019] [headers:debug] [pid 6060:tid 2008]
mod_headers.c(908): AH01503: headers: ap_headers_error_filter()

Marc

_______________________________________________
mod-security-developers mailing list
mod...@li...<mailto:mod...@li...>
https://scanmail.trustwave.com/?c=4062&d=kv333Abx-vXiIBZ1YneBxeM0MfaUkB_XCXnlDQQiBg&s=5&u=https%3a%2f%2flists%2esourceforge%2enet%2flists%2flistinfo%2fmod-security-developers<https://scanmail.trustwave.com/?c=4062&d=yNKH3MMlr2fvDpZSllszGJ_gvfkIiM0oQRMGgD8iLQ&s=5&u=https%3a%2f%2flists%2esourceforge%2enet%2flists%2flistinfo%2fmod-security-developers>
ModSecurity Services from Trustwave's SpiderLabs:
https://www.trustwave.com/spiderLabs.php

Re: [Mod-security-developers] Request body processed when blocking in phase 1

[Marc S. <mar...@ap...>]

I reproduced this behaviour even in Windows with everything compiled together

Marc

On 11-03-19 14:22, Felipe Costa wrote:
I have seemed the behavior that you have described in servers with APR version mismatch. Other than that, I did not manage to emulate such behavior.


Br.,

Felipe "Zimmerle" Costa

Security Researcher, Lead Developer ModSecurity

m: +55 81.98706.5547



[signature_480191669]

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



Recognized by industry analysts as a leader in managed security services.<https://www.trustwave.com/company/about-us/accolades/>


________________________________
From: Marc Stern <mar...@ap...><mailto:mar...@ap...>
Sent: Thursday, February 28, 2019 11:49 AM
To: mod...@li...<mailto:mod...@li...>
Subject: [Mod-security-developers] Request body processed when blocking in phase 1

I'm running v 2.9.3 built with --enable-request-early to have phase 1
rules running before receiving the body.
If I sent a huge body, the request is well blocked in phase 1 but
there's a huge processing time (10 min for 1.5 MB) on a strong machine
after hook_insert_error_filter()
Can somebody explain me what could happen and/or how to troubleshoot that.
Isn't the phase 1 rule (with --enable-request-early) supposed to run
before the request body is received by httpd?

Here's the debug log (max level):
[28/Feb/2019:14:27:50 +0100] [...][4] Ctl: Set requestBodyAccess to 0.
[...]
[28/Feb/2019:14:27:50 +0100] [...][4] Access denied with code 404 (phase
1). [...]
[28/Feb/2019:14:27:50 +0100] [...][4] Hook insert_error_filter: Adding
output filter (r 248029de120).
[28/Feb/2019:14:37:20 +0100] [...][9] Output filter: Receiving output (f
24802c82a38, r 248029de120).
[28/Feb/2019:14:37:20 +0100] [...][4] Skipping phase 3 as request was
already intercepted.

error log:
[Thu Feb 28 14:27:50.864432 2019] [core:trace5] [pid 6060:tid 2008]
protocol.c(614): [client ...] Request received from client: POST /...
HTTP/1.1
[Thu Feb 28 14:37:20.529622 2019] [headers:debug] [pid 6060:tid 2008]
mod_headers.c(908): AH01503: headers: ap_headers_error_filter()

Marc

_______________________________________________
mod-security-developers mailing list
mod...@li...<mailto:mod...@li...>
https://scanmail.trustwave.com/?c=4062&d=kv333Abx-vXiIBZ1YneBxeM0MfaUkB_XCXnlDQQiBg&s=5&u=https%3a%2f%2flists%2esourceforge%2enet%2flists%2flistinfo%2fmod-security-developers
ModSecurity Services from Trustwave's SpiderLabs:
https://www.trustwave.com/spiderLabs.php

Re: [Mod-security-developers] Request body processed when blocking in phase 1

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

I have seemed the behavior that you have described in servers with APR version mismatch. Other than that, I did not manage to emulate such behavior.


Br.,

Felipe "Zimmerle" Costa

Security Researcher, Lead Developer ModSecurity

m: +55 81.98706.5547



[signature_480191669]

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



Recognized by industry analysts as a leader in managed security services.<https://www.trustwave.com/company/about-us/accolades/>


________________________________
From: Marc Stern <mar...@ap...>
Sent: Thursday, February 28, 2019 11:49 AM
To: mod...@li...
Subject: [Mod-security-developers] Request body processed when blocking in phase 1

I'm running v 2.9.3 built with --enable-request-early to have phase 1
rules running before receiving the body.
If I sent a huge body, the request is well blocked in phase 1 but
there's a huge processing time (10 min for 1.5 MB) on a strong machine
after hook_insert_error_filter()
Can somebody explain me what could happen and/or how to troubleshoot that.
Isn't the phase 1 rule (with --enable-request-early) supposed to run
before the request body is received by httpd?

Here's the debug log (max level):
[28/Feb/2019:14:27:50 +0100] [...][4] Ctl: Set requestBodyAccess to 0.
[...]
[28/Feb/2019:14:27:50 +0100] [...][4] Access denied with code 404 (phase
1). [...]
[28/Feb/2019:14:27:50 +0100] [...][4] Hook insert_error_filter: Adding
output filter (r 248029de120).
[28/Feb/2019:14:37:20 +0100] [...][9] Output filter: Receiving output (f
24802c82a38, r 248029de120).
[28/Feb/2019:14:37:20 +0100] [...][4] Skipping phase 3 as request was
already intercepted.

error log:
[Thu Feb 28 14:27:50.864432 2019] [core:trace5] [pid 6060:tid 2008]
protocol.c(614): [client ...] Request received from client: POST /...
HTTP/1.1
[Thu Feb 28 14:37:20.529622 2019] [headers:debug] [pid 6060:tid 2008]
mod_headers.c(908): AH01503: headers: ap_headers_error_filter()

Marc

_______________________________________________
mod-security-developers mailing list
mod...@li...
https://scanmail.trustwave.com/?c=4062&d=kv333Abx-vXiIBZ1YneBxeM0MfaUkB_XCXnlDQQiBg&s=5&u=https%3a%2f%2flists%2esourceforge%2enet%2flists%2flistinfo%2fmod-security-developers
ModSecurity Services from Trustwave's SpiderLabs:
https://www.trustwave.com/spiderLabs.php

[Mod-security-developers] Request body processed when blocking in phase 1

[Marc S. <mar...@ap...>]

I'm running v 2.9.3 built with --enable-request-early to have phase 1 
rules running before receiving the body.
If I sent a huge body, the request is well blocked in phase 1 but 
there's a huge processing time (10 min for 1.5 MB) on a strong machine 
after hook_insert_error_filter()
Can somebody explain me what could happen and/or how to troubleshoot that.
Isn't the phase 1 rule (with --enable-request-early) supposed to run 
before the request body is received by httpd?

Here's the debug log (max level):
[28/Feb/2019:14:27:50 +0100] [...][4] Ctl: Set requestBodyAccess to 0.
[...]
[28/Feb/2019:14:27:50 +0100] [...][4] Access denied with code 404 (phase 
1). [...]
[28/Feb/2019:14:27:50 +0100] [...][4] Hook insert_error_filter: Adding 
output filter (r 248029de120).
[28/Feb/2019:14:37:20 +0100] [...][9] Output filter: Receiving output (f 
24802c82a38, r 248029de120).
[28/Feb/2019:14:37:20 +0100] [...][4] Skipping phase 3 as request was 
already intercepted.

error log:
[Thu Feb 28 14:27:50.864432 2019] [core:trace5] [pid 6060:tid 2008] 
protocol.c(614): [client ...] Request received from client: POST /... 
HTTP/1.1
[Thu Feb 28 14:37:20.529622 2019] [headers:debug] [pid 6060:tid 2008] 
mod_headers.c(908): AH01503: headers: ap_headers_error_filter()

Marc

Re: [Mod-security-developers] Question regarding calls to serverLog()

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

Hi Jai,

Sometimes logging is a consequence of a disruptive action; sometimes the logging is just a warning. On 3.0.2 the logging for disruptive (aka error on 2.x) was being generated as a warning as well. To avoid creating the same message twice, we have changed 3.0.3 to produce only warnings, and give access to error message along with the disruptive structure.

Here is how the ngnix connector is handling it:
https://github.com/SpiderLabs/ModSecurity-nginx/blob/master/src/ngx_http_modsecurity_module.c#L139


Yes, performance is better and will be even better for the upcoming releases :)

Br.,

Felipe "Zimmerle" Costa

Security Researcher, Lead Developer ModSecurity

m: +55 81.98706.5547



[signature_480191669]

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



Recognized by industry analysts as a leader in managed security services.<https://www.trustwave.com/company/about-us/accolades/>


________________________________
From: Jai Harpalani via mod-security-developers <mod...@li...>
Sent: Wednesday, February 20, 2019 8:32 PM
To: mod-security-d.
Cc: Jai Harpalani
Subject: [Mod-security-developers] Question regarding calls to serverLog()

We are integrating ModSecurity into our product as a library, and using it to evaluate owasp crs rules. With version 3.0.2, all was working relatively well. With version 3.0.3, we are encountering problems. Details below.

We invoke setServerLogCb(ourCallbackMethod) and expect that ourCallbackMethod() will be invoked whenever a rule is triggered. This is the only way we know a rule has triggered, and this was working with version 3.0.2. With 3.0.3, this scheme does not work for all rules.

Looking at the code in rule.cc,<http://scanmail.trustwave.com/?c=4062&d=9urt3IzQGylflGxIvXzdwpsVsyjoMmRH3TE5HVEtqg&s=5&u=http%3a%2f%2frule%2ecc> I notice that logic surrounding the invocation of trans->serverLog() which eventually invokes ourCallbackMethod() has changed. Due to these changes, ourCallbackMethod() is not called for all rules.

First question: Why were these changes made, and can they be reverted?
Second question: Are there other ways for our product-specific code to know that a rule has been triggered along with all the information in modsecurity::RuleMessage? In other words, are there any other hooks into ModSecurity that our product-specific code can use to get this information?

BTW, I am seeing a 2x speedup with version 3.0.3 vs 3.0.2 which is great. Good job on making ModSecurity more performant!

[Mod-security-developers] Question regarding calls to serverLog()

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

We are integrating ModSecurity into our product as a library, and using it
to evaluate owasp crs rules. With version 3.0.2, all was working relatively
well. With version 3.0.3, we are encountering problems. Details below.

We invoke setServerLogCb(ourCallbackMethod) and expect that
ourCallbackMethod() will be invoked whenever a rule is triggered. This is
the only way we know a rule has triggered, and this was working with
version 3.0.2. With 3.0.3, this scheme does not work for all rules.

Looking at the code in rule.cc, I notice that logic surrounding the
invocation of trans->serverLog() which eventually invokes
ourCallbackMethod() has changed. Due to these changes, ourCallbackMethod()
is not called for all rules.

First question: Why were these changes made, and can they be reverted?
Second question: Are there other ways for our product-specific code to know
that a rule has been triggered along with all the information in
modsecurity::RuleMessage? In other words, are there any other hooks into
ModSecurity that our product-specific code can use to get this information?

BTW, I am seeing a 2x speedup with version 3.0.3 vs 3.0.2 which is great.
Good job on making ModSecurity more performant!

Re: [Mod-security-developers] Macro expansion in operators

[Ervin H. <ai...@gm...>]

hi,

On Mon, Feb 11, 2019 at 01:42:46PM +0000, Felipe Costa wrote:
> I've got your point. Personally, I don't like this approach as it may be confusing to debug the rules, but I understand your point. Yes, a patch will be welcome 😉

before anybody should start to work on operators, please don't
forget, that there is a pending PR related to the
validateByteRange operator:

https://github.com/SpiderLabs/ModSecurity/pull/2017


:)


a.
 
>> Br.,
> 
> Felipe "Zimmerle" Costa
> 
> Security Researcher, Lead Developer ModSecurity
> 
> m: +55 81.98706.5547
> 
> 
> 
> [signature_480191669]
> 
> www.trustwave.com<http://www.trustwave.com/>
> 
> 
> 
> Recognized by industry analysts as a leader in managed security services.<https://www.trustwave.com/company/about-us/accolades/>
> 
> 
> ________________________________
> From: Marc Stern <mar...@ap...>
> Sent: Thursday, February 7, 2019 6:24 AM
> To: mod...@li...
> Subject: Re: [Mod-security-developers] Macro expansion in operators
> 
> The main goal is to be able to extend a pattern incrementally. This is especially useful in shared environments, but not limited to this case.
> 
> Example: you define you general policy to accept only certain characters
>    SecRule ARGS "@validateByteRange 32-90"
> 
> In a location, you want an exception to accept some additional characters (CR/LF):
>    <Location /...>
>     SecRule ARGS "@validateByteRange 10,13,32-90"
>    </Location>
> 
> In case you extend your global policy (let's say 32-95), your exception doesn't follow it. You are obliged to keep them aligned (you'll forget to do this if they are disseminated in several files).
> 
> The solution could be:
>    SecAction "phase:1,setvar:tx.allowedRange=32-90"
> 
>    <Location /...>
>     SecAction "phase:2,setvar:tx.allowedRange=%{tx.allowedRange},10,13"
>    </Location>
> 
>    SecRule ARGS "@validateByteRange %{tx.allowedRange}" "phase:2,..."
> 
> Same for ipMatch
> 
> Marc
> 
> On 05-02-19 17:54, Felipe Costa wrote:
> 
> Hi Marc,
> 
> 
> There is no specific reason. As there is a computational cost for macro expansion, we may have it only where/when it is extremely necessary. Do you have a specific use case?
> 
> 
> Br.,
> 
> Felipe "Zimmerle" Costa
> 
> Security Researcher, Lead Developer ModSecurity
> 
> 
> ________________________________
> From: Marc Stern <mar...@ap...><mailto:mar...@ap...>
> Sent: Friday, February 1, 2019 12:16:20 PM
> To: mod...@li...<mailto:mod...@li...>
> Subject: [Mod-security-developers] Macro expansion in operators
> 
> Can somebody explain me why the operators below don't perform macro
> expansion; they're using plain strings, not pre-calculated patterns:
>   - ipMatch
>   - validateByteRange
> 
> Would a pull request implementing this be accepted?
> 
> Marc Stern
> 
> _______________________________________________
> mod-security-developers mailing list
> mod...@li...<mailto:mod...@li...>
> https://scanmail.trustwave.com/?c=4062&d=3bHU3PIPIuUQrzOmOziiUcqWOyJFIV2loAPuiTrUlA&s=5&u=https%3a%2f%2flists%2esourceforge%2enet%2flists%2flistinfo%2fmod-security-developers<https://scanmail.trustwave.com/?c=4062&d=57nc3DspNU5aOwZsU4--G33vqxJuRzh_IAF3WDNkmw&s=5&u=https%3a%2f%2flists%2esourceforge%2enet%2flists%2flistinfo%2fmod-security-developers>
> ModSecurity Services from Trustwave's SpiderLabs:
> https://www.trustwave.com/spiderLabs.php
> 


> _______________________________________________
> mod-security-developers mailing list
> mod...@li...
> https://lists.sourceforge.net/lists/listinfo/mod-security-developers
> ModSecurity Services from Trustwave's SpiderLabs:
> https://www.trustwave.com/spiderLabs.php

Re: [Mod-security-developers] Macro expansion in operators

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

I've got your point. Personally, I don't like this approach as it may be confusing to debug the rules, but I understand your point. Yes, a patch will be welcome 😉

Br.,

Felipe "Zimmerle" Costa

Security Researcher, Lead Developer ModSecurity

m: +55 81.98706.5547



[signature_480191669]

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



Recognized by industry analysts as a leader in managed security services.<https://www.trustwave.com/company/about-us/accolades/>


________________________________
From: Marc Stern <mar...@ap...>
Sent: Thursday, February 7, 2019 6:24 AM
To: mod...@li...
Subject: Re: [Mod-security-developers] Macro expansion in operators

The main goal is to be able to extend a pattern incrementally. This is especially useful in shared environments, but not limited to this case.

Example: you define you general policy to accept only certain characters
   SecRule ARGS "@validateByteRange 32-90"

In a location, you want an exception to accept some additional characters (CR/LF):
   <Location /...>
    SecRule ARGS "@validateByteRange 10,13,32-90"
   </Location>

In case you extend your global policy (let's say 32-95), your exception doesn't follow it. You are obliged to keep them aligned (you'll forget to do this if they are disseminated in several files).

The solution could be:
   SecAction "phase:1,setvar:tx.allowedRange=32-90"

   <Location /...>
    SecAction "phase:2,setvar:tx.allowedRange=%{tx.allowedRange},10,13"
   </Location>

   SecRule ARGS "@validateByteRange %{tx.allowedRange}" "phase:2,..."

Same for ipMatch

Marc

On 05-02-19 17:54, Felipe Costa wrote:

Hi Marc,


There is no specific reason. As there is a computational cost for macro expansion, we may have it only where/when it is extremely necessary. Do you have a specific use case?


Br.,

Felipe "Zimmerle" Costa

Security Researcher, Lead Developer ModSecurity


________________________________
From: Marc Stern <mar...@ap...><mailto:mar...@ap...>
Sent: Friday, February 1, 2019 12:16:20 PM
To: mod...@li...<mailto:mod...@li...>
Subject: [Mod-security-developers] Macro expansion in operators

Can somebody explain me why the operators below don't perform macro
expansion; they're using plain strings, not pre-calculated patterns:
  - ipMatch
  - validateByteRange

Would a pull request implementing this be accepted?

Marc Stern

_______________________________________________
mod-security-developers mailing list
mod...@li...<mailto:mod...@li...>
https://scanmail.trustwave.com/?c=4062&d=3bHU3PIPIuUQrzOmOziiUcqWOyJFIV2loAPuiTrUlA&s=5&u=https%3a%2f%2flists%2esourceforge%2enet%2flists%2flistinfo%2fmod-security-developers<https://scanmail.trustwave.com/?c=4062&d=57nc3DspNU5aOwZsU4--G33vqxJuRzh_IAF3WDNkmw&s=5&u=https%3a%2f%2flists%2esourceforge%2enet%2flists%2flistinfo%2fmod-security-developers>
ModSecurity Services from Trustwave's SpiderLabs:
https://www.trustwave.com/spiderLabs.php

[Mod-security-developers] modsec support for Oracle 11G (oracle EBS impl 50k+ users)

[asad <a.a...@gm...>]

Hi,
I'm working with a customer which has 50k + user-base for ORACLE EBS
implementation. They are using Oracle 11G,

The OAM is : 11.2.0.4
O/S is red-hat: 5.8 64 bit

I'm unable to find workable "modsecurity version" that is supportive to
this platform, should I look into Oracle archives, the one I found was
giving error loading the module files *.so at startup.

Thanks

regards
asad