mod-security-users — General discussion about mod_security

Re: [mod-security-users] libmodsecurity3.0.1 shared object version number regression?

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

Hi Gregory,

Thanks for the report. Fixed here:
https://github.com/SpiderLabs/ModSecurity/commit/2e87c4e751b191619c0de68e3f0567bdac58ed16


The problem was here:
https://github.com/SpiderLabs/ModSecurity/commit/95cb4c56ab90ec19fea4a7beea8ed070e1e61e23#diff-67e997bcfdac55191033d57a16d1408aR14

Can you share your GitHub info, so I can update the CHANGES properly?

Br.,
Felipe.


On Mon, Apr 2, 2018 at 11:52 PM Felipe Zimmerle <fe...@zi...> wrote:

> Hi Gregory,
>
> The correct object is the one out of compilation process, which indeed
> seems to have the wrong version. I will investigate. In the meanwhile it
> will be very good if you manage to report this on GitHub.
>
> Br.,
> F.
>
> On Mon, Apr 2, 2018 at 11:04 PM Gregory LeFevre <gr...@cl...>
> wrote:
>
>>
>> Hi,
>>
>> I am compiling libmodsecurity3.0.1 from
>> https://github.com/SpiderLabs/ModSecurity/releases/download/v3.0.1/modsecurity-v3.0.1.tar.gz
>> on CentOS7 using:
>>
>>
>> $ ./build.sh
>> $ ./configure
>> $ make
>>
>>
>> I see libmodsecurity.so.*2.1.0* afterward in the build artifacts:
>>
>>
>> [modsecurity-v3.0.1]$ ls -l src/.libs
>> total 172892
>> -rw-rw-r-- 1 build build 127289914 Apr  3 00:51 libmodsecurity.a
>> lrwxrwxrwx 1 build build        20 Apr  3 00:51 libmodsecurity.la -> ../
>> libmodsecurity.la
>> -rw-rw-r-- 1 build build    819584 Apr  3 00:48
>> libmodsecurity_la-anchored_set_variable.o
>> -rw-rw-r-- 1 build build    601432 Apr  3 00:48
>> libmodsecurity_la-anchored_variable.o
>> -rw-rw-r-- 1 build build      1050 Apr  3 00:51 libmodsecurity.lai
>> -rw-rw-r-- 1 build build    742312 Apr  3 00:48
>> libmodsecurity_la-modsecurity.o
>> -rw-rw-r-- 1 build build   1027624 Apr  3 00:48
>> libmodsecurity_la-rule_message.o
>> -rw-rw-r-- 1 build build   2442416 Apr  3 00:48 libmodsecurity_la-rule.o
>> -rw-rw-r-- 1 build build    936496 Apr  3 00:48
>> libmodsecurity_la-rule_script.o
>> -rw-rw-r-- 1 build build   1205592 Apr  3 00:48
>> libmodsecurity_la-rules_exceptions.o
>> -rw-rw-r-- 1 build build   1413432 Apr  3 00:48 libmodsecurity_la-rules.o
>> -rw-rw-r-- 1 build build    814008 Apr  3 00:48
>> libmodsecurity_la-run_time_string.o
>> -rw-rw-r-- 1 build build   2373024 Apr  3 00:48
>> libmodsecurity_la-transaction.o
>> -rw-rw-r-- 1 build build    126280 Apr  3 00:48
>> libmodsecurity_la-unique_id.o
>> lrwxrwxrwx 1 build build        23 Apr  3 00:51 libmodsecurity.so ->
>> libmodsecurity.so.2.1.0
>> lrwxrwxrwx 1 build build        23 Apr  3 00:51 libmodsecurity.so.2 ->
>> libmodsecurity.so.2.1.0
>> -rwxrwxr-x 1 build build  37216744 Apr  3 00:51 libmodsecurity.so.2.1.0
>>
>>
>> and a previous libmodsecurity3.0.0 build (on the same machine, using the
>> same build steps) has libmodsecurity.so.3.0.0:
>>
>>
>> [modsecurity-v3.0.0]$ ls -l src/.libs
>> total 150292
>> -rw-rw-r-- 1 build build 108625334 Apr  3 00:45 libmodsecurity.a
>> lrwxrwxrwx 1 build build        20 Apr  3 00:45 libmodsecurity.la -> ../
>> libmodsecurity.la
>> -rw-rw-r-- 1 build build    754752 Apr  3 00:42
>> libmodsecurity_la-anchored_set_variable.o
>> -rw-rw-r-- 1 build build    572888 Apr  3 00:42
>> libmodsecurity_la-anchored_variable.o
>> -rw-rw-r-- 1 build build      1050 Apr  3 00:45 libmodsecurity.lai
>> -rw-rw-r-- 1 build build   1133712 Apr  3 00:42
>> libmodsecurity_la-macro_expansion.o
>> -rw-rw-r-- 1 build build    753320 Apr  3 00:42
>> libmodsecurity_la-modsecurity.o
>> -rw-rw-r-- 1 build build   1074248 Apr  3 00:42
>> libmodsecurity_la-rule_message.o
>> -rw-rw-r-- 1 build build   2713344 Apr  3 00:42 libmodsecurity_la-rule.o
>> -rw-rw-r-- 1 build build    927592 Apr  3 00:42
>> libmodsecurity_la-rule_script.o
>> -rw-rw-r-- 1 build build   1171128 Apr  3 00:42
>> libmodsecurity_la-rules_exceptions.o
>> -rw-rw-r-- 1 build build   1364000 Apr  3 00:42 libmodsecurity_la-rules.o
>> -rw-rw-r-- 1 build build   2442848 Apr  3 00:42
>> libmodsecurity_la-transaction.o
>> -rw-rw-r-- 1 build build    126280 Apr  3 00:42
>> libmodsecurity_la-unique_id.o
>> lrwxrwxrwx 1 build build        23 Apr  3 00:45 libmodsecurity.so ->
>> libmodsecurity.so.3.0.0
>> lrwxrwxrwx 1 build build        23 Apr  3 00:45 libmodsecurity.so.3 ->
>> libmodsecurity.so.3.0.0
>> -rwxrwxr-x 1 build build  32211128 Apr  3 00:45 libmodsecurity.so.3.0.0
>>
>>
>> Does anyone else see this? How can I be certain that I am getting the
>> correct shared object?
>>
>> Thank you,
>>
>> Gregory
>>
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> mod-security-users mailing list
>> mod...@li...
>> https://lists.sourceforge.net/lists/listinfo/mod-security-users
>> Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs:
>> http://www.modsecurity.org/projects/commercial/rules/
>> http://www.modsecurity.org/projects/commercial/support/
>>
>

Re: [mod-security-users] REQUEST_COOKIES_NAMES:/regex/ does not work

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

On Mon, Apr 02, 2018 at 03:03:42PM -0700, Robert Paprocki wrote:
> Right, so the reason SecRuleUpdateTargetById wasn't working was because it
> was listed in the config file before my rule definition. It's gotta live
> *after*. (ref: https://github.com/SpiderLabs/owasp-modsecurity-
> crs/blob/v3.0/master/rules/REQUEST-900-EXCLUSION-RULES-
> BEFORE-CRS.conf.example#L43)

Note to self: Don't attend 2-hour CRS community chat and then try to respond
to questions on mailinglist quickly before going to bed.

Christian


-- 
Orwell never meant 1984 as a blueprint!
-- Comment found on Bruce Schneier's blog

Re: [mod-security-users] libmodsecurity3.0.1 shared object version number regression?

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

Hi Gregory,

The correct object is the one out of compilation process, which indeed
seems to have the wrong version. I will investigate. In the meanwhile it
will be very good if you manage to report this on GitHub.

Br.,
F.

On Mon, Apr 2, 2018 at 11:04 PM Gregory LeFevre <gr...@cl...> wrote:

>
> Hi,
>
> I am compiling libmodsecurity3.0.1 from
> https://github.com/SpiderLabs/ModSecurity/releases/download/v3.0.1/modsecurity-v3.0.1.tar.gz
> on CentOS7 using:
>
>
> $ ./build.sh
> $ ./configure
> $ make
>
>
> I see libmodsecurity.so.*2.1.0* afterward in the build artifacts:
>
>
> [modsecurity-v3.0.1]$ ls -l src/.libs
> total 172892
> -rw-rw-r-- 1 build build 127289914 Apr  3 00:51 libmodsecurity.a
> lrwxrwxrwx 1 build build        20 Apr  3 00:51 libmodsecurity.la -> ../
> libmodsecurity.la
> -rw-rw-r-- 1 build build    819584 Apr  3 00:48
> libmodsecurity_la-anchored_set_variable.o
> -rw-rw-r-- 1 build build    601432 Apr  3 00:48
> libmodsecurity_la-anchored_variable.o
> -rw-rw-r-- 1 build build      1050 Apr  3 00:51 libmodsecurity.lai
> -rw-rw-r-- 1 build build    742312 Apr  3 00:48
> libmodsecurity_la-modsecurity.o
> -rw-rw-r-- 1 build build   1027624 Apr  3 00:48
> libmodsecurity_la-rule_message.o
> -rw-rw-r-- 1 build build   2442416 Apr  3 00:48 libmodsecurity_la-rule.o
> -rw-rw-r-- 1 build build    936496 Apr  3 00:48
> libmodsecurity_la-rule_script.o
> -rw-rw-r-- 1 build build   1205592 Apr  3 00:48
> libmodsecurity_la-rules_exceptions.o
> -rw-rw-r-- 1 build build   1413432 Apr  3 00:48 libmodsecurity_la-rules.o
> -rw-rw-r-- 1 build build    814008 Apr  3 00:48
> libmodsecurity_la-run_time_string.o
> -rw-rw-r-- 1 build build   2373024 Apr  3 00:48
> libmodsecurity_la-transaction.o
> -rw-rw-r-- 1 build build    126280 Apr  3 00:48
> libmodsecurity_la-unique_id.o
> lrwxrwxrwx 1 build build        23 Apr  3 00:51 libmodsecurity.so ->
> libmodsecurity.so.2.1.0
> lrwxrwxrwx 1 build build        23 Apr  3 00:51 libmodsecurity.so.2 ->
> libmodsecurity.so.2.1.0
> -rwxrwxr-x 1 build build  37216744 Apr  3 00:51 libmodsecurity.so.2.1.0
>
>
> and a previous libmodsecurity3.0.0 build (on the same machine, using the
> same build steps) has libmodsecurity.so.3.0.0:
>
>
> [modsecurity-v3.0.0]$ ls -l src/.libs
> total 150292
> -rw-rw-r-- 1 build build 108625334 Apr  3 00:45 libmodsecurity.a
> lrwxrwxrwx 1 build build        20 Apr  3 00:45 libmodsecurity.la -> ../
> libmodsecurity.la
> -rw-rw-r-- 1 build build    754752 Apr  3 00:42
> libmodsecurity_la-anchored_set_variable.o
> -rw-rw-r-- 1 build build    572888 Apr  3 00:42
> libmodsecurity_la-anchored_variable.o
> -rw-rw-r-- 1 build build      1050 Apr  3 00:45 libmodsecurity.lai
> -rw-rw-r-- 1 build build   1133712 Apr  3 00:42
> libmodsecurity_la-macro_expansion.o
> -rw-rw-r-- 1 build build    753320 Apr  3 00:42
> libmodsecurity_la-modsecurity.o
> -rw-rw-r-- 1 build build   1074248 Apr  3 00:42
> libmodsecurity_la-rule_message.o
> -rw-rw-r-- 1 build build   2713344 Apr  3 00:42 libmodsecurity_la-rule.o
> -rw-rw-r-- 1 build build    927592 Apr  3 00:42
> libmodsecurity_la-rule_script.o
> -rw-rw-r-- 1 build build   1171128 Apr  3 00:42
> libmodsecurity_la-rules_exceptions.o
> -rw-rw-r-- 1 build build   1364000 Apr  3 00:42 libmodsecurity_la-rules.o
> -rw-rw-r-- 1 build build   2442848 Apr  3 00:42
> libmodsecurity_la-transaction.o
> -rw-rw-r-- 1 build build    126280 Apr  3 00:42
> libmodsecurity_la-unique_id.o
> lrwxrwxrwx 1 build build        23 Apr  3 00:45 libmodsecurity.so ->
> libmodsecurity.so.3.0.0
> lrwxrwxrwx 1 build build        23 Apr  3 00:45 libmodsecurity.so.3 ->
> libmodsecurity.so.3.0.0
> -rwxrwxr-x 1 build build  32211128 Apr  3 00:45 libmodsecurity.so.3.0.0
>
>
> Does anyone else see this? How can I be certain that I am getting the
> correct shared object?
>
> Thank you,
>
> Gregory
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> mod-security-users mailing list
> mod...@li...
> https://lists.sourceforge.net/lists/listinfo/mod-security-users
> Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs:
> http://www.modsecurity.org/projects/commercial/rules/
> http://www.modsecurity.org/projects/commercial/support/
>

[mod-security-users] libmodsecurity3.0.1 shared object version number regression?

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

Hi,

I am compiling libmodsecurity3.0.1 from
https://github.com/SpiderLabs/ModSecurity/releases/download/v3.0.1/modsecurity-v3.0.1.tar.gz
on CentOS7 using:


$ ./build.sh
$ ./configure
$ make


I see libmodsecurity.so.*2.1.0* afterward in the build artifacts:


[modsecurity-v3.0.1]$ ls -l src/.libs
total 172892
-rw-rw-r-- 1 build build 127289914 Apr  3 00:51 libmodsecurity.a
lrwxrwxrwx 1 build build        20 Apr  3 00:51 libmodsecurity.la -> ../
libmodsecurity.la
-rw-rw-r-- 1 build build    819584 Apr  3 00:48
libmodsecurity_la-anchored_set_variable.o
-rw-rw-r-- 1 build build    601432 Apr  3 00:48
libmodsecurity_la-anchored_variable.o
-rw-rw-r-- 1 build build      1050 Apr  3 00:51 libmodsecurity.lai
-rw-rw-r-- 1 build build    742312 Apr  3 00:48
libmodsecurity_la-modsecurity.o
-rw-rw-r-- 1 build build   1027624 Apr  3 00:48
libmodsecurity_la-rule_message.o
-rw-rw-r-- 1 build build   2442416 Apr  3 00:48 libmodsecurity_la-rule.o
-rw-rw-r-- 1 build build    936496 Apr  3 00:48
libmodsecurity_la-rule_script.o
-rw-rw-r-- 1 build build   1205592 Apr  3 00:48
libmodsecurity_la-rules_exceptions.o
-rw-rw-r-- 1 build build   1413432 Apr  3 00:48 libmodsecurity_la-rules.o
-rw-rw-r-- 1 build build    814008 Apr  3 00:48
libmodsecurity_la-run_time_string.o
-rw-rw-r-- 1 build build   2373024 Apr  3 00:48
libmodsecurity_la-transaction.o
-rw-rw-r-- 1 build build    126280 Apr  3 00:48
libmodsecurity_la-unique_id.o
lrwxrwxrwx 1 build build        23 Apr  3 00:51 libmodsecurity.so ->
libmodsecurity.so.2.1.0
lrwxrwxrwx 1 build build        23 Apr  3 00:51 libmodsecurity.so.2 ->
libmodsecurity.so.2.1.0
-rwxrwxr-x 1 build build  37216744 Apr  3 00:51 libmodsecurity.so.2.1.0


and a previous libmodsecurity3.0.0 build (on the same machine, using the
same build steps) has libmodsecurity.so.3.0.0:


[modsecurity-v3.0.0]$ ls -l src/.libs
total 150292
-rw-rw-r-- 1 build build 108625334 Apr  3 00:45 libmodsecurity.a
lrwxrwxrwx 1 build build        20 Apr  3 00:45 libmodsecurity.la -> ../
libmodsecurity.la
-rw-rw-r-- 1 build build    754752 Apr  3 00:42
libmodsecurity_la-anchored_set_variable.o
-rw-rw-r-- 1 build build    572888 Apr  3 00:42
libmodsecurity_la-anchored_variable.o
-rw-rw-r-- 1 build build      1050 Apr  3 00:45 libmodsecurity.lai
-rw-rw-r-- 1 build build   1133712 Apr  3 00:42
libmodsecurity_la-macro_expansion.o
-rw-rw-r-- 1 build build    753320 Apr  3 00:42
libmodsecurity_la-modsecurity.o
-rw-rw-r-- 1 build build   1074248 Apr  3 00:42
libmodsecurity_la-rule_message.o
-rw-rw-r-- 1 build build   2713344 Apr  3 00:42 libmodsecurity_la-rule.o
-rw-rw-r-- 1 build build    927592 Apr  3 00:42
libmodsecurity_la-rule_script.o
-rw-rw-r-- 1 build build   1171128 Apr  3 00:42
libmodsecurity_la-rules_exceptions.o
-rw-rw-r-- 1 build build   1364000 Apr  3 00:42 libmodsecurity_la-rules.o
-rw-rw-r-- 1 build build   2442848 Apr  3 00:42
libmodsecurity_la-transaction.o
-rw-rw-r-- 1 build build    126280 Apr  3 00:42
libmodsecurity_la-unique_id.o
lrwxrwxrwx 1 build build        23 Apr  3 00:45 libmodsecurity.so ->
libmodsecurity.so.3.0.0
lrwxrwxrwx 1 build build        23 Apr  3 00:45 libmodsecurity.so.3 ->
libmodsecurity.so.3.0.0
-rwxrwxr-x 1 build build  32211128 Apr  3 00:45 libmodsecurity.so.3.0.0


Does anyone else see this? How can I be certain that I am getting the
correct shared object?

Thank you,

Gregory

Re: [mod-security-users] REQUEST_COOKIES_NAMES:/regex/ does not work

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

Right, so the reason SecRuleUpdateTargetById wasn't working was because it
was listed in the config file before my rule definition. It's gotta live
*after*. (ref: https://github.com/SpiderLabs/owasp-modsecurity-
crs/blob/v3.0/master/rules/REQUEST-900-EXCLUSION-RULES-
BEFORE-CRS.conf.example#L43)

So for example, the following works:

SecRuleUpdateTargetById 1234123413 "!REQUEST_HEADERS:/Coo.*/"

Because the Cookie request header matches that regex. Of course, as
mentioned above you cannot whitelist specific cookie in this manner, it
would need to be done like so:

SecRule
REQUEST_HEADERS|XML:/*|!REQUEST_HEADERS:Referer|!REQUEST_HEADERS:Cookie
"\b(\d+) ?= ?\1\b|[\'\"](\w+)[\'\"] ?= ?[\'\"]\2\b" \

"phase:2,capture,t:none,t:urlDecodeUni,t:htmlEntityDecode,t:replaceComments,t:compressWhiteSpace,t:lowercase,ctl:auditLogParts=+E,log,auditlog,msg:'SQL
Injection
Attack',id:1234123413,tag:'WEB_ATTACK/SQL_INJECTION',logdata:'%{TX.0}',severity:'2',deny"

SecRule "REQUEST_COOKIES|!REQUEST_COOKIES:/_gac_UA[\d-]+$/" "\b(\d+) ?=
?\1\b|[\'\"](\w+)[\'\"] ?= ?[\'\"]\2\b" \

"phase:2,capture,t:none,t:urlDecodeUni,t:htmlEntityDecode,t:replaceComments,t:compressWhiteSpace,t:lowercase,ctl:auditLogParts=+E,log,auditlog,msg:'SQL
Injection
Attack',id:1234123414,tag:'WEB_ATTACK/SQL_INJECTION',logdata:'%{TX.0}',severity:'2',deny"

But again, using REQUEST_COOKIES as a target is not meaningful because the
regex in question doesn't match the cookie value, only the name+value.



On Mon, Apr 2, 2018 at 2:20 PM, Robert Paprocki <rpaprocki@
fearnothingproductions.net> wrote:

> Okay, so I got the following to work (as expected), ignoring
> SecRuleUpdateTargetById which I've never had much luck with:
>
> SecRule REQUEST_HEADERS|XML:/*|!REQUEST_HEADERS:Referer "\b(\d+) ?=
> ?\1\b|[\'\"](\w+)[\'\"] ?= ?[\'\"]\2\b" \
>         "phase:2,capture,t:none,t:urlDecodeUni,t:htmlEntityDecode,t:
> replaceComments,t:compressWhiteSpace,t:lowercase,ctl:
> auditLogParts=+E,log,auditlog,msg:'SQL Injection
> Attack',id:1234123413,tag:'WEB_ATTACK/SQL_INJECTION',logdata
> :'%{TX.0}',severity:'2',deny"
>
> SecRule ARGS:test "@streq foo" "id:12345,deny,phase:2,msg:'lo
> lnope',sanitiseArg:yomama"
>
> SecAction "ctl:ruleRemoveTargetById=1234123413;REQUEST_HEADERS:Cookie,
> id:12346,phase:1"
>
> Relevent debug logs:
>
> https://gist.github.com/p0pr0ck5/3d7b38c3c182604242449ff0b04c444d
>
> @Eric, because your rule targets REQUEST_HEADERS and not COOKIES, you
> cannot remove a specific cookie from this target. Headers and cookies are
> treated as separated tables. You will either need to use an ignore or craft
> a second rule that looks specifically at cookies.
>
> BTW, you may want to evaluate the regex in question here; what
> specifically are you trying to catch? It matches on a cookie only because
> of how cookies are formed.
>
> On Mon, Apr 2, 2018 at 1:41 PM, Robert Paprocki <
> rpa...@fe...> wrote:
>
>> Hey Christian,
>>
>> On Mon, Apr 2, 2018 at 1:38 PM, Christian Folini <
>> chr...@ne...> wrote:
>>
>>> Hello Eric,
>>>
>>> On Mon, Apr 02, 2018 at 07:31:14PM +0000, Eric Wheeler wrote:
>>> > We have tried the following, but none have worked:
>>> >
>>> >       SecRuleUpdateTargetById 1234123413 "!REQUEST_COOKIES_NAMES:/_gac_
>>> UA-5521579-1/"
>>> >       SecRuleUpdateTargetById 1234123413 "!REQUEST_COOKIES:/_gac_UA-552
>>> 1579-1/"
>>> >
>>> >       SecRuleUpdateTargetById 1234123413 "!REQUEST_HEADERS:/_gac_UA-552
>>> 1579-1/"
>>> >
>>> >       SecRuleUpdateTargetById 1234123413 "!REQUEST_COOKIES_NAMES:_gac_U
>>> A-5521579-1"
>>> >       SecRuleUpdateTargetById 1234123413 "!REQUEST_COOKIES:_gac_UA-5521
>>> 579-1"
>>> >
>>> >
>>> > Interestingly, these two work, but are of course too permissive:
>>> >
>>> >       SecRuleUpdateTargetById 1234123413 "!REQUEST_HEADERS:/./"
>>> >       SecRuleUpdateTargetById 1234123413 "!REQUEST_HEADERS:Cookie"
>>>
>>> If
>>> SecRuleUpdateTargetById 1234123413 "!REQUEST_HEADERS:/./"
>>> works, it's undocumented behaviour. This does not really support regexes.
>>>
>>
>> From https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Man
>> ual-%28v2.x%29#SecRuleUpdateTargetById:
>>
>> Note that is is also possible to use regular expressions in the target
>> specification:
>>
>> SecRuleUpdateTargetById 981172 "!REQUEST_COOKIES:/^appl1_.*/"
>>
>>
>> Interestingly, neither of the following work for me:
>>
>> SecRuleUpdateTargetById 1234123413 "!REQUEST_HEADERS:/./"
>> SecRuleUpdateTargetById 1234123413 "!REQUEST_HEADERS:Cookie"
>>
>> And there is no meaningful log-level 9 debug information to indicate that
>> SecRuleUpdateTargetById did anything (im still walking through
>> https://github.com/SpiderLabs/ModSecurity/blob/72f63
>> 2e9b6b2e63677cfba7e62a47efb87c90b48/apache2/re.c#L198 at this point-
>> busy watching the Falcon 9 launch atm ;) ).
>>
>
>

Re: [mod-security-users] REQUEST_COOKIES_NAMES:/regex/ does not work

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

Hey Robert,

On Mon, Apr 02, 2018 at 01:41:30PM -0700, Robert Paprocki wrote:
> From
> https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual-%28v2.x%29#SecRuleUpdateTargetById
> :
> 
> Note that is is also possible to use regular expressions in the target
> specification:
> 
> SecRuleUpdateTargetById 981172 "!REQUEST_COOKIES:/^appl1_.*/"

Now look at that! Glad you checked. I overlooked this after I had made
up my mind based on the handbook and then confirmed this with the link above.

But either way: If it does not work, then it's of no use. ;(

> And there is no meaningful log-level 9 debug information to indicate that
> SecRuleUpdateTargetById did anything (im still walking through
> https://github.com/SpiderLabs/ModSecurity/blob/72f632e9b6b2e63677cfba7e62a47efb87c90b48/apache2/re.c#L198
> at this point- busy watching the Falcon 9 launch atm ;) ).

SecRuleUpdateTargetById does not report much. But SecRule will.

Ahoj,

Christian


-- 
It is not useful for liberty that we abolish it in order to protect it.
--- Wolfgang Thierse, President of the German Parliament 

Re: [mod-security-users] REQUEST_COOKIES_NAMES:/regex/ does not work

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

Okay, so I got the following to work (as expected), ignoring
SecRuleUpdateTargetById which I've never had much luck with:

SecRule REQUEST_HEADERS|XML:/*|!REQUEST_HEADERS:Referer "\b(\d+) ?=
?\1\b|[\'\"](\w+)[\'\"] ?= ?[\'\"]\2\b" \

"phase:2,capture,t:none,t:urlDecodeUni,t:htmlEntityDecode,t:replaceComments,t:compressWhiteSpace,t:lowercase,ctl:auditLogParts=+E,log,auditlog,msg:'SQL
Injection
Attack',id:1234123413,tag:'WEB_ATTACK/SQL_INJECTION',logdata:'%{TX.0}',severity:'2',deny"

SecRule ARGS:test "@streq foo"
"id:12345,deny,phase:2,msg:'lolnope',sanitiseArg:yomama"

SecAction
"ctl:ruleRemoveTargetById=1234123413;REQUEST_HEADERS:Cookie,id:12346,phase:1"

Relevent debug logs:

https://gist.github.com/p0pr0ck5/3d7b38c3c182604242449ff0b04c444d

@Eric, because your rule targets REQUEST_HEADERS and not COOKIES, you
cannot remove a specific cookie from this target. Headers and cookies are
treated as separated tables. You will either need to use an ignore or craft
a second rule that looks specifically at cookies.

BTW, you may want to evaluate the regex in question here; what specifically
are you trying to catch? It matches on a cookie only because of how cookies
are formed.

On Mon, Apr 2, 2018 at 1:41 PM, Robert Paprocki <
rpa...@fe...> wrote:

> Hey Christian,
>
> On Mon, Apr 2, 2018 at 1:38 PM, Christian Folini <
> chr...@ne...> wrote:
>
>> Hello Eric,
>>
>> On Mon, Apr 02, 2018 at 07:31:14PM +0000, Eric Wheeler wrote:
>> > We have tried the following, but none have worked:
>> >
>> >       SecRuleUpdateTargetById 1234123413 "!REQUEST_COOKIES_NAMES:/_gac_
>> UA-5521579-1/"
>> >       SecRuleUpdateTargetById 1234123413 "!REQUEST_COOKIES:/_gac_UA-552
>> 1579-1/"
>> >
>> >       SecRuleUpdateTargetById 1234123413 "!REQUEST_HEADERS:/_gac_UA-552
>> 1579-1/"
>> >
>> >       SecRuleUpdateTargetById 1234123413 "!REQUEST_COOKIES_NAMES:_gac_U
>> A-5521579-1"
>> >       SecRuleUpdateTargetById 1234123413 "!REQUEST_COOKIES:_gac_UA-5521
>> 579-1"
>> >
>> >
>> > Interestingly, these two work, but are of course too permissive:
>> >
>> >       SecRuleUpdateTargetById 1234123413 "!REQUEST_HEADERS:/./"
>> >       SecRuleUpdateTargetById 1234123413 "!REQUEST_HEADERS:Cookie"
>>
>> If
>> SecRuleUpdateTargetById 1234123413 "!REQUEST_HEADERS:/./"
>> works, it's undocumented behaviour. This does not really support regexes.
>>
>
> From https://github.com/SpiderLabs/ModSecurity/wiki/Reference-
> Manual-%28v2.x%29#SecRuleUpdateTargetById:
>
> Note that is is also possible to use regular expressions in the target
> specification:
>
> SecRuleUpdateTargetById 981172 "!REQUEST_COOKIES:/^appl1_.*/"
>
>
> Interestingly, neither of the following work for me:
>
> SecRuleUpdateTargetById 1234123413 "!REQUEST_HEADERS:/./"
> SecRuleUpdateTargetById 1234123413 "!REQUEST_HEADERS:Cookie"
>
> And there is no meaningful log-level 9 debug information to indicate that
> SecRuleUpdateTargetById did anything (im still walking through
> https://github.com/SpiderLabs/ModSecurity/blob/
> 72f632e9b6b2e63677cfba7e62a47efb87c90b48/apache2/re.c#L198 at this point-
> busy watching the Falcon 9 launch atm ;) ).
>

Re: [mod-security-users] REQUEST_COOKIES_NAMES:/regex/ does not work

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

Hey Christian,

On Mon, Apr 2, 2018 at 1:38 PM, Christian Folini <
chr...@ne...> wrote:

> Hello Eric,
>
> On Mon, Apr 02, 2018 at 07:31:14PM +0000, Eric Wheeler wrote:
> > We have tried the following, but none have worked:
> >
> >       SecRuleUpdateTargetById 1234123413 "!REQUEST_COOKIES_NAMES:/_gac_
> UA-5521579-1/"
> >       SecRuleUpdateTargetById 1234123413 "!REQUEST_COOKIES:/_gac_UA-
> 5521579-1/"
> >
> >       SecRuleUpdateTargetById 1234123413 "!REQUEST_HEADERS:/_gac_UA-
> 5521579-1/"
> >
> >       SecRuleUpdateTargetById 1234123413 "!REQUEST_COOKIES_NAMES:_gac_
> UA-5521579-1"
> >       SecRuleUpdateTargetById 1234123413 "!REQUEST_COOKIES:_gac_UA-
> 5521579-1"
> >
> >
> > Interestingly, these two work, but are of course too permissive:
> >
> >       SecRuleUpdateTargetById 1234123413 "!REQUEST_HEADERS:/./"
> >       SecRuleUpdateTargetById 1234123413 "!REQUEST_HEADERS:Cookie"
>
> If
> SecRuleUpdateTargetById 1234123413 "!REQUEST_HEADERS:/./"
> works, it's undocumented behaviour. This does not really support regexes.
>

From
https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual-%28v2.x%29#SecRuleUpdateTargetById
:

Note that is is also possible to use regular expressions in the target
specification:

SecRuleUpdateTargetById 981172 "!REQUEST_COOKIES:/^appl1_.*/"


Interestingly, neither of the following work for me:

SecRuleUpdateTargetById 1234123413 "!REQUEST_HEADERS:/./"
SecRuleUpdateTargetById 1234123413 "!REQUEST_HEADERS:Cookie"

And there is no meaningful log-level 9 debug information to indicate that
SecRuleUpdateTargetById did anything (im still walking through
https://github.com/SpiderLabs/ModSecurity/blob/72f632e9b6b2e63677cfba7e62a47efb87c90b48/apache2/re.c#L198
at this point- busy watching the Falcon 9 launch atm ;) ).

Re: [mod-security-users] REQUEST_COOKIES_NAMES:/regex/ does not work

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

Hello Eric,

On Mon, Apr 02, 2018 at 07:31:14PM +0000, Eric Wheeler wrote:
> We have tried the following, but none have worked:
> 
> 	SecRuleUpdateTargetById 1234123413 "!REQUEST_COOKIES_NAMES:/_gac_UA-5521579-1/"
> 	SecRuleUpdateTargetById 1234123413 "!REQUEST_COOKIES:/_gac_UA-5521579-1/"
> 
> 	SecRuleUpdateTargetById 1234123413 "!REQUEST_HEADERS:/_gac_UA-5521579-1/"
> 
> 	SecRuleUpdateTargetById 1234123413 "!REQUEST_COOKIES_NAMES:_gac_UA-5521579-1"
> 	SecRuleUpdateTargetById 1234123413 "!REQUEST_COOKIES:_gac_UA-5521579-1"
> 
> 
> Interestingly, these two work, but are of course too permissive:
> 
> 	SecRuleUpdateTargetById 1234123413 "!REQUEST_HEADERS:/./"
> 	SecRuleUpdateTargetById 1234123413 "!REQUEST_HEADERS:Cookie"

If 
SecRuleUpdateTargetById 1234123413 "!REQUEST_HEADERS:/./" 
works, it's undocumented behaviour. This does not really support regexes.

However, this is meant to work:
SecRuleUpdateTargetById 1234123413 "!REQUEST_COOKIES:_gac_UA-5521579-1"

Could you please raise your ModSec Debug level to 9 and check what is
going on? You should see this cookied added to an ignore list and then
when 1234123413 is being executed, it should be removed from the list
of targets for the rule.

If it really does not work, you might have to do a runtime rule exclusion
via a ctl statement.

Ahoj,

Christian


-- 
Integrity without knowledge is weak and useless, and knowledge
without integrity is dangerous and dreadful.          
-- Samuel Johnson

[mod-security-users] REQUEST_COOKIES_NAMES:/regex/ does not work

[Eric W. <mod...@li...>]

Hello all,

We've been scratching our heads trying to whitelist Google cookies that 
are breaking some sites. The rule we are hitting is:

SecRule REQUEST_HEADERS|XML:/*|!REQUEST_HEADERS:Referer "\b(\d+) ?= ?\1\b|[\'\"](\w+)[\'\"] ?= ?[\'\"]\2\b" \
        "phase:2,capture,t:none,t:urlDecodeUni,t:htmlEntityDecode,t:replaceComments,t:compressWhiteSpace,t:lowercase,ctl:auditLogParts=+E,log,auditlog,msg:'SQL Injection Attack',id:'1234123413',tag:'WEB_ATTACK/SQL_INJECTION',logdata:'%{TX.0}',severity:'2'"

This is the cookie:

Cookie: _gac_UA-5521579-1=1.1522352332.EAlalQobChMI5trKIKSS2gIV0IKzCh2vIQeDEAAYASAAEgICPPD_8wE


This is the error that we are getting:

[Mon Apr 02 15:21:20.137112 2018] [:error] [pid 7908:tid 140248145336064] [client 24.20.122.25] ModSecurity: Warning. Pattern match "\\\\b(\\\\d+) ?= ?\\\\1\\\\b|[\\\\'\\"](\\\\w+)[\\\\'\\"] ?= ?[\\\\'\\"]\\\\2\\\\b" at REQUEST_HEADERS:Cookie. [file "/usr/local/apache/conf/modsec2.user.conf"] [line "98"] [id "1234123413"] [msg "SQL Injection Attack"] [data "1=1"] [severity "CRITICAL"] [tag "WEB_ATTACK/SQL_INJECTION"] [hostname "example.com"] [uri "/"] [unique_id "WsKCsMYURboAAB7kVSwAAADA"]


We have tried the following, but none have worked:

	SecRuleUpdateTargetById 1234123413 "!REQUEST_COOKIES_NAMES:/_gac_UA-5521579-1/"
	SecRuleUpdateTargetById 1234123413 "!REQUEST_COOKIES:/_gac_UA-5521579-1/"

	SecRuleUpdateTargetById 1234123413 "!REQUEST_HEADERS:/_gac_UA-5521579-1/"

	SecRuleUpdateTargetById 1234123413 "!REQUEST_COOKIES_NAMES:_gac_UA-5521579-1"
	SecRuleUpdateTargetById 1234123413 "!REQUEST_COOKIES:_gac_UA-5521579-1"


Interestingly, these two work, but are of course too permissive:

	SecRuleUpdateTargetById 1234123413 "!REQUEST_HEADERS:/./"
	SecRuleUpdateTargetById 1234123413 "!REQUEST_HEADERS:Cookie"


We are running ModSecurity 2.9.0 under WHM 58.0.52

Can anyone suggest a way to solve this?

Thank you for your help!

--
Eric Wheeler

[mod-security-users] ModSecurity version 3.0.1 announcement

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



It is a pleasure to announce the release of ModSecurity version 3.0.1
(libModSecurity). This version contains improvements, fixes and new features.

The most important new feature is the support for the libMaxMinddb,
popularly kown as the new version of the GeoIP library. 

There is a splendid performance upgrade on v3.0.1. A significant amount of
work was placed on how to handle the memory usage more efficiently, which
leaded to great improvements in terms of latency and requests per second.

The list with the full changes can be found on the project CHANGES
file, available here:
- - https://github.com/SpiderLabs/ModSecurity/releases/tag/v3.0.1/CHANGES

The list of open issues is available on GitHub:
- - https://github.com/SpiderLabs/ModSecurity/labels/3.x

Thanks to everybody who helped in this process: reporting issues, making
comments and suggestions, sending patches and so on.

Further details on the compilation process for ModSecurity v3, can be found on
the project README:
 - https://github.com/SpiderLabs/ModSecurity/tree/v3/master#compilation

Complementary documentation for the connectors are available here:
 - nginx: https://github.com/SpiderLabs/ModSecurity-nginx/#compilation
 - Apache: https://github.com/SpiderLabs/ModSecurity-apache/#compilation


IMPORTANT: ModSecurity version 2 will be available and maintained parallel
to version 3. There is no ETA to deprecate the version 2.x. New features
and major improvements will be implemented on version 3.x. Security or major
bugs are planned to be back ported. Version 2 and version 3 has a completely
independent development/release cycle.


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

Trustwave | SMART SECURITY ON DEMAND
www.trustwave.com

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iF0EARECAB0WIQQZDvrMoen6RmqOzZzm37CM6LESdwUCWsIiCAAKCRDm37CM6LES
d8DzAKCpQmKnYFVcWD99ue+nxihZZep8BACgsJxQu9UrapxBBZu0cJMEekwHBzo=
=OTkS
-----END PGP SIGNATURE-----

Re: [mod-security-users] Initial setup mod_security with httpd-guardian

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

This seems like a better questions for the httpd-guardian developers, no?

Sent from my iPhone

> On Mar 29, 2018, at 20:09, Chip <jef...@gm...> wrote:
> 
> Anyone on this list have experience with using mod_security running on
> WHM/Cpanel with httpd-guardian?
> 
> When I dive into the httpd-guardian perl script there are some settings
> I could use some clarification on such as:
> 
> 1) is "spread" required to use httpd-guardian?
> 2) the perl script httpd-guardian when started and with the entry for
> spread set to not run, I do not see any port 3333 open as should be.
> 3) when httpd-guardian set to run (toggled in the script) I get an error
> message about spread - so I'm assuming it is required to use the service
> effectively, however;
> 4) the wording of the instructions in the script is not very clear or
> written in a way that leaves it open to interpretation whether or not
> spread is required.
> 
> Thank you.
> 
> ------------------------------------------------------------------------------
> 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/

[mod-security-users] Initial setup mod_security with httpd-guardian

[Chip <jef...@gm...>]

Anyone on this list have experience with using mod_security running on
WHM/Cpanel with httpd-guardian?

When I dive into the httpd-guardian perl script there are some settings
I could use some clarification on such as:

1) is "spread" required to use httpd-guardian?
2) the perl script httpd-guardian when started and with the entry for
spread set to not run, I do not see any port 3333 open as should be.
3) when httpd-guardian set to run (toggled in the script) I get an error
message about spread - so I'm assuming it is required to use the service
effectively, however;
4) the wording of the instructions in the script is not very clear or
written in a way that leaves it open to interpretation whether or not
spread is required.

Thank you.

Re: [mod-security-users] SecRuleRemoveByTag not working

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

Hello,

On Wed, Mar 28, 2018 at 10:52:46PM +0200, Eirik Øverby - ModSecurity wrote:
> > I just checked again. SecRuleRemoveByTag works for me. I think you need to
> > dig down into your problem and if you find it's a bug, then issue a bug
> > report.
> 
> Not sure how to dig deeper; this should be a pretty straight-forward use
> case which I'd expect to "just work". What's the preferred place to post a
> report? And what details should I give that weren't already given here, if
> any?

Here is the place:
https://github.com/SpiderLabs/ModSecurity/issues

And the level of information you provided here seems about right.

Ahoj,

Christian


> 
> /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] SecRuleRemoveByTag not working

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

Hi,

>>> Hmm. That is odd. It works for me:
>>> 
>>> $> echo 'SecRuleRemoveByTag "platform-apache"' > /tmp/rule.conf
>>> $> /usr/src/modsecurity/modsecurity-v3.0.0/tools/rules-check/modsec-rules-check /tmp/rule.conf 
>>> : /tmp/rule.conf  --  Loaded 0 rules.
>>> Test ok.

To add to the mystery:

# modsec-rules-check 'SecRuleRemoveByTag "attack-injection-php"'
: SecRuleRemoveByTag "attack-injection-php"  --  RemoveByTagattack-injection-phpLoaded -1 rules.
   Rules error. File: <<reference missing or not informed>>. Line: 1. Column: 41. syntax error, unexpected end of file 
Test failed.

# echo 'SecRuleRemoveByTag "attack-injection-php"' > t.conf
# modsec-rules-check t.conf 
: t.conf  --  RemoveByTagattack-injection-php
Loaded -1 rules.
   Rules error. File: t.conf. Line: 1. Column: 42. syntax error, unexpected end of file 
Test failed.

So it balks on EOF in both cases.

>> 
>> Which version and OS is this?
> 
> $> cat /etc/issue
> Ubuntu 16.04.4 LTS \n \l
> 
> $> uname -a
> Linux anastasia 4.13.0-37-generic #42~16.04.1-Ubuntu SMP Wed Mar 7 16:03:28 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

# uname -a
FreeBSD nets-acs.test.modirum.com 10.4-RELEASE-p3 FreeBSD 10.4-RELEASE-p3 #0: Tue Nov 14 09:43:55 UTC 2017     ro...@am...:/usr/obj/usr/src/sys/GENERIC  amd64


> $> ldd /usr/src/modsecurity/modsecurity-v3.0.0/tools/rules-check/modsec-rules-check
> linux-vdso.so.1 =>  (0x00007fffad7b2000)
> libcurl-gnutls.so.4 => /usr/lib/x86_64-linux-gnu/libcurl-gnutls.so.4 (0x00007f2adaddf000)
> libGeoIP.so.1 => /usr/lib/x86_64-linux-gnu/libGeoIP.so.1 (0x00007f2adabae000)
> libpcre.so.1 => /usr/local/pcre/lib/libpcre.so.1 (0x00007f2ada990000)
> libyajl.so.2 => /usr/lib/x86_64-linux-gnu/libyajl.so.2 (0x00007f2ada785000)
> libxml2.so.2 => /usr/lib/x86_64-linux-gnu/libxml2.so.2 (0x00007f2ada3ca000)
> librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f2ada1c2000)
> libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f2ad9e40000)
> libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f2ad9b37000)
> libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f2ad9921000)
> libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f2ad9704000)
> libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f2ad933a000)
> libidn.so.11 => /usr/lib/x86_64-linux-gnu/libidn.so.11 (0x00007f2ad9107000)
> librtmp.so.1 => /usr/lib/x86_64-linux-gnu/librtmp.so.1 (0x00007f2ad8eeb000)
> libnettle.so.6 => /usr/lib/x86_64-linux-gnu/libnettle.so.6 (0x00007f2ad8cb5000)
> libgnutls.so.30 => /usr/lib/x86_64-linux-gnu/libgnutls.so.30 (0x00007f2ad8985000)
> libgssapi_krb5.so.2 => /usr/lib/x86_64-linux-gnu/libgssapi_krb5.so.2 (0x00007f2ad873b000)
> liblber-2.4.so.2 => /usr/lib/x86_64-linux-gnu/liblber-2.4.so.2 (0x00007f2ad852c000)
> libldap_r-2.4.so.2 => /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2 (0x00007f2ad82db000)
> libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f2ad80c1000)
> libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f2ad7ebd000)
> libicuuc.so.55 => /usr/lib/x86_64-linux-gnu/libicuuc.so.55 (0x00007f2ad7b29000)
> liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x00007f2ad7907000)
> /lib64/ld-linux-x86-64.so.2 (0x00007f2adb04c000)
> libhogweed.so.4 => /usr/lib/x86_64-linux-gnu/libhogweed.so.4 (0x00007f2ad76d4000)
> libgmp.so.10 => /usr/lib/x86_64-linux-gnu/libgmp.so.10 (0x00007f2ad7454000)
> libp11-kit.so.0 => /usr/lib/x86_64-linux-gnu/libp11-kit.so.0 (0x00007f2ad71f0000)
> libtasn1.so.6 => /usr/lib/x86_64-linux-gnu/libtasn1.so.6 (0x00007f2ad6fdd000)
> libkrb5.so.3 => /usr/lib/x86_64-linux-gnu/libkrb5.so.3 (0x00007f2ad6d0b000)
> libk5crypto.so.3 => /usr/lib/x86_64-linux-gnu/libk5crypto.so.3 (0x00007f2ad6adc000)
> libcom_err.so.2 => /lib/x86_64-linux-gnu/libcom_err.so.2 (0x00007f2ad68d8000)
> libkrb5support.so.0 => /usr/lib/x86_64-linux-gnu/libkrb5support.so.0 (0x00007f2ad66cd000)
> libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x00007f2ad64b2000)
> libsasl2.so.2 => /usr/lib/x86_64-linux-gnu/libsasl2.so.2 (0x00007f2ad6297000)
> libgssapi.so.3 => /usr/lib/x86_64-linux-gnu/libgssapi.so.3 (0x00007f2ad6056000)
> libicudata.so.55 => /usr/lib/x86_64-linux-gnu/libicudata.so.55 (0x00007f2ad459f000)
> libffi.so.6 => /usr/lib/x86_64-linux-gnu/libffi.so.6 (0x00007f2ad4397000)
> libkeyutils.so.1 => /lib/x86_64-linux-gnu/libkeyutils.so.1 (0x00007f2ad4193000)
> libheimntlm.so.0 => /usr/lib/x86_64-linux-gnu/libheimntlm.so.0 (0x00007f2ad3f8a000)
> libkrb5.so.26 => /usr/lib/x86_64-linux-gnu/libkrb5.so.26 (0x00007f2ad3d00000)
> libasn1.so.8 => /usr/lib/x86_64-linux-gnu/libasn1.so.8 (0x00007f2ad3a5e000)
> libhcrypto.so.4 => /usr/lib/x86_64-linux-gnu/libhcrypto.so.4 (0x00007f2ad382b000)
> libroken.so.18 => /usr/lib/x86_64-linux-gnu/libroken.so.18 (0x00007f2ad3615000)
> libwind.so.0 => /usr/lib/x86_64-linux-gnu/libwind.so.0 (0x00007f2ad33ec000)
> libheimbase.so.1 => /usr/lib/x86_64-linux-gnu/libheimbase.so.1 (0x00007f2ad31dd000)
> libhx509.so.5 => /usr/lib/x86_64-linux-gnu/libhx509.so.5 (0x00007f2ad2f92000)
> libsqlite3.so.0 => /usr/lib/x86_64-linux-gnu/libsqlite3.so.0 (0x00007f2ad2cbd000)
> libcrypt.so.1 => /lib/x86_64-linux-gnu/libcrypt.so.1 (0x00007f2ad2a85000)

# ldd `which modsec-rules-check`
/usr/local/bin/modsec-rules-check:
   libcurl.so.4 => /usr/local/lib/libcurl.so.4 (0x800958000)
   libGeoIP.so.1 => /usr/local/lib/libGeoIP.so.1 (0x800bbd000)
   libpcre.so.1 => /usr/local/lib/libpcre.so.1 (0x800e01000)
   libyajl.so.2 => /usr/local/lib/libyajl.so.2 (0x801079000)
   libxml2.so.2 => /usr/local/lib/libxml2.so.2 (0x801282000)
   libz.so.6 => /lib/libz.so.6 (0x80161c000)
   liblzma.so.5 => /usr/lib/liblzma.so.5 (0x801833000)
   librt.so.1 => /usr/lib/librt.so.1 (0x801a5c000)
   libstdc++.so.6 => /usr/local/lib/gcc6/libstdc++.so.6 (0x801c62000)
   libm.so.5 => /lib/libm.so.5 (0x801ff7000)
   libgcc_s.so.1 => /usr/local/lib/gcc6/libgcc_s.so.1 (0x802220000)
   libc.so.7 => /lib/libc.so.7 (0x802436000)
   libnghttp2.so.14 => /usr/local/lib/libnghttp2.so.14 (0x8027e5000)
   libssl.so.9 => /usr/local/lib/libssl.so.9 (0x802a0b000)
   libcrypto.so.9 => /usr/local/lib/libcrypto.so.9 (0x802e00000)
   libthr.so.3 => /lib/libthr.so.3 (0x803253000)

Shorter list but that's a FreeBSD-ism I suppose. Also I know we build our stuff without kerberos which cuts down on deps quite a bit.


> I just checked again. SecRuleRemoveByTag works for me. I think you need
> to dig down into your problem and if you find it's a bug, then issue a bug
> report.

Not sure how to dig deeper; this should be a pretty straight-forward use case which I'd expect to "just work". What's the preferred place to post a report? And what details should I give that weren't already given here, if any?

/Eirik

Re: [mod-security-users] SecRuleRemoveByTag not working

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

Hey, hey,

On Wed, Mar 28, 2018 at 10:26:05PM +0200, Eirik Øverby - ModSecurity wrote:
> Hi there,
> 
> > Hmm. That is odd. It works for me:
> > 
> > $> echo 'SecRuleRemoveByTag "platform-apache"' > /tmp/rule.conf
> > $> /usr/src/modsecurity/modsecurity-v3.0.0/tools/rules-check/modsec-rules-check /tmp/rule.conf 
> > : /tmp/rule.conf  --  Loaded 0 rules.
> > Test ok.
> 
> Which version and OS is this?

$> cat /etc/issue
Ubuntu 16.04.4 LTS \n \l

$> uname -a
Linux anastasia 4.13.0-37-generic #42~16.04.1-Ubuntu SMP Wed Mar 7 16:03:28 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

$> ldd /usr/src/modsecurity/modsecurity-v3.0.0/tools/rules-check/modsec-rules-check
linux-vdso.so.1 =>  (0x00007fffad7b2000)
libcurl-gnutls.so.4 => /usr/lib/x86_64-linux-gnu/libcurl-gnutls.so.4 (0x00007f2adaddf000)
libGeoIP.so.1 => /usr/lib/x86_64-linux-gnu/libGeoIP.so.1 (0x00007f2adabae000)
libpcre.so.1 => /usr/local/pcre/lib/libpcre.so.1 (0x00007f2ada990000)
libyajl.so.2 => /usr/lib/x86_64-linux-gnu/libyajl.so.2 (0x00007f2ada785000)
libxml2.so.2 => /usr/lib/x86_64-linux-gnu/libxml2.so.2 (0x00007f2ada3ca000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f2ada1c2000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f2ad9e40000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f2ad9b37000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f2ad9921000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f2ad9704000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f2ad933a000)
libidn.so.11 => /usr/lib/x86_64-linux-gnu/libidn.so.11 (0x00007f2ad9107000)
librtmp.so.1 => /usr/lib/x86_64-linux-gnu/librtmp.so.1 (0x00007f2ad8eeb000)
libnettle.so.6 => /usr/lib/x86_64-linux-gnu/libnettle.so.6 (0x00007f2ad8cb5000)
libgnutls.so.30 => /usr/lib/x86_64-linux-gnu/libgnutls.so.30 (0x00007f2ad8985000)
libgssapi_krb5.so.2 => /usr/lib/x86_64-linux-gnu/libgssapi_krb5.so.2 (0x00007f2ad873b000)
liblber-2.4.so.2 => /usr/lib/x86_64-linux-gnu/liblber-2.4.so.2 (0x00007f2ad852c000)
libldap_r-2.4.so.2 => /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2 (0x00007f2ad82db000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f2ad80c1000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f2ad7ebd000)
libicuuc.so.55 => /usr/lib/x86_64-linux-gnu/libicuuc.so.55 (0x00007f2ad7b29000)
liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x00007f2ad7907000)
/lib64/ld-linux-x86-64.so.2 (0x00007f2adb04c000)
libhogweed.so.4 => /usr/lib/x86_64-linux-gnu/libhogweed.so.4 (0x00007f2ad76d4000)
libgmp.so.10 => /usr/lib/x86_64-linux-gnu/libgmp.so.10 (0x00007f2ad7454000)
libp11-kit.so.0 => /usr/lib/x86_64-linux-gnu/libp11-kit.so.0 (0x00007f2ad71f0000)
libtasn1.so.6 => /usr/lib/x86_64-linux-gnu/libtasn1.so.6 (0x00007f2ad6fdd000)
libkrb5.so.3 => /usr/lib/x86_64-linux-gnu/libkrb5.so.3 (0x00007f2ad6d0b000)
libk5crypto.so.3 => /usr/lib/x86_64-linux-gnu/libk5crypto.so.3 (0x00007f2ad6adc000)
libcom_err.so.2 => /lib/x86_64-linux-gnu/libcom_err.so.2 (0x00007f2ad68d8000)
libkrb5support.so.0 => /usr/lib/x86_64-linux-gnu/libkrb5support.so.0 (0x00007f2ad66cd000)
libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x00007f2ad64b2000)
libsasl2.so.2 => /usr/lib/x86_64-linux-gnu/libsasl2.so.2 (0x00007f2ad6297000)
libgssapi.so.3 => /usr/lib/x86_64-linux-gnu/libgssapi.so.3 (0x00007f2ad6056000)
libicudata.so.55 => /usr/lib/x86_64-linux-gnu/libicudata.so.55 (0x00007f2ad459f000)
libffi.so.6 => /usr/lib/x86_64-linux-gnu/libffi.so.6 (0x00007f2ad4397000)
libkeyutils.so.1 => /lib/x86_64-linux-gnu/libkeyutils.so.1 (0x00007f2ad4193000)
libheimntlm.so.0 => /usr/lib/x86_64-linux-gnu/libheimntlm.so.0 (0x00007f2ad3f8a000)
libkrb5.so.26 => /usr/lib/x86_64-linux-gnu/libkrb5.so.26 (0x00007f2ad3d00000)
libasn1.so.8 => /usr/lib/x86_64-linux-gnu/libasn1.so.8 (0x00007f2ad3a5e000)
libhcrypto.so.4 => /usr/lib/x86_64-linux-gnu/libhcrypto.so.4 (0x00007f2ad382b000)
libroken.so.18 => /usr/lib/x86_64-linux-gnu/libroken.so.18 (0x00007f2ad3615000)
libwind.so.0 => /usr/lib/x86_64-linux-gnu/libwind.so.0 (0x00007f2ad33ec000)
libheimbase.so.1 => /usr/lib/x86_64-linux-gnu/libheimbase.so.1 (0x00007f2ad31dd000)
libhx509.so.5 => /usr/lib/x86_64-linux-gnu/libhx509.so.5 (0x00007f2ad2f92000)
libsqlite3.so.0 => /usr/lib/x86_64-linux-gnu/libsqlite3.so.0 (0x00007f2ad2cbd000)
libcrypt.so.1 => /lib/x86_64-linux-gnu/libcrypt.so.1 (0x00007f2ad2a85000)

(Lines moved to the left to fit on the line in most cases).

> > ModSecurity has a tendency to make mistakes when it counts numbers and
> > lines.  I usually tweak around a dozen times until I am sure what
> > line/column it is complaining about.
> 
> Yeah but comparing the first and second tests it seems pretty clear (EOF
> error) it's not actually even trying to parse the rule, it simply doesn't
> see the end of it.

Agree.

> OK, I've only tried excluding individual rules, showing that the general
> idea works. The tag variant doesn't seem to work at all - not even if I
> enable one from the OWASP example files.

I just checked again. SecRuleRemoveByTag works for me. I think you need
to dig down into your problem and if you find it's a bug, then issue a bug
report.

Ahoj,

Christian



> 
> /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] SecRuleRemoveByTag not working

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

Hi there,

> Hmm. That is odd. It works for me:
> 
> $> echo 'SecRuleRemoveByTag "platform-apache"' > /tmp/rule.conf
> $> /usr/src/modsecurity/modsecurity-v3.0.0/tools/rules-check/modsec-rules-check /tmp/rule.conf 
> : /tmp/rule.conf  --  Loaded 0 rules.
> Test ok.

Which version and OS is this?


>> : t.conf  --  RemoveByTagplatform-apache
>> Loaded -1 rules.
>>   Rules error. File: t.conf. Line: 1. Column: 57. syntax error, unexpected Operator RX (content only) 
>> Test failed.
>> 
>> There is no column 57. It's like it doesn't see the end of the lines, so it's concatenating.
> 
> ModSecurity has a tendency to make mistakes when it counts numbers and lines.
> I usually tweak around a dozen times until I am sure what line/column it is 
> complaining about.

Yeah but comparing the first and second tests it seems pretty clear (EOF error) it's not actually even trying to parse the rule, it simply doesn't see the end of it.

>> NOTE: SecRuleRemoveById works as expected in all tests and scenarios.
> 
> Unfortunately, it does not. 
> 
> Here is my take on SecRuleRemoveById:
> 
> # works
> SecRuleRemoveById 930120
> SecRuleRemoveById 932160
> SecRuleRemoveById 930120-932160
> SecRuleRemoveById 1-932160
> 
> # fails to work properly
> SecRuleRemoveById 930120,932160
> 
> # fails with parsing error
> SecRuleRemoveById 99-932160
> 
> The latter is really odd, I think.

OK, I've only tried excluding individual rules, showing that the general idea works. The tag variant doesn't seem to work at all - not even if I enable one from the OWASP example files.

/Eirik

Re: [mod-security-users] SecRuleRemoveByTag not working

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

Hello Eirik,

On Wed, Mar 28, 2018 at 08:13:40PM +0200, Eirik Øverby - ModSecurity wrote:
> If I create a file with a single line:
>  SecRuleRemoveByTag "platform-apache"
> 
> And run modsec-rules-check against it, I get:
> 
> : t.conf  --  RemoveByTagplatform-apache
> Loaded -1 rules.
>    Rules error. File: t.conf. Line: 1. Column: 37. syntax error, unexpected end of file 
> Test failed.

Hmm. That is odd. It works for me:

$> echo 'SecRuleRemoveByTag "platform-apache"' > /tmp/rule.conf
$> /usr/src/modsecurity/modsecurity-v3.0.0/tools/rules-check/modsec-rules-check /tmp/rule.conf 
 : /tmp/rule.conf  --  Loaded 0 rules.
Test ok.

> : t.conf  --  RemoveByTagplatform-apache
> Loaded -1 rules.
>    Rules error. File: t.conf. Line: 1. Column: 57. syntax error, unexpected Operator RX (content only) 
> Test failed.
> 
> There is no column 57. It's like it doesn't see the end of the lines, so it's concatenating.

ModSecurity has a tendency to make mistakes when it counts numbers and lines.
I usually tweak around a dozen times until I am sure what line/column it is 
complaining about.

> NOTE: SecRuleRemoveById works as expected in all tests and scenarios.

Unfortunately, it does not. 

Here is my take on SecRuleRemoveById:

# works
SecRuleRemoveById 930120
SecRuleRemoveById 932160
SecRuleRemoveById 930120-932160
SecRuleRemoveById 1-932160

# fails to work properly
SecRuleRemoveById 930120,932160

# fails with parsing error
SecRuleRemoveById 99-932160

The latter is really odd, I think.

Ahoj,

Christian


-- 
If it could be proved that two plus two is five, then it could be 
proved that five is not five, and then there would be no claim that 
could not be proved, and math would be a lot of bunk.
-- George Boolos

[mod-security-users] SecRuleRemoveByTag not working

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

Hi,

we're trying to use stuff like
 SecRuleRemoveByTag "platform-apache"
to remove entirely uninteresting rules from our modsecurity configuration without actually touching the OWASP rule file.

If I create a file with a single line:
 SecRuleRemoveByTag "platform-apache"

And run modsec-rules-check against it, I get:

: t.conf  --  RemoveByTagplatform-apache
Loaded -1 rules.
   Rules error. File: t.conf. Line: 1. Column: 37. syntax error, unexpected end of file 
Test failed.

If I add a second line, with "platform-windows" for instance, I get:

: t.conf  --  RemoveByTagplatform-apache
Loaded -1 rules.
   Rules error. File: t.conf. Line: 1. Column: 57. syntax error, unexpected Operator RX (content only) 
Test failed.

There is no column 57. It's like it doesn't see the end of the lines, so it's concatenating.

Anyone else seen this?
Getting the same kind of errors when trying to load a complete config (with a line like these at the end) through nginx, or using modsecurity_rules directive in nginx.conf.

NOTE: SecRuleRemoveById works as expected in all tests and scenarios.

Wbr
/Eirik

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

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

Hi,

On Tue, Mar 27, 2018 at 5:17 PM Robert Paprocki <
rpa...@fe...> wrote:

> It's encouraging to see this discussion taking place. A few observations,
> as a member of the community who has not had time for significant
> engagement in either the CRS or libmodsecurity projects in the last year or
> so:
>
>
First, https://github.com/SpiderLabs/ModSecurity/issues/1011 looks like a
> placeholder card to mark that a feature has not been implemented. Up until
> its closure in October 2017, there was no discussion or notation to
> indicate that this feature *would not* be implemented. Indeed, most other
> cards with this issue tag do not have any discussion, only a note that
> indicating their completion, so there's nothing in this issue, apart from
> an abrupt note and closure, that the community can reference that would
> indicate that the feature will not make it into libmodsecurity. I don't
> call seeing any solicitation from developers to the community about the
> usefulness of PERF_*, and I don't think its reasonable to say that there
> has been no community care about these variables until now, because the
> card in question wasn't a call for discussion- it was a placeholder. So,
> with all respect, it seems a little disingenuous to claim "no one cared
> about this we're not going to support it"- from an outside observation,
> there has *always* been an expectation that this feature would be
> available someday.
>

I canot change your perspective, all I can tell is that there are members
of this community that thinks otherwise, as the example of:
https://github.com/SpiderLabs/ModSecurity/issues/1139


> Second, stap and friends simply are not an equivalent replacement for
> PERF_*. For one, deploying and using systemtap isn't an option for
> technical reasons. It is a complex, nuanced tool that takes substantial
> effort to use, and trying to troubleshoot stap errors or malfunctions for
> less-advanced users is, put lightly, a daunting task. Yes, having a working
> set of systemtap scripts designed to introspect libmodsecurity is useful.
> It's a wonderful opportunity. But comparing systemtap output and natively
> integrated SecRules DSL is apples and oranges. PERF_* provides the ability
> to extend and alter ruleset functionality; systemtap introspection is a
> passive output. These are fundamentally different approaches.
>

The version 3 is a complete rewrite. The motivations are written here -

https://www.trustwave.com/Resources/SpiderLabs-Blog/An-Overview-of-the-Upcoming-libModSecurity/

There are fundamental changes all around the place. All of them is meant to
be for benefit of the user. Comparing v3 to v2 is kind compare a orange to
an apple :) And I failed to see why the systemtap is not a replacement. Can
you share with us your concerns?

The performance was treatedd on the very first announcement altogether with
SystemTap and others ideas there are new and change the way that the old
ModSecurity works (v2).

We don't want to loose performance unless it is extremely necessary.

Also, there is always the v2. There is not point to make v3 equals to v2.
Better use v2 instead don't you agree?

Regarding the openresty-systemtap-toolkit, this is a wonderful repository
> of examples and targeted scripts. It is a useful reference point, but it's
> just that- a reference point. It is not actively maintained at this time,
> and several of the scripts do not work with even modestly recent releases
> of OpenResty. Certainly I mean no disrespect to agentzh (or Felipe!) here,
> but simply pointing libmodsecurity users to this repo without further
> instruction or discussion is not a useful answer, IMHO.
>


> Finally, and I'm sure I'm missing something here, but I fail to see the
> substantial technical challenges in porting PERF_* to libmodsecurity. Yes,
> stap can be a useful tool, and I think the community would love to see more
> official stap scripts for libmodsecurity (I would love to have the time to
> work on these myself!). But I just don't understand why implementing PERF_*
> in v3 is a blocking problem. The v2 implementation is quite very simply, at
> least for the combined and per-phase members (
> https://github.com/SpiderLabs/ModSecurity/blob/v2/master/apache2/re_variables.c#L1668-L1680).
> @Felipe, would you consider a community-contributed implemention of PERF_*
> for libmodsecurity?
>

Community contribution is always welcome in many aspects. If you are
willing to add a feature that doesn't negatively impact  ModSecurity and
it's something that the fullfills the needs of the community (and not just
one single user needs) you're more then welcome to submit a pull request
and we will carefully evaluate it.

As I mentioned the big loss is to report the numbers. Enable logging to
measure performance does not sounds right. I/O is expensive, but there is
no need for a discussion on this. The numbers can talk by itself.

Again, I'm very encouraged by this discussion. It's good to see community
> involvement and responses from Felipe. I look forward to continued
> engagement on this. Cheers.
>

We are discussing stuff on Slack and on GitHub. We are in a very good
momentum, I would like to invite all of you to join.

Br.,
Felipe

On Tue, Mar 27, 2018 at 6:01 AM, Felipe Zimmerle <fe...@zi...>
> wrote:
>
>> Hi,
>>
>> On Tue, Mar 27, 2018 at 8:56 AM Christian Folini <
>> chr...@ne...> wrote:
>>
>>> Hello Felipe,
>>>
>>> Thank you for your openness to discuss this on github in detail. Still,
>>> I'd like to continue in this thread because it has already started and
>>> because it interests a wider audience due of certain implications that
>>> have to do with the way you handle our concerns.
>>>
>>>
>> The issue is open for discussion on GitHub since "Dec 9, 2015" no one
>> seems to care about till yesterday. On GitHub we have more audience and
>> everything is indexed. Please use the 2015 issue to discuss this.
>>
>> In case you missed something:
>> https://github.com/SpiderLabs/ModSecurity/issues/1011
>>
>>
>> On Mon, Mar 26, 2018 at 05:08:50PM +0000, Felipe Zimmerle wrote:
>>> > I have no bug report saying that DURATION is not working and a
>>> regression
>>> > test that leads me to believe that it is working. Thus, I am assuming
>>> that
>>> > it is working Ok.
>>>
>>> Here is your new bug report:
>>>
>>> https://github.com/SpiderLabs/ModSecurity/issues/1725
>>>
>>>
>> That is a good way to work in a open source project. Report a bug that
>> was found. Thank you in the name of the community.
>>
>> (...)
>>>
>>
>>
>>> I have just been commissioned to come up with a decent approach to do
>>> performance analysis of existing services on libModSecurity / NGINX.
>>> This is
>>> great for me, because it means business. But it is bad for ModSecurity
>>> because
>>> people should be able to do this without Christian Folini coming up with
>>> a
>>> smart method. It should be easier than this (and it should be
>>> documented!):
>>>
>>>
>> There is a difference in between run ModSecurity and code ModSecurity. In
>> the same way that there is a difference in create a script and run a
>> script. We have published the script here:
>> https://github.com/SpiderLabs/ModSecurity-nginx/commits/master/ngx-modsec.stp
>> since 20 Sep 2015. We dind't charge nobody for it. The decision to ask
>> for money is ours.
>>
>> Maybe the script is not in the shape that you like but it is working and
>> 100% compatible with our current user base. May advice to you in to study
>> the current proposed method before complain about it. There are huge
>> advantages in this new approach. It is in fact a good thing for our users.
>> Having said that, can you provide a solid argument pointing towards stap
>> not be good?
>>
>>
>>> The standard questions in such situations is:
>>> - Which requests have a performance issue?
>>> - Is the performance issue with ModSecurity or with the backend
>>> application?
>>>
>>>
>> Here you can find answers to all your questions:
>>  https://github.com/openresty/openresty-systemtap-toolkit
>>
>>
>> With ModSecurity 2.9.2 this is easy to find out. See my tutorials
>>> https://www.netnea.com/cms/apache-tutorial-5_extending-access-log/
>>> https://www.netnea.com/cms/apache-tutorial-6_embedding-modsecurity/
>>> that describe an access log format that brings this performance data for
>>> every request and the ModSec rules necessary to fill the variables.
>>> This settles 90% of all performance issues immediately.
>>>
>>>
>> I understand that the new version outdated your tutorials, etc... I am
>> sorry for that.
>>
>>
>>> Now NGINX does not allow to display env variables easily in the access
>>> log
>>> and libModSecurity does not yet support env variables anyways. So I
>>> assumed
>>> I would have to take a different path. Now it looks like I would need to
>>> write everything into the error log and _then_ calculate the timings
>>> externally with a new tool / script that works with floating point
>>> numbers.
>>>
>>> And additionally I will look into systemtap because you told us to do so
>>> and because the example you give may be useful for experienced stap
>>> users,
>>> but it's beyond the knowledge level of the average ModSecurity user.
>>>
>>>
>> It is just about execute a script. Nothing more. Still:
>>
>> a) The discussion from 2015 still open. I am not telling what to do.
>> Happy users are using stap.
>> b) The version 2.x is still maintained; If you don't want to learn
>> something new, you can keep using v2.
>>
>>
>>> I am sorry if this message is a bit rude. I usually try to remain calm
>>> and
>>> diplomatic. But this time, it did not work out and sleeping it over did
>>> not work either.
>>>
>>>
>> Feel free to share your feelings.
>>
>>
>>> We are all together on this ModSecurity ship. You are the captain and you
>>> steer the ship based on the decisions you think are best. The rest of the
>>> community only notices the decision once the ship starts to turn. You
>>> stated libModSecurity would be feature compatible to 2.9.x. Now we learn
>>> it
>>> is not and we have to make fundamental changes to our setups and
>>> methodology.
>>>
>>>
>> Like a said too many times: We started a discussion back in 2015. If you
>> are part of this community, why I we didn't have a comment from you?
>>
>>
>>> I am totally open for a discussion on the need for the PERF_ variables.
>>> If they mean a performance hit, then tell us how much and tell us why you
>>> think it is not acceptable. How is the libModSecurity 3.0 performance
>>> stacking up against 2.9.x? Is it really so good, that you want to squeeze
>>> out the last few cpu cycles to the very limit and PERF_ is the last
>>> remaining target?
>>> Having to calculate performance via arithemtics
>>> and DURATION also has a performance hit, and maybe one could make the
>>> PERF_ variables optional (compile time flag or directive that is off by
>>> default). But please do not take these decisions silently and then brush
>>> away our concerns.
>>>
>>>
>> Since 2015:
>>  https://github.com/SpiderLabs/ModSecurity/issues/1011
>>
>> Br.,
>> Felipe.
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> mod-security-users mailing list
>> mod...@li...
>> https://lists.sourceforge.net/lists/listinfo/mod-security-users
>> Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs:
>> http://www.modsecurity.org/projects/commercial/rules/
>> http://www.modsecurity.org/projects/commercial/support/
>>
>>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> mod-security-users mailing list
> mod...@li...
> https://lists.sourceforge.net/lists/listinfo/mod-security-users
> Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs:
> http://www.modsecurity.org/projects/commercial/rules/
> http://www.modsecurity.org/projects/commercial/support/
>

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

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

Hello Felipe,

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

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

Ahoj,

Christian



On Tue, Mar 27, 2018 at 01:01:56PM +0000, Felipe Zimmerle wrote:
> Hi,
> 
> On Tue, Mar 27, 2018 at 8:56 AM Christian Folini <
> chr...@ne...> wrote:
> 
> > Hello Felipe,
> >
> > Thank you for your openness to discuss this on github in detail. Still,
> > I'd like to continue in this thread because it has already started and
> > because it interests a wider audience due of certain implications that
> > have to do with the way you handle our concerns.
> >
> >
> The issue is open for discussion on GitHub since "Dec 9, 2015" no one seems
> to care about till yesterday. On GitHub we have more audience and
> everything is indexed. Please use the 2015 issue to discuss this.
> 
> In case you missed something:
> https://github.com/SpiderLabs/ModSecurity/issues/1011
> 
> 
> On Mon, Mar 26, 2018 at 05:08:50PM +0000, Felipe Zimmerle wrote:
> > > I have no bug report saying that DURATION is not working and a regression
> > > test that leads me to believe that it is working. Thus, I am assuming
> > that
> > > it is working Ok.
> >
> > Here is your new bug report:
> >
> > https://github.com/SpiderLabs/ModSecurity/issues/1725
> >
> >
> That is a good way to work in a open source project. Report a bug that was
> found. Thank you in the name of the community.
> 
> (...)
> >
> 
> 
> > I have just been commissioned to come up with a decent approach to do
> > performance analysis of existing services on libModSecurity / NGINX. This
> > is
> > great for me, because it means business. But it is bad for ModSecurity
> > because
> > people should be able to do this without Christian Folini coming up with a
> > smart method. It should be easier than this (and it should be documented!):
> >
> >
> There is a difference in between run ModSecurity and code ModSecurity. In
> the same way that there is a difference in create a script and run a
> script. We have published the script here:
> https://github.com/SpiderLabs/ModSecurity-nginx/commits/master/ngx-modsec.stp
> since 20 Sep 2015. We dind't charge nobody for it. The decision to ask for
> money is ours.
> 
> Maybe the script is not in the shape that you like but it is working and
> 100% compatible with our current user base. May advice to you in to study
> the current proposed method before complain about it. There are huge
> advantages in this new approach. It is in fact a good thing for our users.
> Having said that, can you provide a solid argument pointing towards stap
> not be good?
> 
> 
> > The standard questions in such situations is:
> > - Which requests have a performance issue?
> > - Is the performance issue with ModSecurity or with the backend
> > application?
> >
> >
> Here you can find answers to all your questions:
>  https://github.com/openresty/openresty-systemtap-toolkit
> 
> 
> With ModSecurity 2.9.2 this is easy to find out. See my tutorials
> > https://www.netnea.com/cms/apache-tutorial-5_extending-access-log/
> > https://www.netnea.com/cms/apache-tutorial-6_embedding-modsecurity/
> > that describe an access log format that brings this performance data for
> > every request and the ModSec rules necessary to fill the variables.
> > This settles 90% of all performance issues immediately.
> >
> >
> I understand that the new version outdated your tutorials, etc... I am
> sorry for that.
> 
> 
> > Now NGINX does not allow to display env variables easily in the access log
> > and libModSecurity does not yet support env variables anyways. So I assumed
> > I would have to take a different path. Now it looks like I would need to
> > write everything into the error log and _then_ calculate the timings
> > externally with a new tool / script that works with floating point numbers.
> >
> > And additionally I will look into systemtap because you told us to do so
> > and because the example you give may be useful for experienced stap users,
> > but it's beyond the knowledge level of the average ModSecurity user.
> >
> >
> It is just about execute a script. Nothing more. Still:
> 
> a) The discussion from 2015 still open. I am not telling what to do. Happy
> users are using stap.
> b) The version 2.x is still maintained; If you don't want to learn
> something new, you can keep using v2.
> 
> 
> > I am sorry if this message is a bit rude. I usually try to remain calm and
> > diplomatic. But this time, it did not work out and sleeping it over did
> > not work either.
> >
> >
> Feel free to share your feelings.
> 
> 
> > We are all together on this ModSecurity ship. You are the captain and you
> > steer the ship based on the decisions you think are best. The rest of the
> > community only notices the decision once the ship starts to turn. You
> > stated libModSecurity would be feature compatible to 2.9.x. Now we learn it
> > is not and we have to make fundamental changes to our setups and
> > methodology.
> >
> >
> Like a said too many times: We started a discussion back in 2015. If you
> are part of this community, why I we didn't have a comment from you?
> 
> 
> > I am totally open for a discussion on the need for the PERF_ variables.
> > If they mean a performance hit, then tell us how much and tell us why you
> > think it is not acceptable. How is the libModSecurity 3.0 performance
> > stacking up against 2.9.x? Is it really so good, that you want to squeeze
> > out the last few cpu cycles to the very limit and PERF_ is the last
> > remaining target?
> > Having to calculate performance via arithemtics
> > and DURATION also has a performance hit, and maybe one could make the
> > PERF_ variables optional (compile time flag or directive that is off by
> > default). But please do not take these decisions silently and then brush
> > away our concerns.
> >
> >
> Since 2015:
>  https://github.com/SpiderLabs/ModSecurity/issues/1011
> 
> Br.,
> Felipe.

> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot

> _______________________________________________
> mod-security-users mailing list
> mod...@li...
> https://lists.sourceforge.net/lists/listinfo/mod-security-users
> Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs:
> http://www.modsecurity.org/projects/commercial/rules/
> http://www.modsecurity.org/projects/commercial/support/


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

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

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

It's encouraging to see this discussion taking place. A few observations,
as a member of the community who has not had time for significant
engagement in either the CRS or libmodsecurity projects in the last year or
so:

First, https://github.com/SpiderLabs/ModSecurity/issues/1011 looks like a
placeholder card to mark that a feature has not been implemented. Up until
its closure in October 2017, there was no discussion or notation to
indicate that this feature *would not* be implemented. Indeed, most other
cards with this issue tag do not have any discussion, only a note that
indicating their completion, so there's nothing in this issue, apart from
an abrupt note and closure, that the community can reference that would
indicate that the feature will not make it into libmodsecurity. I don't
call seeing any solicitation from developers to the community about the
usefulness of PERF_*, and I don't think its reasonable to say that there
has been no community care about these variables until now, because the
card in question wasn't a call for discussion- it was a placeholder. So,
with all respect, it seems a little disingenuous to claim "no one cared
about this we're not going to support it"- from an outside observation,
there has *always* been an expectation that this feature would be available
someday.

Second, stap and friends simply are not an equivalent replacement for
PERF_*. For one, deploying and using systemtap isn't an option for
technical reasons. It is a complex, nuanced tool that takes substantial
effort to use, and trying to troubleshoot stap errors or malfunctions for
less-advanced users is, put lightly, a daunting task. Yes, having a working
set of systemtap scripts designed to introspect libmodsecurity is useful.
It's a wonderful opportunity. But comparing systemtap output and natively
integrated SecRules DSL is apples and oranges. PERF_* provides the ability
to extend and alter ruleset functionality; systemtap introspection is a
passive output. These are fundamentally different approaches.

Regarding the openresty-systemtap-toolkit, this is a wonderful repository
of examples and targeted scripts. It is a useful reference point, but it's
just that- a reference point. It is not actively maintained at this time,
and several of the scripts do not work with even modestly recent releases
of OpenResty. Certainly I mean no disrespect to agentzh (or Felipe!) here,
but simply pointing libmodsecurity users to this repo without further
instruction or discussion is not a useful answer, IMHO.

Finally, and I'm sure I'm missing something here, but I fail to see the
substantial technical challenges in porting PERF_* to libmodsecurity. Yes,
stap can be a useful tool, and I think the community would love to see more
official stap scripts for libmodsecurity (I would love to have the time to
work on these myself!). But I just don't understand why implementing PERF_*
in v3 is a blocking problem. The v2 implementation is quite very simply, at
least for the combined and per-phase members (
https://github.com/SpiderLabs/ModSecurity/blob/v2/master/apache2/re_variables.c#L1668-L1680).
@Felipe, would you consider a community-contributed implemention of PERF_*
for libmodsecurity?

Again, I'm very encouraged by this discussion. It's good to see community
involvement and responses from Felipe. I look forward to continued
engagement on this. Cheers.

On Tue, Mar 27, 2018 at 6:01 AM, Felipe Zimmerle <fe...@zi...>
wrote:

> Hi,
>
> On Tue, Mar 27, 2018 at 8:56 AM Christian Folini <
> chr...@ne...> wrote:
>
>> Hello Felipe,
>>
>> Thank you for your openness to discuss this on github in detail. Still,
>> I'd like to continue in this thread because it has already started and
>> because it interests a wider audience due of certain implications that
>> have to do with the way you handle our concerns.
>>
>>
> The issue is open for discussion on GitHub since "Dec 9, 2015" no one
> seems to care about till yesterday. On GitHub we have more audience and
> everything is indexed. Please use the 2015 issue to discuss this.
>
> In case you missed something:
> https://github.com/SpiderLabs/ModSecurity/issues/1011
>
>
> On Mon, Mar 26, 2018 at 05:08:50PM +0000, Felipe Zimmerle wrote:
>> > I have no bug report saying that DURATION is not working and a
>> regression
>> > test that leads me to believe that it is working. Thus, I am assuming
>> that
>> > it is working Ok.
>>
>> Here is your new bug report:
>>
>> https://github.com/SpiderLabs/ModSecurity/issues/1725
>>
>>
> That is a good way to work in a open source project. Report a bug that was
> found. Thank you in the name of the community.
>
> (...)
>>
>
>
>> I have just been commissioned to come up with a decent approach to do
>> performance analysis of existing services on libModSecurity / NGINX. This
>> is
>> great for me, because it means business. But it is bad for ModSecurity
>> because
>> people should be able to do this without Christian Folini coming up with a
>> smart method. It should be easier than this (and it should be
>> documented!):
>>
>>
> There is a difference in between run ModSecurity and code ModSecurity. In
> the same way that there is a difference in create a script and run a
> script. We have published the script here: https://github.com/
> SpiderLabs/ModSecurity-nginx/commits/master/ngx-modsec.stp
> since 20 Sep 2015. We dind't charge nobody for it. The decision to ask for
> money is ours.
>
> Maybe the script is not in the shape that you like but it is working and
> 100% compatible with our current user base. May advice to you in to study
> the current proposed method before complain about it. There are huge
> advantages in this new approach. It is in fact a good thing for our users.
> Having said that, can you provide a solid argument pointing towards stap
> not be good?
>
>
>> The standard questions in such situations is:
>> - Which requests have a performance issue?
>> - Is the performance issue with ModSecurity or with the backend
>> application?
>>
>>
> Here you can find answers to all your questions:
>  https://github.com/openresty/openresty-systemtap-toolkit
>
>
> With ModSecurity 2.9.2 this is easy to find out. See my tutorials
>> https://www.netnea.com/cms/apache-tutorial-5_extending-access-log/
>> https://www.netnea.com/cms/apache-tutorial-6_embedding-modsecurity/
>> that describe an access log format that brings this performance data for
>> every request and the ModSec rules necessary to fill the variables.
>> This settles 90% of all performance issues immediately.
>>
>>
> I understand that the new version outdated your tutorials, etc... I am
> sorry for that.
>
>
>> Now NGINX does not allow to display env variables easily in the access log
>> and libModSecurity does not yet support env variables anyways. So I
>> assumed
>> I would have to take a different path. Now it looks like I would need to
>> write everything into the error log and _then_ calculate the timings
>> externally with a new tool / script that works with floating point
>> numbers.
>>
>> And additionally I will look into systemtap because you told us to do so
>> and because the example you give may be useful for experienced stap users,
>> but it's beyond the knowledge level of the average ModSecurity user.
>>
>>
> It is just about execute a script. Nothing more. Still:
>
> a) The discussion from 2015 still open. I am not telling what to do. Happy
> users are using stap.
> b) The version 2.x is still maintained; If you don't want to learn
> something new, you can keep using v2.
>
>
>> I am sorry if this message is a bit rude. I usually try to remain calm and
>> diplomatic. But this time, it did not work out and sleeping it over did
>> not work either.
>>
>>
> Feel free to share your feelings.
>
>
>> We are all together on this ModSecurity ship. You are the captain and you
>> steer the ship based on the decisions you think are best. The rest of the
>> community only notices the decision once the ship starts to turn. You
>> stated libModSecurity would be feature compatible to 2.9.x. Now we learn
>> it
>> is not and we have to make fundamental changes to our setups and
>> methodology.
>>
>>
> Like a said too many times: We started a discussion back in 2015. If you
> are part of this community, why I we didn't have a comment from you?
>
>
>> I am totally open for a discussion on the need for the PERF_ variables.
>> If they mean a performance hit, then tell us how much and tell us why you
>> think it is not acceptable. How is the libModSecurity 3.0 performance
>> stacking up against 2.9.x? Is it really so good, that you want to squeeze
>> out the last few cpu cycles to the very limit and PERF_ is the last
>> remaining target?
>> Having to calculate performance via arithemtics
>> and DURATION also has a performance hit, and maybe one could make the
>> PERF_ variables optional (compile time flag or directive that is off by
>> default). But please do not take these decisions silently and then brush
>> away our concerns.
>>
>>
> Since 2015:
>  https://github.com/SpiderLabs/ModSecurity/issues/1011
>
> Br.,
> Felipe.
>
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> mod-security-users mailing list
> mod...@li...
> https://lists.sourceforge.net/lists/listinfo/mod-security-users
> Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs:
> http://www.modsecurity.org/projects/commercial/rules/
> http://www.modsecurity.org/projects/commercial/support/
>
>

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

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

Hi,

On Tue, Mar 27, 2018 at 8:56 AM Christian Folini <
chr...@ne...> wrote:

> Hello Felipe,
>
> Thank you for your openness to discuss this on github in detail. Still,
> I'd like to continue in this thread because it has already started and
> because it interests a wider audience due of certain implications that
> have to do with the way you handle our concerns.
>
>
The issue is open for discussion on GitHub since "Dec 9, 2015" no one seems
to care about till yesterday. On GitHub we have more audience and
everything is indexed. Please use the 2015 issue to discuss this.

In case you missed something:
https://github.com/SpiderLabs/ModSecurity/issues/1011


On Mon, Mar 26, 2018 at 05:08:50PM +0000, Felipe Zimmerle wrote:
> > I have no bug report saying that DURATION is not working and a regression
> > test that leads me to believe that it is working. Thus, I am assuming
> that
> > it is working Ok.
>
> Here is your new bug report:
>
> https://github.com/SpiderLabs/ModSecurity/issues/1725
>
>
That is a good way to work in a open source project. Report a bug that was
found. Thank you in the name of the community.

(...)
>


> I have just been commissioned to come up with a decent approach to do
> performance analysis of existing services on libModSecurity / NGINX. This
> is
> great for me, because it means business. But it is bad for ModSecurity
> because
> people should be able to do this without Christian Folini coming up with a
> smart method. It should be easier than this (and it should be documented!):
>
>
There is a difference in between run ModSecurity and code ModSecurity. In
the same way that there is a difference in create a script and run a
script. We have published the script here:
https://github.com/SpiderLabs/ModSecurity-nginx/commits/master/ngx-modsec.stp
since 20 Sep 2015. We dind't charge nobody for it. The decision to ask for
money is ours.

Maybe the script is not in the shape that you like but it is working and
100% compatible with our current user base. May advice to you in to study
the current proposed method before complain about it. There are huge
advantages in this new approach. It is in fact a good thing for our users.
Having said that, can you provide a solid argument pointing towards stap
not be good?


> The standard questions in such situations is:
> - Which requests have a performance issue?
> - Is the performance issue with ModSecurity or with the backend
> application?
>
>
Here you can find answers to all your questions:
 https://github.com/openresty/openresty-systemtap-toolkit


With ModSecurity 2.9.2 this is easy to find out. See my tutorials
> https://www.netnea.com/cms/apache-tutorial-5_extending-access-log/
> https://www.netnea.com/cms/apache-tutorial-6_embedding-modsecurity/
> that describe an access log format that brings this performance data for
> every request and the ModSec rules necessary to fill the variables.
> This settles 90% of all performance issues immediately.
>
>
I understand that the new version outdated your tutorials, etc... I am
sorry for that.


> Now NGINX does not allow to display env variables easily in the access log
> and libModSecurity does not yet support env variables anyways. So I assumed
> I would have to take a different path. Now it looks like I would need to
> write everything into the error log and _then_ calculate the timings
> externally with a new tool / script that works with floating point numbers.
>
> And additionally I will look into systemtap because you told us to do so
> and because the example you give may be useful for experienced stap users,
> but it's beyond the knowledge level of the average ModSecurity user.
>
>
It is just about execute a script. Nothing more. Still:

a) The discussion from 2015 still open. I am not telling what to do. Happy
users are using stap.
b) The version 2.x is still maintained; If you don't want to learn
something new, you can keep using v2.


> I am sorry if this message is a bit rude. I usually try to remain calm and
> diplomatic. But this time, it did not work out and sleeping it over did
> not work either.
>
>
Feel free to share your feelings.


> We are all together on this ModSecurity ship. You are the captain and you
> steer the ship based on the decisions you think are best. The rest of the
> community only notices the decision once the ship starts to turn. You
> stated libModSecurity would be feature compatible to 2.9.x. Now we learn it
> is not and we have to make fundamental changes to our setups and
> methodology.
>
>
Like a said too many times: We started a discussion back in 2015. If you
are part of this community, why I we didn't have a comment from you?


> I am totally open for a discussion on the need for the PERF_ variables.
> If they mean a performance hit, then tell us how much and tell us why you
> think it is not acceptable. How is the libModSecurity 3.0 performance
> stacking up against 2.9.x? Is it really so good, that you want to squeeze
> out the last few cpu cycles to the very limit and PERF_ is the last
> remaining target?
> Having to calculate performance via arithemtics
> and DURATION also has a performance hit, and maybe one could make the
> PERF_ variables optional (compile time flag or directive that is off by
> default). But please do not take these decisions silently and then brush
> away our concerns.
>
>
Since 2015:
 https://github.com/SpiderLabs/ModSecurity/issues/1011

Br.,
Felipe.

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

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

Hello Felipe,

Thank you for your openness to discuss this on github in detail. Still,
I'd like to continue in this thread because it has already started and
because it interests a wider audience due of certain implications that
have to do with the way you handle our concerns.

On Mon, Mar 26, 2018 at 05:08:50PM +0000, Felipe Zimmerle wrote:
> I have no bug report saying that DURATION is not working and a regression
> test that leads me to believe that it is working. Thus, I am assuming that
> it is working Ok.

Here is your new bug report:

https://github.com/SpiderLabs/ModSecurity/issues/1725

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

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

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

I have just been commissioned to come up with a decent approach to do
performance analysis of existing services on libModSecurity / NGINX. This is
great for me, because it means business. But it is bad for ModSecurity because
people should be able to do this without Christian Folini coming up with a
smart method. It should be easier than this (and it should be documented!):

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

With ModSecurity 2.9.2 this is easy to find out. See my tutorials
https://www.netnea.com/cms/apache-tutorial-5_extending-access-log/
https://www.netnea.com/cms/apache-tutorial-6_embedding-modsecurity/
that describe an access log format that brings this performance data for
every request and the ModSec rules necessary to fill the variables.
This settles 90% of all performance issues immediately.

Now NGINX does not allow to display env variables easily in the access log
and libModSecurity does not yet support env variables anyways. So I assumed
I would have to take a different path. Now it looks like I would need to
write everything into the error log and _then_ calculate the timings
externally with a new tool / script that works with floating point numbers.

And additionally I will look into systemtap because you told us to do so
and because the example you give may be useful for experienced stap users,
but it's beyond the knowledge level of the average ModSecurity user.

I am sorry if this message is a bit rude. I usually try to remain calm and
diplomatic. But this time, it did not work out and sleeping it over did
not work either.

We are all together on this ModSecurity ship. You are the captain and you
steer the ship based on the decisions you think are best. The rest of the
community only notices the decision once the ship starts to turn. You
stated libModSecurity would be feature compatible to 2.9.x. Now we learn it
is not and we have to make fundamental changes to our setups and methodology.

I am totally open for a discussion on the need for the PERF_ variables.
If they mean a performance hit, then tell us how much and tell us why you
think it is not acceptable. How is the libModSecurity 3.0 performance
stacking up against 2.9.x? Is it really so good, that you want to squeeze
out the last few cpu cycles to the very limit and PERF_ is the last
remaining target?
Having to calculate performance via arithemtics
and DURATION also has a performance hit, and maybe one could make the
PERF_ variables optional (compile time flag or directive that is off by
default). But please do not take these decisions silently and then brush
away our concerns.

Best regards,

Christian


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

Re: [mod-security-users] OWASP ModSecurity Core Rule Set vs. OWASP ModSecurity Core Rule Set V 3.0

[Osama E. <oel...@gm...>]

As Christian mentioned, you are probably better off with mod_qos.  Also,
the user-based blocking you linked to looks like it will block valid users
from logging in as well if someone is brute-forcing their accounts.
Finally, you can look into other options such as:

- adding an invisible CAPTCHA to the login page (this is very
straight-forward but would require minor modifications to the application)
- using a CDN that requires proof of work before forwarding requests to
your site

-- 
Osama Elnaggar

On March 27, 2018 at 3:12:47 PM, Christian Folini (
chr...@ne...) wrote:

Hi there,

On Mon, Mar 26, 2018 at 11:18:20PM -0400, Chip wrote:
> Any idea if the suggestions on this page are up-to-date?  No timestamp
> on the technical details just an interesting how-to.

It looks like the author knows ModSecurity given the advanced rule set
he / she proposes. But it's hard to tell if this works without testing
it by heart.

Alternatively, the ModSecurity Handbook has similar rules with the same
goal and I guarantee that those really work.

But ModSecurity is not the best tool to prevent BruteForce and Automation
anyways. At least not when it gets closer to a DoS. Mod_qos and friends are
usually better suited.

Depends on the rules. The example you linked should apparently be put
in Location context. But you can also work in server context which brings
advantages as it can be ran in phase 1. But honestly, this is really
advanced
stuff and pros and cons are all very complicated and take a lot of
experience.

Ahoj,

Christian


-- 
Investors should be aware of the overall dangers the legal profession
present to companies, and how its current and generalized naiveté can
sink fortunes overnight.
--- John Dvorak on the digg.com story in May 2007

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