mod-security-users — General discussion about mod_security

Re: [mod-security-users] Retry-After header not being set?

[Andrew H. <and...@lo...>]

Hi Jamie,

That works for me:

> GET /foo HTTP/1.1
> Host: example.com
> User-Agent: curl/7.81.0
> Accept: */*
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 429 Too Many Requests
< Date: Wed, 16 Feb 2022 16:52:32 GMT
< Server: Apache
< Retry-After: 10
< Content-Length: 227
< Content-Type: text/html; charset=iso-8859-1

Is your Apache config loading mod_headers? E.g.:
    LoadModule headers_module lib/httpd/mod_headers.so

It's not a "core" Apache module, so it may not be compiled by default.

For what it's worth, in my opinion, ModSecurity is really, really not
a good place to do any kind of rate limiting. Especially on Apache:
the underlying persistent collection mechanism is ridiculously flakey
and will break your heart (and eat your RAM). The implementation of
'deprecatevar' is particularly "interesting". (Can you tell I've been
burnt by all this before? :)  )

I've had much more success putting HAProxy in front of Apache and
using its stick tables to take care of rate limiting. I've also heard
good things about using the Apache mod_qos module, although I've never
tried it myself. You can also do some clever things using iptables and
tc.

Thanks,
Andrew

-- 

Andrew Howe
Loadbalancer.org Ltd.
www.loadbalancer.org
+1 888 867 9504 / +44 (0)330 380 1064

[mod-security-users] Retry-After header not being set?

[Jamie B. <ja...@ib...>]

Hi



I’m using the following to rate limit request:



<LocationMatch "^/foo">

   SecAction initcol:ip=%{REMOTE_ADDR},pass,nolog,id:100

   SecAction "phase:5,deprecatevar:ip.hitcounter=1/10,pass,nolog,id:102"

   SecRule IP:HITCOUNTER "@gt 60"
"phase:2,pause:300,deny,status:429,setenv:RATELIMITED,skip:1,nolog,id:103"

   SecAction "phase:2,pass,setvar:ip.hitcounter=+1,nolog,id:104"

   Header always set Retry-After "10" env=RATELIMITED

</LocationMatch>



The limiting is working as expected, with a 429 response code when reached
but there is no Retry-After header shown in the response. Can anyone help
me to figure out why?



Thanks

Jamie

Re: [mod-security-users] SecArgumentsLimit Equivalent for XML Processing

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

I remember that discussion now, thanks.

I am not sure if the developers are actively following the mailing list. So
it's probably best to ask this question on github.

Best,

Christian

On Fri, Dec 24, 2021 at 12:53:47PM +0000, Srikanth Arunachalam via mod-security-users wrote:
> Hi Christian,
> 
> Thanks for getting back to me so quickly. Yes, SecArgumentsLimit is a
> Modsec keyword in V3.
> This allows to restrict the rule apply to quantity specified in
> SecArgumentsLimit.
> 
> We had some performance considerations in the past, when, json payload has
> high depth cardinality of list.
> Rule id 942460 (Metacharacter search on non-alphanumberic characters \W)
> spends lot of time.
> 
> There has also been some discussions on this SecArgumentsLimit on
> https://github.com/SpiderLabs/ModSecurity/pull/2234
> 
> This woks fantastic for JSON based payload. To be more precise, including a
> value of SecArgumentsLimit allows to process partial set of payload, rather
> than the whole file.
> 
> We couldnt apply the same for the XML payload is the concern I have raised
> in this forum.
> 
> Kind Regards
> Srikanth Arunachalam
> 
> On Thu, Dec 23, 2021 at 11:01 PM Christian Folini <
> chr...@ne...> wrote:
> 
> > Hey Srikanth,
> >
> > I'm not familia with SecArgumentsLimit. Is it a v3 directive?
> >
> > What do you want it to do exactly with your XML payload?
> >
> > Best,
> >
> > Christian Folini
> >
> > On Thu, Dec 23, 2021 at 04:43:56PM +0000, Srikanth Arunachalam via
> > mod-security-users wrote:
> > > Hi
> > >
> > > We have a not very large XML payload (3mb) with tags including
> > > multiple entries separated with comma.
> > >
> > >     When I remove the comma separation the WAF process takes about 14sec
> > to
> > > complete.
> > > When I include the comma separation lists in XML tag, it complex in 29
> > > seconds.
> > >
> > > Had this been a json payload, I would have used SecArgumentsLimit. It has
> > > not been effective in XML.
> > >
> > > Any sooner suggestion/response would be appreciated.
> > >
> > > Kind Regards
> > > Srikanth Arunachalam
> >
> >
> > > _______________________________________________
> > > 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 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 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] SecArgumentsLimit Equivalent for XML Processing

[Srikanth A. <sri...@go...>]

Hi Christian,

Thanks for getting back to me so quickly. Yes, SecArgumentsLimit is a
Modsec keyword in V3.
This allows to restrict the rule apply to quantity specified in
SecArgumentsLimit.

We had some performance considerations in the past, when, json payload has
high depth cardinality of list.
Rule id 942460 (Metacharacter search on non-alphanumberic characters \W)
spends lot of time.

There has also been some discussions on this SecArgumentsLimit on
https://github.com/SpiderLabs/ModSecurity/pull/2234

This woks fantastic for JSON based payload. To be more precise, including a
value of SecArgumentsLimit allows to process partial set of payload, rather
than the whole file.

We couldnt apply the same for the XML payload is the concern I have raised
in this forum.

Kind Regards
Srikanth Arunachalam

On Thu, Dec 23, 2021 at 11:01 PM Christian Folini <
chr...@ne...> wrote:

> Hey Srikanth,
>
> I'm not familia with SecArgumentsLimit. Is it a v3 directive?
>
> What do you want it to do exactly with your XML payload?
>
> Best,
>
> Christian Folini
>
> On Thu, Dec 23, 2021 at 04:43:56PM +0000, Srikanth Arunachalam via
> mod-security-users wrote:
> > Hi
> >
> > We have a not very large XML payload (3mb) with tags including
> > multiple entries separated with comma.
> >
> >     When I remove the comma separation the WAF process takes about 14sec
> to
> > complete.
> > When I include the comma separation lists in XML tag, it complex in 29
> > seconds.
> >
> > Had this been a json payload, I would have used SecArgumentsLimit. It has
> > not been effective in XML.
> >
> > Any sooner suggestion/response would be appreciated.
> >
> > Kind Regards
> > Srikanth Arunachalam
>
>
> > _______________________________________________
> > 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 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] SecArgumentsLimit Equivalent for XML Processing

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

Hey Srikanth,

I'm not familia with SecArgumentsLimit. Is it a v3 directive?

What do you want it to do exactly with your XML payload?

Best,

Christian Folini

On Thu, Dec 23, 2021 at 04:43:56PM +0000, Srikanth Arunachalam via mod-security-users wrote:
> Hi
> 
> We have a not very large XML payload (3mb) with tags including
> multiple entries separated with comma.
> 
>     When I remove the comma separation the WAF process takes about 14sec to
> complete.
> When I include the comma separation lists in XML tag, it complex in 29
> seconds.
> 
> Had this been a json payload, I would have used SecArgumentsLimit. It has
> not been effective in XML.
> 
> Any sooner suggestion/response would be appreciated.
> 
> Kind Regards
> Srikanth Arunachalam


> _______________________________________________
> 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] SecArgumentsLimit Equivalent for XML Processing

[Srikanth A. <sri...@go...>]

Hi

We have a not very large XML payload (3mb) with tags including
multiple entries separated with comma.

    When I remove the comma separation the WAF process takes about 14sec to
complete.
When I include the comma separation lists in XML tag, it complex in 29
seconds.

Had this been a json payload, I would have used SecArgumentsLimit. It has
not been effective in XML.

Any sooner suggestion/response would be appreciated.

Kind Regards
Srikanth Arunachalam

[mod-security-users] Talking about CRS, Modsecurity and the new Coraza WAF

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

Dear all,

CRS has published a blog post about ModSecurity. In this article we lay down 
our position with regards to Trustwave pulling out of ModSecurity on the mid 
term and we introduce Coraza WAF as a new multipurpose open source WAF engine.

https://coreruleset.org/20211222/talking-about-modsecurity-and-the-new-coraza-waf/

Please help us spread the word on twitter: 
https://twitter.com/CoreRuleSet/status/1473642801736949768

Have questions? Please ask them here!

Happy holidays - and a calm and normal 2022!

Christian


-- 
I would rather have a mind opened by wonder than one closed by belief.
-- Gerry Spence

Re: [mod-security-users] Recommended rule exclusions for WYSIWYG editor editing

[Quinn C. <qu...@st...>]

On 31 Oct 2021 13:39:57, Reindl Harald wrote:
>  <LocationMatch "(.*)\/editor\/plugins\/preview\.php$">

I like this solution too. 

Also, if your editors are connecting from a fixed location or use a VPN, you can turn off SecRequestBodyAccess for a specific IP address either by using:

<If "-R '111.222.333.444'">
    SecRequestBodyAccess Off
</If>

or:

SecRule REMOTE_ADDR "^111.222.333.444" "phase:1,nolog,allow,ctl:responseBodyAccess=Off,id:1001"


Regards,
Quinn

Re: [mod-security-users] Recommended rule exclusions for WYSIWYG editor editing

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

Hey Harald,

On Sun, Oct 31, 2021 at 03:35:35PM +0100, Reindl Harald wrote:
> it's not completly disabled
> SecRequestBodyAccess versus SecRuleEngine!
> 
> phase:1 and all the header stuff is still active
> 
> SecRequestBodyAccess:
> Configures whether request bodies will be buffered and processed by
> ModSecurity by default.


That's decent enough. Watch our for next CRS release where more rules
will happen in phase 1.

Cheers,

Christian



> 
> > ______________________________________________________________
> >  > Od: "Reindl Harald" <h.r...@th...>
> >  > Komu: mod...@li...
> >  > Datum: 31.10.2021 13:41
> >  > Předmět: Re: [mod-security-users] Recommended rule exclusions for
> > WYSIWYG editor editing
> >  >
> > 
> > Am 31.10.21 um 13:34 schrieb Filip Bartmann:
> >  > I'm discovering mod_security with core rule set as very usefull, but
> > I'm going in to trouble with editing HTML via admin part of my CMS
> > including file uploads other parts works well.
> >  >
> >  > Is there any recomendations for minimal rule exlusions for allowing
> > this, but with as many as possible rules enabled. In editing html in
> > forms I get many detections in this as XSS attacks or so on.
> > 
> > you started that topic already afew weeks ago
> > 
> > there is nothing like post HTML and enable as much as possible rules at
> > the same time - you will have a fulltimejob adding more and more rules
> > to exceptions and a minimal WYSIWG change can hit another rule tomorrow
> > 
> > forget it, been there, done that many years ago - it's not worth
> > 
> > <IfModule mod_security2.c>
> >   <LocationMatch "(.*)\/editor\/plugins\/preview\.php$">
> >    SecRequestBodyAccess Off
> >   </LocationMatch>
> > </IfModule>
> 
> 
> _______________________________________________
> 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] Recommended rule exclusions for WYSIWYG editor editing

[Reindl H. <h.r...@th...>]

Am 31.10.21 um 13:57 schrieb Filip Bartmann:
> Hello thanks,
> 
> so I do this, I thought, that core rule set can be enabled even if i 
> want to POST HTML content.

it's not completly disabled
SecRequestBodyAccess versus SecRuleEngine!

phase:1 and all the header stuff is still active

SecRequestBodyAccess:
Configures whether request bodies will be buffered and processed by 
ModSecurity by default.

> ______________________________________________________________
>  > Od: "Reindl Harald" <h.r...@th...>
>  > Komu: mod...@li...
>  > Datum: 31.10.2021 13:41
>  > Předmět: Re: [mod-security-users] Recommended rule exclusions for 
> WYSIWYG editor editing
>  >
> 
> Am 31.10.21 um 13:34 schrieb Filip Bartmann:
>  > I'm discovering mod_security with core rule set as very usefull, but 
> I'm going in to trouble with editing HTML via admin part of my CMS 
> including file uploads other parts works well.
>  >
>  > Is there any recomendations for minimal rule exlusions for allowing 
> this, but with as many as possible rules enabled. In editing html in 
> forms I get many detections in this as XSS attacks or so on.
> 
> you started that topic already afew weeks ago
> 
> there is nothing like post HTML and enable as much as possible rules at
> the same time - you will have a fulltimejob adding more and more rules
> to exceptions and a minimal WYSIWG change can hit another rule tomorrow
> 
> forget it, been there, done that many years ago - it's not worth
> 
> <IfModule mod_security2.c>
>   <LocationMatch "(.*)\/editor\/plugins\/preview\.php$">
>    SecRequestBodyAccess Off
>   </LocationMatch>
> </IfModule>

Re: [mod-security-users] Recommended rule exclusions for WYSIWYG editor editing

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

Hey Filip,

I do not want to disturb Harald's dark outlook with an overly optimistic
perspective, but CRS has come a long way since the old days and free form
textareas generally work. However, if you insist on posting HTML content, then
it's best to enable CRS, but disable all XSS rules by tag on this very field.

Other than that check out the rule exclusion packages, maybe they can help.
(part of CRS).

Cheers,

Christian


On Sun, Oct 31, 2021 at 01:57:16PM +0100, Filip Bartmann wrote:
> Hello thanks,
> so I do this, I thought, that core rule set can be enabled even if i want to POST HTML content.
>  
> With best regards,
> Filip Bartmann
>  
> ______________________________________________________________
> > Od: "Reindl Harald" <h.r...@th...>
> > Komu: mod...@li...
> > Datum: 31.10.2021 13:41
> > Předmět: Re: [mod-security-users] Recommended rule exclusions for WYSIWYG editor editing
> > 
> 
> 
> Am 31.10.21 um 13:34 schrieb Filip Bartmann:
> > I'm discovering mod_security with core rule set as very usefull, but I'm going in to trouble with editing HTML via admin part of my CMS including file uploads other parts works well.
> >   > Is there any recomendations for minimal rule exlusions for allowing
> this, but with as many as possible rules enabled. In editing html in forms I
> get many detections in this as XSS attacks or so on.
> 
> you started that topic already afew weeks ago
> 
> there is nothing like post HTML and enable as much as possible rules at the
> same time - you will have a fulltimejob adding more and more rules to
> exceptions and a minimal WYSIWG change can hit another rule tomorrow
> 
> forget it, been there, done that many years ago - it's not worth
> 
> <IfModule mod_security2.c>
>  <LocationMatch "(.*)\/editor\/plugins\/preview\.php$">
>   SecRequestBodyAccess Off
>  </LocationMatch>
> </IfModule>
> 
> 
> _______________________________________________
> mod-security-users mailing list
> mod...@li...
> https://lists.sourceforge.net/lists/listinfo/mod-security-users <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/rules/>
> http://www.modsecurity.org/projects/commercial/support/ <http://www.modsecurity.org/projects/commercial/support/>
> 


> _______________________________________________
> 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] Recommended rule exclusions for WYSIWYG editor editing

[Filip B. <fi...@ce...>]

Hello thanks,
so I do this, I thought, that core rule set can be enabled even if i want to POST HTML content.
 
With best regards,
Filip Bartmann
 
______________________________________________________________
> Od: "Reindl Harald" <h.r...@th...>
> Komu: mod...@li...
> Datum: 31.10.2021 13:41
> Předmět: Re: [mod-security-users] Recommended rule exclusions for WYSIWYG editor editing
>

 
 Am 31.10.21 um 13:34 schrieb Filip Bartmann:
 > I'm discovering mod_security with core rule set as very usefull, but I'm going in to trouble with editing HTML via admin part of my CMS including file uploads other parts works well.
 >   
 > Is there any recomendations for minimal rule exlusions for allowing this, but with as many as possible rules enabled. In editing html in forms I get many detections in this as XSS attacks or so on.
 
 you started that topic already afew weeks ago
 
 there is nothing like post HTML and enable as much as possible rules at 
 the same time - you will have a fulltimejob adding more and more rules 
 to exceptions and a minimal WYSIWG change can hit another rule tomorrow
 
 forget it, been there, done that many years ago - it's not worth
 
 <IfModule mod_security2.c>
  <LocationMatch "(.*)\/editor\/plugins\/preview\.php$">
   SecRequestBodyAccess Off
  </LocationMatch>
 </IfModule>
 
 
 _______________________________________________
 mod-security-users mailing list
 mod...@li...
 https://lists.sourceforge.net/lists/listinfo/mod-security-users <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/rules/>
 http://www.modsecurity.org/projects/commercial/support/ <http://www.modsecurity.org/projects/commercial/support/>

Re: [mod-security-users] Recommended rule exclusions for WYSIWYG editor editing

[Reindl H. <h.r...@th...>]

Am 31.10.21 um 13:34 schrieb Filip Bartmann:
> I'm discovering mod_security with core rule set as very usefull, but I'm going in to trouble with editing HTML via admin part of my CMS including file uploads other parts works well.
>   
> Is there any recomendations for minimal rule exlusions for allowing this, but with as many as possible rules enabled. In editing html in forms I get many detections in this as XSS attacks or so on.

you started that topic already afew weeks ago

there is nothing like post HTML and enable as much as possible rules at 
the same time - you will have a fulltimejob adding more and more rules 
to exceptions and a minimal WYSIWG change can hit another rule tomorrow

forget it, been there, done that many years ago - it's not worth

<IfModule mod_security2.c>
  <LocationMatch "(.*)\/editor\/plugins\/preview\.php$">
   SecRequestBodyAccess Off
  </LocationMatch>
</IfModule>

[mod-security-users] Recommended rule exclusions for WYSIWYG editor editing

[Filip B. <fi...@ce...>]

Hello,
I'm discovering mod_security with core rule set as very usefull, but I'm going in to trouble with editing HTML via admin part of my CMS including file uploads other parts works well.
 
Is there any recomendations for minimal rule exlusions for allowing this, but with as many as possible rules enabled. In editing html in forms I get many detections in this as XSS attacks or so on.
 
Thanks,
Filip Bartmann

Re: [mod-security-users] Reason for case discrpency in variable names?

[Quinn C. <qu...@st...>]

Thanks Andrew!


On 29 Oct 2021 11:12:35, Andrew Howe wrote:
> Hello Quinn,
> 
> The syntax for *using* variables is subtly different to the syntax for
> *defining* variables, e.g.
>     setvar:tx.my_thing
> versus
>     SecRule TX:my_thing
> 
> At least in the Core Rule Set project, we try to emphasise this
> difference by using upper-case letters for the collection (e.g. TX)
> when *using* a variable and lower-case letters (e.g. tx) when
> *defining* a variable. In addition, lower-case letters are used for
> variables in both cases. (See:
> https://github.com/coreruleset/coreruleset/blob/v3.4/dev/CONTRIBUTING.md#variable-naming-conventions).
> 
> It looks like the example from the ModSecurity Reference Manual you
> mentioned also changes the case of the variable name, for even more
> emphasis.
> 
> Hopefully that answers your question.
> 
> Thanks,
> Andrew
> 
> 
> _______________________________________________
> 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] Reason for case discrpency in variable names?

[Andrew H. <rub...@gm...>]

Hello Quinn,

The syntax for *using* variables is subtly different to the syntax for
*defining* variables, e.g.
    setvar:tx.my_thing
versus
    SecRule TX:my_thing

At least in the Core Rule Set project, we try to emphasise this
difference by using upper-case letters for the collection (e.g. TX)
when *using* a variable and lower-case letters (e.g. tx) when
*defining* a variable. In addition, lower-case letters are used for
variables in both cases. (See:
https://github.com/coreruleset/coreruleset/blob/v3.4/dev/CONTRIBUTING.md#variable-naming-conventions).

It looks like the example from the ModSecurity Reference Manual you
mentioned also changes the case of the variable name, for even more
emphasis.

Hopefully that answers your question.

Thanks,
Andrew

[mod-security-users] Reason for case discrpency in variable names?

[Quinn C. <qu...@st...>]

Hello all,

Under the `drop` section in the v2.x reference manual [1], there is this example:

SecAction phase:1,id:109,initcol:ip=%{REMOTE_ADDR},nolog
SecRule ARGS:login "!^$" "nolog,phase:1,id:110,setvar:ip.auth_attempt=+1,deprecatevar:ip.auth_attempt=25/120"
SecRule IP:AUTH_ATTEMPT "@gt 25" "log,drop,phase:1,id:111,msg:'Possible Brute Force Attack'"

I notice that `ip.auth_attempt` is all lowercase, while `IP:AUTH_ATTEMPT` is all uppercase. Is this the required format? I find it confusing if a variable is lowercase in one location but uppercase in another, so I'm hoping the above example is an error and it would be better to standard the case of variables as they are used in rules?

I couldn't find anywhere in the manual where it is suggested that SecRule variables should be uppercase while SecRule and SecAction actions use lowercase variables. In fact, there is an example under the description of SecAction [2], where an uppercase variable is initialized as `initcol:RESOURCE=…`, and I've seen other examples on the web where lowercase variable names are used as SecRule variables.

Just trying to make sense of this.

Thanks!
Quinn


[1] https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual-(v2.x)#drop
[2] https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual-(v2.x)#secaction

Re: [mod-security-users] Execution error - PCRE limits exceeded (-8): (null)

[Walter H. <mo...@sp...>]

Hi Filip,

This error can happen if ModSecurity’s regular expression engine (PCRE) is doing more work than the allowed limit. ModSecurity then stops running the rule.

It could be that somebody sent a really complex or large request to your machine (if the error happened in a request rule). 

Or perhaps, your page or response returned was really large (if the error happened in a response rule).

The reason for this limit is to prevent a DoS on your server by sending malicious payloads (or eliciting complex responses) that stress the regular expression engine and eat up all your CPU time. So it is smart to keep a limit on the regex work. But often you will need to raise the PCRE limits to a level that the errors are gone or almost gone.

You can define ModSecurity’s PCRE limits in your mod_security2.conf with the commands SecPcreMatchLimit and SecPcreMatchLimitRecursion.

For instance, you could set them as follows:

SecPcreMatchLimit 100000
SecPcreMatchLimitRecursion 100000

I personally have not needed to set them any higher than 100000.
But I know that some use higher values, such as 200000 or 250000.

These numbers are passed by ModSecurity to the PCRE library. For in-depth information about how it uses these numbers, please see http://pcre.org/original/doc/html/pcreapi.html <http://pcre.org/original/doc/html/pcreapi.html> and look for ‘limits’.

Another angle is to look at the log file to see which rule exceeded the limit. It is possible that you might not need that rule. For instance, I often received your same error on Core Rule Set’s 951190 rule. That rule prevents Ingres SQL information leakages. I don’t use Ingres ever. So, instead of raising the PCRE limits even more, I just disable that rule. You can disable a rule by adding the following to your .conf file:

SecRuleRemoveById 123456

Where 123456 is the rule ID that you want to disable. Note that disabling rules might open up attack vectors, so always do this carefully.

Hope this helps!

Kind regards,
Walter Hop
Core Rule Set co-lead


> On 27 Oct 2021, at 12:37, Filip Bartmann <fi...@ce...> wrote:
> 
> Hello,
> I starting to use mod_security for Apache2 with crs and in log i many times see:
>  
> Execution error - PCRE limits exceeded (-8): (null)
>  
> How can I prevent this?
>  
> Thanks,
> Filip Bartmann
> 
> 
> _______________________________________________
> 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] Execution error - PCRE limits exceeded (-8): (null)

[Filip B. <fi...@ce...>]

Hello,
I starting to use mod_security for Apache2 with crs and in log i many times see:
 
Execution error - PCRE limits exceeded (-8): (null)
 
How can I prevent this?
 
Thanks,
Filip Bartmann

Re: [mod-security-users] How to log transformed REQUEST_URI/​REQUEST_URI_RAW?

[Web C. <we...@we...>]

Dear Azurit

To see what happens while testing I will try that, thank you :)

Does someone know how to print the result uf a transformation function
like: "t:normalizePathWin" in the Message ("msg")?

Is the transformation applied to REQUEST_URI or REQUEST_URI_RAW in the Rule
below?

Greetings,
Webco

<az...@po...> schrieb am Sa., 23. Okt. 2021, 16:57:

> Hi
>
> try enabling debug log in ModSecurity.
>
>
> Citát Web Coach <we...@we...>:
>
> > Hello together :)
> >
> > How can I find the reason why the rule below was triggered? It looks like
> > the audit log does not provide enough information in this case either.
> >
> > %{REQUEST_URI}         gives me: /yyyyy.php?site=http://blubb
> > %{REQUEST_URI_RAW} gives me: /yyyyy.php?site=http://blubb
> >
> > I think the transformed REQUEST_URI might be something like
> > "/yyyyy.php?site=http:/blubb" without the double slash. I want to be sure
> > why the rule was triggered and I want to see it black on white for
> > certainty. How would you do it?
> >
> > ModSecurity version: 2.9.4
> > Apache Version: 2.4.48
> >
> > Rule / in httpd.conf
> > ------------------
> > # Make sure there are no URI evasion attempts
> > SecRule REQUEST_URI "!@streq %{REQUEST_URI_RAW}" \
> >     "id:11000,phase:1,deny,t:normalizePathWin,log,\
> >     msg:'URI evasion attempt REQUEST_URI: %{REQUEST_URI} REQUEST_URI_RAW:
> > %{REQUEST_URI_RAW}'"
> >
> > error.log
> > ------------------
> > [yyyy-mm-dd hh:mm:ss.mmmmmm] [-:error] 127.0.0.1:35220
> > zzzzzzz__zzzzzzzzzzzzzzzzzz [client 127.0.0.1] ModSecurity: Access denied
> > with code 403 (phase 1). Match of "streq %{REQUEST_URI_RAW}" against
> > "REQUEST_URI" required. [file "/opt/apache-2.4.48/conf/httpd.conf"] [line
> > "200"] [id "11000"] [msg "URI evasion attempt REQUEST_URI:
> /yyyyy.php?site=
> > http://blubb REQUEST_URI_RAW: /yyyyy.php?site=http://blubb"] [tag
> > "domain.tld Public"] [hostname "domain.tld"] [uri "/yyyyy.php"]
> [unique_id
> > "zzzzzzz__zzzzzzzzzzzzzzzzzz"]
> >
> > Regards,
> > Webco
>
>
>
>
>
> _______________________________________________
> 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] How to log transformed REQUEST_URI/​REQUEST_URI_RAW?

[<az...@po...>]

Hi

try enabling debug log in ModSecurity.






Citát Web Coach <we...@we...>:

> Hello together :)
>
> How can I find the reason why the rule below was triggered? It looks like
> the audit log does not provide enough information in this case either.
>
> %{REQUEST_URI}         gives me: /yyyyy.php?site=http://blubb
> %{REQUEST_URI_RAW} gives me: /yyyyy.php?site=http://blubb
>
> I think the transformed REQUEST_URI might be something like
> "/yyyyy.php?site=http:/blubb" without the double slash. I want to be sure
> why the rule was triggered and I want to see it black on white for
> certainty. How would you do it?
>
> ModSecurity version: 2.9.4
> Apache Version: 2.4.48
>
> Rule / in httpd.conf
> ------------------
> # Make sure there are no URI evasion attempts
> SecRule REQUEST_URI "!@streq %{REQUEST_URI_RAW}" \
>     "id:11000,phase:1,deny,t:normalizePathWin,log,\
>     msg:'URI evasion attempt REQUEST_URI: %{REQUEST_URI} REQUEST_URI_RAW:
> %{REQUEST_URI_RAW}'"
>
> error.log
> ------------------
> [yyyy-mm-dd hh:mm:ss.mmmmmm] [-:error] 127.0.0.1:35220
> zzzzzzz__zzzzzzzzzzzzzzzzzz [client 127.0.0.1] ModSecurity: Access denied
> with code 403 (phase 1). Match of "streq %{REQUEST_URI_RAW}" against
> "REQUEST_URI" required. [file "/opt/apache-2.4.48/conf/httpd.conf"] [line
> "200"] [id "11000"] [msg "URI evasion attempt REQUEST_URI: /yyyyy.php?site=
> http://blubb REQUEST_URI_RAW: /yyyyy.php?site=http://blubb"] [tag
> "domain.tld Public"] [hostname "domain.tld"] [uri "/yyyyy.php"] [unique_id
> "zzzzzzz__zzzzzzzzzzzzzzzzzz"]
>
> Regards,
> Webco

[mod-security-users] How to log transformed REQUEST_URI/​REQUEST_URI_RAW?

[Web C. <we...@we...>]

Hello together :)

How can I find the reason why the rule below was triggered? It looks like
the audit log does not provide enough information in this case either.

%{REQUEST_URI}         gives me: /yyyyy.php?site=http://blubb
%{REQUEST_URI_RAW} gives me: /yyyyy.php?site=http://blubb

I think the transformed REQUEST_URI might be something like
"/yyyyy.php?site=http:/blubb" without the double slash. I want to be sure
why the rule was triggered and I want to see it black on white for
certainty. How would you do it?

ModSecurity version: 2.9.4
Apache Version: 2.4.48

Rule / in httpd.conf
------------------
# Make sure there are no URI evasion attempts
SecRule REQUEST_URI "!@streq %{REQUEST_URI_RAW}" \
    "id:11000,phase:1,deny,t:normalizePathWin,log,\
    msg:'URI evasion attempt REQUEST_URI: %{REQUEST_URI} REQUEST_URI_RAW:
%{REQUEST_URI_RAW}'"

error.log
------------------
[yyyy-mm-dd hh:mm:ss.mmmmmm] [-:error] 127.0.0.1:35220
zzzzzzz__zzzzzzzzzzzzzzzzzz [client 127.0.0.1] ModSecurity: Access denied
with code 403 (phase 1). Match of "streq %{REQUEST_URI_RAW}" against
"REQUEST_URI" required. [file "/opt/apache-2.4.48/conf/httpd.conf"] [line
"200"] [id "11000"] [msg "URI evasion attempt REQUEST_URI: /yyyyy.php?site=
http://blubb REQUEST_URI_RAW: /yyyyy.php?site=http://blubb"] [tag
"domain.tld Public"] [hostname "domain.tld"] [uri "/yyyyy.php"] [unique_id
"zzzzzzz__zzzzzzzzzzzzzzzzzz"]

Regards,
Webco

Re: [mod-security-users] Allow HTML in post

[Christian V. <cv...@it...>]

Yo have to add exceptions to avoid mod security block certain HTML POST data. 
Look in the error log of apache or audit log of mod-security,  then look for the errors that are blocking the HTML POST, and search the id of the rule, then in the apache config (the one where you CMS is configured), you can add the exception like this:

If you want to disable specific rule in a specific path:

<LocationMatch "/user/login">
	SecRuleRemoveById 981319
</LocationMatch>

If you want to disable specific rule globally:

SecRuleRemoveById 981173

If you want to disable mod security in a specific path:

<Location /some_path/anotherpath>
  <IfModule security2_module>
        SecRuleEngine Off
    </IfModule>
</Location>

Cheers.
Chris.


> El 21-10-2021, a las 09:02, Reindl Harald <h.r...@th...> escribió:
> 
> 
> 
> Am 21.10.21 um 11:30 schrieb Filip Bartmann:
>> I'm new to mod_security and I have own CMS. I want in admin to edit HTML content. How can I enable to POST HTML tags? I Use mod_security v2 with Apache
> 
> <IfModule mod_security2.c>
> <LocationMatch "(.*)\/editor\/plugins\/preview\.php$">
>  SecRequestBodyAccess Off
> </LocationMatch>
> </IfModule>
> 
> 
> _______________________________________________
> 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] Allow HTML in post

[Reindl H. <h.r...@th...>]

Am 21.10.21 um 11:30 schrieb Filip Bartmann:
> I'm new to mod_security and I have own CMS. I want in admin to edit HTML content. How can I enable to POST HTML tags? I Use mod_security v2 with Apache

<IfModule mod_security2.c>
  <LocationMatch "(.*)\/editor\/plugins\/preview\.php$">
   SecRequestBodyAccess Off
  </LocationMatch>
</IfModule>

Re: [mod-security-users] Allow HTML in post

[Filip B. <fi...@ce...>]

Hello,
Yes I use.
 
Filip Bartmann
 
______________________________________________________________
> Od: az...@po...
> Komu: mod...@li...
> Datum: 21.10.2021 12:25
> Předmět: Re: [mod-security-users] Allow HTML in post
>
Hi Filip,
 
 what rules are you using? CRS?
 
 azurit
 
 
 
 
 Citát Filip Bartmann <fi...@ce...>:
 
 > Hello,
 > I'm new to mod_security and I have own CMS. I want in admin to edit  
 > HTML content. How can I enable to POST HTML tags? I Use mod_security  
 > v2 with Apache.
 >  
 > Thanks,
 > Filip Bartmann
 >  
 >
 >
 > _______________________________________________
 > mod-security-users mailing list
 > mod...@li...
 > https://lists.sourceforge.net/lists/listinfo/mod-security-users <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/rules/>
 > http://www.modsecurity.org/projects/commercial/support/ <http://www.modsecurity.org/projects/commercial/support/>
 
 
 
 
 
 _______________________________________________
 mod-security-users mailing list
 mod...@li...
 https://lists.sourceforge.net/lists/listinfo/mod-security-users <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/rules/>
 http://www.modsecurity.org/projects/commercial/support/ <http://www.modsecurity.org/projects/commercial/support/>