mod-security-users Mailing List for ModSecurity

Hi CM,

I was able to check that with the "regular" build options (that I
mentioned previously - Debian and Ubuntu feliver their packages
with those options.

Also I checked crs-setup.conf and enabled early blocking
mechanism:

https://github.com/coreruleset/coreruleset/blob/main/crs-setup.conf.example#L413-L421

I set up my config to use CRS on PL4 (to be sure that engine runs
as many rules as possible).

Then I sent a minimal but invalid request with telnet command:

telnet localhost 80
Trying ::1...
Connected to localhost.
Escape character is '^]'.
GET / HTTP/1.1
Host: 127.0.0.1

HTTP/1.1 200 OK
Date: Mon, 12 May 2025 08:32:07 GMT
Server: Apache/2.4.63 (Debian)
Content-Length: 0

Errors in this request:
* `Host` is an IP address - rule 920350
* `User-Agent` header is missing - rule 920320

These two rules collect 5 points which is enough to trigger rule
949111, which is responsible to deny the request in phase:1

https://github.com/coreruleset/coreruleset/blob/main/rules/REQUEST-949-BLOCKING-EVALUATION.conf#L212-L222

Here is the log:

ModSecurity: Warning. Operator EQ matched 1 at TX:early_blocking. [file "/home/airween/src/coreruleset/rules/REQUEST-949-BLOCKING-EVALUATION.conf"] [line "221"] [id "949111"] [msg "Inbound Anomaly Score Exceeded in phase 1 (Total Score: 5)"] [ver "OWASP_CRS/4.15.0-dev"]

(I get response 200 because the engine is in DetectionOnly mode,
and this is why you see "ModSecurity: Warning", and not "Access
Denied)

I think early blocking works as we expected.


Please check your config again - hope this summary helps you.


Regards,


a.

I tried a couple other builds of mod_security2.so (2.9.8 from Ubuntu 25.04, and a couple of Debian versions), with exactly the same results, and then I compiled my own 2.9.8, still with the same results, so I guess I was barking up the wrong tree.

Next line of thought, is there a minimum Apache version to properly handle the early blocking feature?

I am running Apache 2.4.58-1ubuntu8.6 so it's not too old

or is there any specific Apache-side configuration that has to be added in order for early blocking to function properly, outside of the modsecurity/CRS configs?


Sent with Proton Mail secure email.

On Friday, May 9th, 2025 at 2:31 AM, Ervin Hegedüs <ai...@gm...> wrote:

> Hi CM,
> 
> 
> On Thu, May 08, 2025 at 09:45:48PM +0000, CM via mod-security-users wrote:
> 
> > I am testing out the latest CRS 4.14 because I was interested in the "early blocking" feature
> > 
> > I am using Ubuntu 24.04 using its libapache2-mod-security2 package (version 2.9.7-1build3)
> > 
> > I believe this version of modsecurity should be sufficient for running the latest CRS, however, I get various strange behaviors when turning on early blocking.
> > 
> > As I understand it, modsecurity has a "--enable-request-early" compile flag that needs to be turned on, however, I'm not sure how to tell if my mod_security2.so was compiled with this option or not.
> 
> 
> If you take a look at the module's configure script, you can
> check how it works:
> 
> https://github.com/owasp-modsecurity/ModSecurity/blob/v2.9.7/configure.ac#L412-L426
> 
> # Enable phase-1 in post_read_request
> AC_ARG_ENABLE(request-early,
> AS_HELP_STRING([--enable-request-early],
> [Place phase1 into post_read_request hook. default is hook_request_early]),
> [
> if test "$enableval" != "no"; then
> request_early="-DREQUEST_EARLY"
> MODSEC_EXTRA_CFLAGS="$MODSEC_EXTRA_CFLAGS $request_early"
> else
> request_early=
> fi
> ],
> [
> request_early='-DREQUEST_EARLY'
> ])
> 
> This means if you pass `--enable-request-early=no` (which is
> equivalent with `--disable-request-early`), then you explicitly
> DISABLE this feature. The default is on.
> 
> (Btw I've nver used this option, and now I checked my generated
> Makefile, it contains this macro:
> 
> $ grep -rI REQUEST_EARLY *
> apache2/Makefile:MODSEC_APXS_EXTRA_CFLAGS = -Wc,-DWITH_PCRE_STUDY ... -DREQUEST_EARLY
> )
> 
> > My hypothesis is that because Ubuntu does not ship CRS 4.x yet, they might be compiling modsecurity with this functionality disabled.
> > 
> > I had an idea to try the libapache2-mod-security2 package from Ubuntu 25.04 (which would give me 2.9.8) however I haven't done so yet.
> > 
> > Is there a way to examine my mod_security2.so to determine if it was compiled with early blocking support or not?
> 
> 
> You can check the package build flags - I can't link that
> directly, but here is the package's debian/ directory:
> 
> http://archive.ubuntu.com/ubuntu/pool/universe/m/modsecurity-apache/modsecurity-apache_2.9.7-1build3.debian.tar.xz
> 
> After you download and unpack it, you can see the debian/rules
> file:
> 
> 16 build-stamp:
> 17 dh_testdir
> 18 dh_autoreconf
> 19 ./configure --prefix=/usr --with-apxs=/usr/bin/apxs2 --with-apr=/usr/bin/apr-config --with-lua=/usr/include/lua5.1 --with-pcre2 --enable-pcre-jit --enable-pcre-study CPPFLAGS='$(CPPFLAGS)' CFLAGS='$(CFLAGS)' LDFLAGS='$(LDFLAGS)'
> 
> As you can see there are no --enable-request-early=no nor
> --disable-request-early flags.
> 
> > Here are some of the odd behaviors I'm encountering:
> > 
> > - With early blocking enabled, requests that trigger an Apache redirect still get redirected, even though the audit log shows that they should have been blocked:
> > 
> > --992be21d-F--
> > HTTP/1.1 308 Permanent Redirect
> > ...
> > --992be21d-H--
> > Message: Access denied with code 403 (phase 1). [file "/usr/local/coreruleset/rules/REQUEST-949-BLOCKING-EVALUATION.conf"] [line "221"] [id "949111"] [msg "Inbound Anomaly Score Exceeded in phase 1 (Total Score: 12)"] [ver "OWASP_CRS/4.14.0"] [tag "anomaly-evaluation"] [tag "OWASP_CRS"]Action: Intercepted (phase 1)
> > 
> > - If I try to update rule 949111 to do anything other than a 403, then that action gets applied to ALL requests, not just blocks,
> > 
> > for example with this:
> > 
> > SecRuleUpdateActionById 949111 "status:404"
> > 
> > then even requests with an anomaly score of ZERO get blocked:
> > 
> > Message: Access denied with code 404 (phase 1). [file "/usr/local/coreruleset/rules/REQUEST-949-BLOCKING-EVALUATION.conf"] [line "221"] [id "949111"] [msg "Inbound Anomaly Score Exceeded in phase 1 (Total Score: 0)"] [ver "OWASP_CRS/4.14.0"] [tag "anomaly-evaluation"] [tag "OWASP_CRS"]
> > 
> > but if I don't modify 949111, then this doesn't happen
> 
> 
> I can take a look at this later.
> 
> 
> 
> a.

Hi CM,


On Thu, May 08, 2025 at 09:45:48PM +0000, CM via mod-security-users wrote:
> I am testing out the latest CRS 4.14 because I was interested in the "early blocking" feature
> 
> I am using Ubuntu 24.04 using its libapache2-mod-security2 package (version 2.9.7-1build3)
> 
> I believe this version of modsecurity should be sufficient for running the latest CRS, however, I get various strange behaviors when turning on early blocking.
> 
> As I understand it, modsecurity has a "--enable-request-early" compile flag that needs to be turned on, however, I'm not sure how to tell if my mod_security2.so was compiled with this option or not.

If you take a look at the module's configure script, you can
check how it works:

https://github.com/owasp-modsecurity/ModSecurity/blob/v2.9.7/configure.ac#L412-L426

# Enable phase-1 in post_read_request
AC_ARG_ENABLE(request-early,
              AS_HELP_STRING([--enable-request-early],
                             [Place phase1 into post_read_request hook. default is hook_request_early]),
[
  if test "$enableval" != "no"; then
    request_early="-DREQUEST_EARLY"
    MODSEC_EXTRA_CFLAGS="$MODSEC_EXTRA_CFLAGS $request_early"
  else
    request_early=
  fi
],
[
  request_early='-DREQUEST_EARLY'
])

This means if you pass `--enable-request-early=no` (which is
equivalent with `--disable-request-early`), then you explicitly
DISABLE this feature. The default is on.

(Btw I've nver used this option, and now I checked my generated
Makefile, it contains this macro:

$ grep -rI REQUEST_EARLY *
apache2/Makefile:MODSEC_APXS_EXTRA_CFLAGS = -Wc,-DWITH_PCRE_STUDY ... -DREQUEST_EARLY
)


> My hypothesis is that because Ubuntu does not ship CRS 4.x yet, they might be compiling modsecurity with this functionality disabled.
> 
> I had an idea to try the libapache2-mod-security2 package from Ubuntu 25.04 (which would give me 2.9.8) however I haven't done so yet.
> 
> Is there a way to examine my mod_security2.so to determine if it was compiled with early blocking support or not?

You can check the package build flags - I can't link that
directly, but here is the package's debian/ directory:

http://archive.ubuntu.com/ubuntu/pool/universe/m/modsecurity-apache/modsecurity-apache_2.9.7-1build3.debian.tar.xz

After you download and unpack it, you can see the debian/rules
file:

16 build-stamp:
17 	dh_testdir
18 	dh_autoreconf
19 	./configure --prefix=/usr --with-apxs=/usr/bin/apxs2 --with-apr=/usr/bin/apr-config --with-lua=/usr/include/lua5.1 --with-pcre2 --enable-pcre-jit --enable-pcre-study CPPFLAGS='$(CPPFLAGS)' CFLAGS='$(CFLAGS)' LDFLAGS='$(LDFLAGS)'

As you can see there are no --enable-request-early=no nor
--disable-request-early flags.

> Here are some of the odd behaviors I'm encountering:
> 
> -  With early blocking enabled, requests that trigger an Apache redirect still get redirected, even though the audit log shows that they should have been blocked:
> 
> --992be21d-F--
> HTTP/1.1 308 Permanent Redirect
> ...
> --992be21d-H--
> Message: Access denied with code 403 (phase 1). [file "/usr/local/coreruleset/rules/REQUEST-949-BLOCKING-EVALUATION.conf"] [line "221"] [id "949111"] [msg "Inbound Anomaly Score Exceeded in phase 1 (Total Score: 12)"] [ver "OWASP_CRS/4.14.0"] [tag "anomaly-evaluation"] [tag "OWASP_CRS"]Action: Intercepted (phase 1)
> 
> -  If I try to update rule 949111 to do anything other than a 403, then that action gets applied to ALL requests, not just blocks,
> 
> for example with this:
> 
> SecRuleUpdateActionById 949111 "status:404"
> 
> then even requests with an anomaly score of ZERO get blocked:
> 
> Message: Access denied with code 404 (phase 1). [file "/usr/local/coreruleset/rules/REQUEST-949-BLOCKING-EVALUATION.conf"] [line "221"] [id "949111"] [msg "Inbound Anomaly Score Exceeded in phase 1 (Total Score: 0)"] [ver "OWASP_CRS/4.14.0"] [tag "anomaly-evaluation"] [tag "OWASP_CRS"]
> 
> but if I don't modify 949111, then this doesn't happen

I can take a look at this later.



a.
 

I am testing out the latest CRS 4.14 because I was interested in the "early blocking" feature

I am using Ubuntu 24.04 using its libapache2-mod-security2 package (version 2.9.7-1build3)

I believe this version of modsecurity should be sufficient for running the latest CRS, however, I get various strange behaviors when turning on early blocking.

As I understand it, modsecurity has a "--enable-request-early" compile flag that needs to be turned on, however, I'm not sure how to tell if my mod_security2.so was compiled with this option or not.

My hypothesis is that because Ubuntu does not ship CRS 4.x yet, they might be compiling modsecurity with this functionality disabled.

I had an idea to try the libapache2-mod-security2 package from Ubuntu 25.04 (which would give me 2.9.8) however I haven't done so yet.

Is there a way to examine my mod_security2.so to determine if it was compiled with early blocking support or not?

Here are some of the odd behaviors I'm encountering:

-  With early blocking enabled, requests that trigger an Apache redirect still get redirected, even though the audit log shows that they should have been blocked:

--992be21d-F--
HTTP/1.1 308 Permanent Redirect
...
--992be21d-H--
Message: Access denied with code 403 (phase 1). [file "/usr/local/coreruleset/rules/REQUEST-949-BLOCKING-EVALUATION.conf"] [line "221"] [id "949111"] [msg "Inbound Anomaly Score Exceeded in phase 1 (Total Score: 12)"] [ver "OWASP_CRS/4.14.0"] [tag "anomaly-evaluation"] [tag "OWASP_CRS"]Action: Intercepted (phase 1)

-  If I try to update rule 949111 to do anything other than a 403, then that action gets applied to ALL requests, not just blocks,

for example with this:

SecRuleUpdateActionById 949111 "status:404"

then even requests with an anomaly score of ZERO get blocked:

Message: Access denied with code 404 (phase 1). [file "/usr/local/coreruleset/rules/REQUEST-949-BLOCKING-EVALUATION.conf"] [line "221"] [id "949111"] [msg "Inbound Anomaly Score Exceeded in phase 1 (Total Score: 0)"] [ver "OWASP_CRS/4.14.0"] [tag "anomaly-evaluation"] [tag "OWASP_CRS"]

but if I don't modify 949111, then this doesn't happen

Sent with [Proton Mail](https://proton.me/mail/home) secure email.

Hi CM,

In CRS v3, a handful of rules have explicit "log" actions defined (for
example: rules in REQUEST-949-BLOCKING-EVALUATION,
RESPONSE-980-CORRELATION, but oddly also a bunch of rules in
REQUEST-944-APPLICATION-ATTACK-JAVA which I think must be an old bug.)
These "more specific [log] actions" must be what's overriding the
SecDefaultAction directives, as:
    "Every rule following a...SecDefaultAction directive...will
inherit its settings unless more specific actions are used."

You'll struggle to *completely* keep ModSecurity log lines out of the
Apache error log in this way. There are also engine error lines (e.g.
PCRE errors), parser error log lines, and more which are not
controlled via rules or "log/nolog" actions. Maybe you could use a
LogLevel directive to help with this, although I think it's an odd use
case (I've never needed to try this).

Thinking out loud, an alternative solution for your desired *audit
logging* setup:
Instead of *implicitly* controlling audit logging (by adding
'auditlog' and 'noauditlog' actions via SecRuleUpdateActionById
directives) you could instead *explicitly* control when to switch the
audit engine on.
Pair a "SecAuditEngine Off" directive (to turn off audit logging in
the default case) with a rule (maybe in
RESPONSE-999-EXCLUSION-RULES-AFTER-CRS and in phase 5) that contains a
"ctl:auditEngine=On" action combined with a condition(s) of your
choosing, e.g.
"TX:ANOMALY_SCORE "@ge %{tx.inbound_anomaly_score_threshold}""
=>
ctl:auditEngine=On

Just throwing some ideas into the mix. You may be perfectly happy with
your current solution, but maybe you'd prefer to have a more explicit
level of audit logging control. I think the above idea would work fine
although I haven't tested it.

Thanks,
Andrew Howe

On Fri, 2 May 2025 at 23:21, CM via mod-security-users
<mod...@li...> wrote:
>
> > Just use SecDefaultAction and you don't have to set it for every rule.
>
>
> I have the following in crs-setup.conf:
>
> SecDefaultAction "phase:1,nolog,auditlog,pass"
> SecDefaultAction "phase:2,nolog,auditlog,pass"
>
> all other instances of SecDefaultAction in the file are commented out and I've verified using /server-info (mod_info) that there are no other instances of SecDefaultAction sneaking in from any other file
>
> regardless, rules 949110 and 980130 always end up in the error log unless they have "nolog" applied to them individually
>
> this was observed shortly after I first started using modsecurity in 2020 and has persisted across several updates
>
>
> >
> >
> >
> > > General objectives:
> > >
> > > 1. Keep modsecurity stuff out of the Apache error log, only log to
> > > the audit log (949110 and 980130 have been sneaking back into my
> > > error log for years and I hope I've now found a permanent solution)
> > >
> > > 2. If anomaly score isn't high enough to trigger a block (single
> > > warning or two notices), don't log to the audit log. I've started by
> > > noauditlog'ing 920210, which is the only warning-level violation
> > > I've been seeing in the wild, I also did 920180 and 920190 because I
> > > needed some more to test with. I may have to do more later but I'll
> > > do it when/if I start seeing other notice/warning violations in the
> > > log, I'm not going to bother doing them all in advance.
> > >
> > > I did some testing with curl and it seems to be working
> > >
> > > violating only one of rule 920180, 920190, 920210 does not block
> > > (score 3) and does not log to the audit log
> > >
> > > violating 2 of the 3 rules blocks (score 6) and does log to the audit log
> > >
> > > and the same for violating all 3 rules (score 9)
> > >
> > > so it seems to be working okay so far
> > > unless there's an easier/better way I could be accomplishing these
> > > objectives?
> > >
> > > Sent with Proton Mail secure email.
> > >
> > > On Friday, May 2nd, 2025 at 4:15 AM, Franziska Buehler
> > > fra...@gm... wrote:
> > >
> > > > Hi!
> > > >
> > > > It's not a good idea to edit the rule files directly, as you've noticed.
> > > >
> > > > The following directive works for me if I add it AFTER the CRS
> > > > rules include:
> > > > SecRuleUpdateActionById 920210 "noauditlog".
> > > > I've tested it.
> > > >
> > > > You can, for example, rename the file
> > > > rules/RESPONSE-999-EXCLUSION-RULES-AFTER-CRS.conf.example to
> > > > rules/RESPONSE-999-EXCLUSION-RULES-AFTER-CRS.conf and add the
> > > > directive there.
> > > > You can also use an include in your Apache config after the CRS
> > > > rules include.
> > > >
> > > > Why do you need a nolog for 949110 and 980130? This will make you
> > > > completely blind to which requests were blocked. Otherwise, you can
> > > > probably achieve it with the same directive as above.
> > > >
> > > > Please also read our excellent documentation on these topics:
> > > > https://coreruleset.org/docs/2-how-crs-works/2-3-false-positives-and-tuning/#directly-modifying-crs-rules
> > > > https://coreruleset.org/docs/2-how-crs-works/2-3-false-positives-and-tuning/#rule-exclusions
> > > > https://coreruleset.org/docs/2-how-crs-works/2-3-false-positives-and-tuning/#placement-of-rule-exclusions
> > > >
> > > > Best,
> > > > Franziska,
> > > > CRS Dev-on-Duty
> > > >
> > > > Am Do., 1. Mai 2025 um 23:27 Uhr schrieb CM via mod-security-users
> > > > mod...@li...:
> > > >
> > > > > I previously added "noauditlog" to rule 920210 by editing
> > > > > REQUEST-920-PROTOCOL-ENFORCEMENT.conf (and modified some other
> > > > > rules similarly) but I'm tired of the file getting overwritten by
> > > > > upgrades, I want to be able to manage my rule modifications
> > > > > centrally
> > > > >
> > > > > tried this first (too good to be true):
> > > > >
> > > > > SecRuleUpdateActionById 920210 "noauditlog"
> > > > >
> > > > > didn't work, I guess I'm overwriting everything that's there
> > > > > instead of just adding
> > > > >
> > > > > so I copied everything from the rule (except ID and phase) and
> > > > > added "nolog" to it, ending up with this:
> > > > >
> > > > > SecRuleUpdateActionById 920210 "block, noauditlog, t:none,
> > > > > msg:'Multiple/Conflicting Connection Header Data Found',
> > > > > logdata:'%{MATCHED_VAR}', tag:'application-multi',
> > > > > tag:'language-multi', tag:'platform-multi', tag:'attack-protocol',
> > > > > tag:'paranoia-level/1', tag:'OWASP_CRS', tag:'capec/1000/210/272',
> > > > > ver:'OWASP_CRS/3.3.5', severity:'WARNING',
> > > > > setvar:'tx.anomaly_score_pl1=+%{tx.warning_anomaly_score}'"
> > > > >
> > > > > that did sorta work but also it resulted in the anomaly score
> > > > > being applied twice, causing requests to be blocked that shouldn't
> > > > > have been
> > > > >
> > > > > so I tried removing just the anomaly score thing:
> > > > >
> > > > > SecRuleUpdateActionById 920210 "block, noauditlog, t:none,
> > > > > msg:'Multiple/Conflicting Connection Header Data Found',
> > > > > logdata:'%{MATCHED_VAR}', tag:'application-multi',
> > > > > tag:'language-multi', tag:'platform-multi', tag:'attack-protocol',
> > > > > tag:'paranoia-level/1', tag:'OWASP_CRS', tag:'capec/1000/210/272',
> > > > > ver:'OWASP_CRS/3.3.5', severity:'WARNING'"
> > > > >
> > > > > and that does seem to work but do I really need all that?
> > > > >
> > > > > what's the absolute minimum I can do here to add "noauditlog"
> > > > > without breaking functionality of the rule?
> > > > >
> > > > > I also need to add "nolog" to rule 949110 and 980130, so what's
> > > > > the simplest possible SecRuleUpdateActionById that would do this
> > > > > without breaking them?
> > > > >
> > > > > also I noticed I can't do this in my modsecurity.conf (because
> > > > > it's loaded before the rules), I had to put it in one of my Apache
> > > > > configurations that's loaded after the rules
> > > > >
> > > > > any possible way to make modsecurity.conf process after the rules
> > > > > files are loaded so I can use SecRuleUpdateActionById in it
> > > > > instead of in my Apache configs?
> > > > >
> > > > > apache2/mods-enabled/security2.conf contains the following:
> > > > >
> > > > > IncludeOptional /etc/modsecurity/*.conf
> > > > >
> > > > > IncludeOptional /usr/share/modsecurity-crs/*.load
> > > > >
> > > > > if I swapped the order of these, would it break anything?
> > > > >
> > > > > Sent with Proton Mail secure email.
> > > > > _______________________________________________
> > > > > 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/

> Just use SecDefaultAction and you don't have to set it for every rule.


I have the following in crs-setup.conf:

SecDefaultAction "phase:1,nolog,auditlog,pass"
SecDefaultAction "phase:2,nolog,auditlog,pass"

all other instances of SecDefaultAction in the file are commented out and I've verified using /server-info (mod_info) that there are no other instances of SecDefaultAction sneaking in from any other file

regardless, rules 949110 and 980130 always end up in the error log unless they have "nolog" applied to them individually

this was observed shortly after I first started using modsecurity in 2020 and has persisted across several updates


> 
> 
> 
> > General objectives:
> > 
> > 1. Keep modsecurity stuff out of the Apache error log, only log to
> > the audit log (949110 and 980130 have been sneaking back into my
> > error log for years and I hope I've now found a permanent solution)
> > 
> > 2. If anomaly score isn't high enough to trigger a block (single
> > warning or two notices), don't log to the audit log. I've started by
> > noauditlog'ing 920210, which is the only warning-level violation
> > I've been seeing in the wild, I also did 920180 and 920190 because I
> > needed some more to test with. I may have to do more later but I'll
> > do it when/if I start seeing other notice/warning violations in the
> > log, I'm not going to bother doing them all in advance.
> > 
> > I did some testing with curl and it seems to be working
> > 
> > violating only one of rule 920180, 920190, 920210 does not block
> > (score 3) and does not log to the audit log
> > 
> > violating 2 of the 3 rules blocks (score 6) and does log to the audit log
> > 
> > and the same for violating all 3 rules (score 9)
> > 
> > so it seems to be working okay so far
> > unless there's an easier/better way I could be accomplishing these
> > objectives?
> > 
> > Sent with Proton Mail secure email.
> > 
> > On Friday, May 2nd, 2025 at 4:15 AM, Franziska Buehler
> > fra...@gm... wrote:
> > 
> > > Hi!
> > > 
> > > It's not a good idea to edit the rule files directly, as you've noticed.
> > > 
> > > The following directive works for me if I add it AFTER the CRS
> > > rules include:
> > > SecRuleUpdateActionById 920210 "noauditlog".
> > > I've tested it.
> > > 
> > > You can, for example, rename the file
> > > rules/RESPONSE-999-EXCLUSION-RULES-AFTER-CRS.conf.example to
> > > rules/RESPONSE-999-EXCLUSION-RULES-AFTER-CRS.conf and add the
> > > directive there.
> > > You can also use an include in your Apache config after the CRS
> > > rules include.
> > > 
> > > Why do you need a nolog for 949110 and 980130? This will make you
> > > completely blind to which requests were blocked. Otherwise, you can
> > > probably achieve it with the same directive as above.
> > > 
> > > Please also read our excellent documentation on these topics:
> > > https://coreruleset.org/docs/2-how-crs-works/2-3-false-positives-and-tuning/#directly-modifying-crs-rules
> > > https://coreruleset.org/docs/2-how-crs-works/2-3-false-positives-and-tuning/#rule-exclusions
> > > https://coreruleset.org/docs/2-how-crs-works/2-3-false-positives-and-tuning/#placement-of-rule-exclusions
> > > 
> > > Best,
> > > Franziska,
> > > CRS Dev-on-Duty
> > > 
> > > Am Do., 1. Mai 2025 um 23:27 Uhr schrieb CM via mod-security-users
> > > mod...@li...:
> > > 
> > > > I previously added "noauditlog" to rule 920210 by editing
> > > > REQUEST-920-PROTOCOL-ENFORCEMENT.conf (and modified some other
> > > > rules similarly) but I'm tired of the file getting overwritten by
> > > > upgrades, I want to be able to manage my rule modifications
> > > > centrally
> > > > 
> > > > tried this first (too good to be true):
> > > > 
> > > > SecRuleUpdateActionById 920210 "noauditlog"
> > > > 
> > > > didn't work, I guess I'm overwriting everything that's there
> > > > instead of just adding
> > > > 
> > > > so I copied everything from the rule (except ID and phase) and
> > > > added "nolog" to it, ending up with this:
> > > > 
> > > > SecRuleUpdateActionById 920210 "block, noauditlog, t:none,
> > > > msg:'Multiple/Conflicting Connection Header Data Found',
> > > > logdata:'%{MATCHED_VAR}', tag:'application-multi',
> > > > tag:'language-multi', tag:'platform-multi', tag:'attack-protocol',
> > > > tag:'paranoia-level/1', tag:'OWASP_CRS', tag:'capec/1000/210/272',
> > > > ver:'OWASP_CRS/3.3.5', severity:'WARNING',
> > > > setvar:'tx.anomaly_score_pl1=+%{tx.warning_anomaly_score}'"
> > > > 
> > > > that did sorta work but also it resulted in the anomaly score
> > > > being applied twice, causing requests to be blocked that shouldn't
> > > > have been
> > > > 
> > > > so I tried removing just the anomaly score thing:
> > > > 
> > > > SecRuleUpdateActionById 920210 "block, noauditlog, t:none,
> > > > msg:'Multiple/Conflicting Connection Header Data Found',
> > > > logdata:'%{MATCHED_VAR}', tag:'application-multi',
> > > > tag:'language-multi', tag:'platform-multi', tag:'attack-protocol',
> > > > tag:'paranoia-level/1', tag:'OWASP_CRS', tag:'capec/1000/210/272',
> > > > ver:'OWASP_CRS/3.3.5', severity:'WARNING'"
> > > > 
> > > > and that does seem to work but do I really need all that?
> > > > 
> > > > what's the absolute minimum I can do here to add "noauditlog"
> > > > without breaking functionality of the rule?
> > > > 
> > > > I also need to add "nolog" to rule 949110 and 980130, so what's
> > > > the simplest possible SecRuleUpdateActionById that would do this
> > > > without breaking them?
> > > > 
> > > > also I noticed I can't do this in my modsecurity.conf (because
> > > > it's loaded before the rules), I had to put it in one of my Apache
> > > > configurations that's loaded after the rules
> > > > 
> > > > any possible way to make modsecurity.conf process after the rules
> > > > files are loaded so I can use SecRuleUpdateActionById in it
> > > > instead of in my Apache configs?
> > > > 
> > > > apache2/mods-enabled/security2.conf contains the following:
> > > > 
> > > > IncludeOptional /etc/modsecurity/*.conf
> > > > 
> > > > IncludeOptional /usr/share/modsecurity-crs/*.load
> > > > 
> > > > if I swapped the order of these, would it break anything?
> > > > 
> > > > Sent with Proton Mail secure email.
> > > > _______________________________________________
> > > > 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/

> SecRuleUpdateActionById 920180 "noauditlog"
> SecRuleUpdateActionById 920190 "noauditlog"
> SecRuleUpdateActionById 920210 "noauditlog"
> SecRuleUpdateActionById 949110 "nolog,auditlog"
> SecRuleUpdateActionById 980130 "nolog,auditlog"


Just use SecDefaultAction and you don't have to set it for every rule.




>
> General objectives:
>
> 1. Keep modsecurity stuff out of the Apache error log, only log to  
> the audit log (949110 and 980130 have been sneaking back into my  
> error log for years and I hope I've now found a permanent solution)
>
> 2. If anomaly score isn't high enough to trigger a block (single  
> warning or two notices), don't log to the audit log. I've started by  
> noauditlog'ing 920210, which is the only warning-level violation  
> I've been seeing in the wild, I also did 920180 and 920190 because I  
> needed some more to test with. I may have to do more later but I'll  
> do it when/if I start seeing other notice/warning violations in the  
> log, I'm not going to bother doing them all in advance.
>
> I did some testing with curl and it seems to be working
>
> violating only one of rule 920180, 920190, 920210 does not block  
> (score 3) and does not log to the audit log
>
> violating 2 of the 3 rules blocks (score 6) and does log to the audit log
>
> and the same for violating all 3 rules (score 9)
>
> so it seems to be working okay so far
> unless there's an easier/better way I could be accomplishing these  
> objectives?
>
> Sent with [Proton Mail](https://proton.me/mail/home) secure email.
>
> On Friday, May 2nd, 2025 at 4:15 AM, Franziska Buehler  
> <fra...@gm...> wrote:
>
>> Hi!
>>
>> It's not a good idea to edit the rule files directly, as you've noticed.
>>
>> The following directive works for me if I add it AFTER the CRS  
>> rules include:
>> SecRuleUpdateActionById 920210 "noauditlog".
>> I've tested it.
>>
>> You can, for example, rename the file  
>> rules/RESPONSE-999-EXCLUSION-RULES-AFTER-CRS.conf.example to  
>> rules/RESPONSE-999-EXCLUSION-RULES-AFTER-CRS.conf and add the  
>> directive there.
>> You can also use an include in your Apache config after the CRS  
>> rules include.
>>
>> Why do you need a nolog for 949110 and 980130? This will make you  
>> completely blind to which requests were blocked. Otherwise, you can  
>> probably achieve it with the same directive as above.
>>
>> Please also read our excellent documentation on these topics:
>> https://coreruleset.org/docs/2-how-crs-works/2-3-false-positives-and-tuning/#directly-modifying-crs-rules
>> https://coreruleset.org/docs/2-how-crs-works/2-3-false-positives-and-tuning/#rule-exclusions
>> https://coreruleset.org/docs/2-how-crs-works/2-3-false-positives-and-tuning/#placement-of-rule-exclusions
>>
>> Best,
>> Franziska,
>> CRS Dev-on-Duty
>>
>> Am Do., 1. Mai 2025 um 23:27 Uhr schrieb CM via mod-security-users  
>> <mod...@li...>:
>>
>>> I previously added "noauditlog" to rule 920210 by editing  
>>> REQUEST-920-PROTOCOL-ENFORCEMENT.conf (and modified some other  
>>> rules similarly) but I'm tired of the file getting overwritten by  
>>> upgrades, I want to be able to manage my rule modifications  
>>> centrally
>>>
>>> tried this first (too good to be true):
>>>
>>> SecRuleUpdateActionById 920210 "noauditlog"
>>>
>>> didn't work, I guess I'm overwriting everything that's there  
>>> instead of just adding
>>>
>>> so I copied everything from the rule (except ID and phase) and  
>>> added "nolog" to it, ending up with this:
>>>
>>> SecRuleUpdateActionById 920210 "block, noauditlog, t:none,  
>>> msg:'Multiple/Conflicting Connection Header Data Found',  
>>> logdata:'%{MATCHED_VAR}', tag:'application-multi',  
>>> tag:'language-multi', tag:'platform-multi', tag:'attack-protocol',  
>>> tag:'paranoia-level/1', tag:'OWASP_CRS', tag:'capec/1000/210/272',  
>>> ver:'OWASP_CRS/3.3.5', severity:'WARNING',  
>>> setvar:'tx.anomaly_score_pl1=+%{tx.warning_anomaly_score}'"
>>>
>>> that did sorta work but also it resulted in the anomaly score  
>>> being applied twice, causing requests to be blocked that shouldn't  
>>> have been
>>>
>>> so I tried removing just the anomaly score thing:
>>>
>>> SecRuleUpdateActionById 920210 "block, noauditlog, t:none,  
>>> msg:'Multiple/Conflicting Connection Header Data Found',  
>>> logdata:'%{MATCHED_VAR}', tag:'application-multi',  
>>> tag:'language-multi', tag:'platform-multi', tag:'attack-protocol',  
>>> tag:'paranoia-level/1', tag:'OWASP_CRS', tag:'capec/1000/210/272',  
>>> ver:'OWASP_CRS/3.3.5', severity:'WARNING'"
>>>
>>> and that does seem to work but do I really need all that?
>>>
>>> what's the absolute minimum I can do here to add "noauditlog"  
>>> without breaking functionality of the rule?
>>>
>>> I also need to add "nolog" to rule 949110 and 980130, so what's  
>>> the simplest possible SecRuleUpdateActionById that would do this  
>>> without breaking them?
>>>
>>> also I noticed I can't do this in my modsecurity.conf (because  
>>> it's loaded before the rules), I had to put it in one of my Apache  
>>> configurations that's loaded after the rules
>>>
>>> any possible way to make modsecurity.conf process after the rules  
>>> files are loaded so I can use SecRuleUpdateActionById in it  
>>> instead of in my Apache configs?
>>>
>>> apache2/mods-enabled/security2.conf contains the following:
>>>
>>> IncludeOptional /etc/modsecurity/*.conf
>>>
>>> IncludeOptional /usr/share/modsecurity-crs/*.load
>>>
>>> if I swapped the order of these, would it break anything?
>>>
>>> Sent with [Proton Mail](https://proton.me/mail/home) secure email.
>>> _______________________________________________
>>> 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/

Thank you for the information.

After messing with it for a while here's what I ended up with:

SecRuleUpdateActionById 920180 "noauditlog"
SecRuleUpdateActionById 920190 "noauditlog"
SecRuleUpdateActionById 920210 "noauditlog"
SecRuleUpdateActionById 949110 "nolog,auditlog"
SecRuleUpdateActionById 980130 "nolog,auditlog"

General objectives:

1. Keep modsecurity stuff out of the Apache error log, only log to the audit log (949110 and 980130 have been sneaking back into my error log for years and I hope I've now found a permanent solution)

2. If anomaly score isn't high enough to trigger a block (single warning or two notices), don't log to the audit log. I've started by noauditlog'ing 920210, which is the only warning-level violation I've been seeing in the wild, I also did 920180 and 920190 because I needed some more to test with. I may have to do more later but I'll do it when/if I start seeing other notice/warning violations in the log, I'm not going to bother doing them all in advance.

I did some testing with curl and it seems to be working

violating only one of rule 920180, 920190, 920210 does not block (score 3) and does not log to the audit log

violating 2 of the 3 rules blocks (score 6) and does log to the audit log

and the same for violating all 3 rules (score 9)

so it seems to be working okay so far
unless there's an easier/better way I could be accomplishing these objectives?

Sent with [Proton Mail](https://proton.me/mail/home) secure email.

On Friday, May 2nd, 2025 at 4:15 AM, Franziska Buehler <fra...@gm...> wrote:

> Hi!
>
> It's not a good idea to edit the rule files directly, as you've noticed.
>
> The following directive works for me if I add it AFTER the CRS rules include:
> SecRuleUpdateActionById 920210 "noauditlog".
> I've tested it.
>
> You can, for example, rename the file rules/RESPONSE-999-EXCLUSION-RULES-AFTER-CRS.conf.example to rules/RESPONSE-999-EXCLUSION-RULES-AFTER-CRS.conf and add the directive there.
> You can also use an include in your Apache config after the CRS rules include.
>
> Why do you need a nolog for 949110 and 980130? This will make you completely blind to which requests were blocked. Otherwise, you can probably achieve it with the same directive as above.
>
> Please also read our excellent documentation on these topics:
> https://coreruleset.org/docs/2-how-crs-works/2-3-false-positives-and-tuning/#directly-modifying-crs-rules
> https://coreruleset.org/docs/2-how-crs-works/2-3-false-positives-and-tuning/#rule-exclusions
> https://coreruleset.org/docs/2-how-crs-works/2-3-false-positives-and-tuning/#placement-of-rule-exclusions
>
> Best,
> Franziska,
> CRS Dev-on-Duty
>
> Am Do., 1. Mai 2025 um 23:27 Uhr schrieb CM via mod-security-users <mod...@li...>:
>
>> I previously added "noauditlog" to rule 920210 by editing REQUEST-920-PROTOCOL-ENFORCEMENT.conf (and modified some other rules similarly) but I'm tired of the file getting overwritten by upgrades, I want to be able to manage my rule modifications centrally
>>
>> tried this first (too good to be true):
>>
>> SecRuleUpdateActionById 920210 "noauditlog"
>>
>> didn't work, I guess I'm overwriting everything that's there instead of just adding
>>
>> so I copied everything from the rule (except ID and phase) and added "nolog" to it, ending up with this:
>>
>> SecRuleUpdateActionById 920210 "block, noauditlog, t:none, msg:'Multiple/Conflicting Connection Header Data Found', logdata:'%{MATCHED_VAR}', tag:'application-multi', tag:'language-multi', tag:'platform-multi', tag:'attack-protocol', tag:'paranoia-level/1', tag:'OWASP_CRS', tag:'capec/1000/210/272', ver:'OWASP_CRS/3.3.5', severity:'WARNING', setvar:'tx.anomaly_score_pl1=+%{tx.warning_anomaly_score}'"
>>
>> that did sorta work but also it resulted in the anomaly score being applied twice, causing requests to be blocked that shouldn't have been
>>
>> so I tried removing just the anomaly score thing:
>>
>> SecRuleUpdateActionById 920210 "block, noauditlog, t:none, msg:'Multiple/Conflicting Connection Header Data Found', logdata:'%{MATCHED_VAR}', tag:'application-multi', tag:'language-multi', tag:'platform-multi', tag:'attack-protocol', tag:'paranoia-level/1', tag:'OWASP_CRS', tag:'capec/1000/210/272', ver:'OWASP_CRS/3.3.5', severity:'WARNING'"
>>
>> and that does seem to work but do I really need all that?
>>
>> what's the absolute minimum I can do here to add "noauditlog" without breaking functionality of the rule?
>>
>> I also need to add "nolog" to rule 949110 and 980130, so what's the simplest possible SecRuleUpdateActionById that would do this without breaking them?
>>
>> also I noticed I can't do this in my modsecurity.conf (because it's loaded before the rules), I had to put it in one of my Apache configurations that's loaded after the rules
>>
>> any possible way to make modsecurity.conf process after the rules files are loaded so I can use SecRuleUpdateActionById in it instead of in my Apache configs?
>>
>> apache2/mods-enabled/security2.conf contains the following:
>>
>> IncludeOptional /etc/modsecurity/*.conf
>>
>> IncludeOptional /usr/share/modsecurity-crs/*.load
>>
>> if I swapped the order of these, would it break anything?
>>
>> Sent with [Proton Mail](https://proton.me/mail/home) secure email.
>> _______________________________________________
>> 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/

Hi!

It's not a good idea to edit the rule files directly, as you've noticed.

The following directive works for me if I add it AFTER the CRS rules
include:
SecRuleUpdateActionById 920210 "noauditlog".
I've tested it.

You can, for example, rename the file
rules/RESPONSE-999-EXCLUSION-RULES-AFTER-CRS.conf.example to
rules/RESPONSE-999-EXCLUSION-RULES-AFTER-CRS.conf and add the directive
there.
You can also use an include in your Apache config after the CRS rules
include.

Why do you need a nolog for 949110 and 980130? This will make you
completely blind to which requests were blocked. Otherwise, you can
probably achieve it with the same directive as above.

Please also read our excellent documentation on these topics:
https://coreruleset.org/docs/2-how-crs-works/2-3-false-positives-and-tuning/#directly-modifying-crs-rules
https://coreruleset.org/docs/2-how-crs-works/2-3-false-positives-and-tuning/#rule-exclusions
https://coreruleset.org/docs/2-how-crs-works/2-3-false-positives-and-tuning/#placement-of-rule-exclusions

Best,
Franziska,
CRS Dev-on-Duty

Am Do., 1. Mai 2025 um 23:27 Uhr schrieb CM via mod-security-users <
mod...@li...>:

> I previously added "noauditlog" to rule 920210 by editing REQUEST-920-PROTOCOL-ENFORCEMENT.conf
> (and modified some other rules similarly) but I'm tired of the file getting
> overwritten by upgrades, I want to be able to manage my rule modifications
> centrally
>
> tried this first (too good to be true):
>
> SecRuleUpdateActionById 920210 "noauditlog"
>
> didn't work, I guess I'm overwriting everything that's there instead of
> just adding
>
> so I copied everything from the rule (except ID and phase) and added
> "nolog" to it, ending up with this:
>
> SecRuleUpdateActionById 920210 "block, noauditlog, t:none,
> msg:'Multiple/Conflicting Connection Header Data Found',
> logdata:'%{MATCHED_VAR}', tag:'application-multi', tag:'language-multi',
> tag:'platform-multi', tag:'attack-protocol', tag:'paranoia-level/1',
> tag:'OWASP_CRS', tag:'capec/1000/210/272', ver:'OWASP_CRS/3.3.5',
> severity:'WARNING',
> setvar:'tx.anomaly_score_pl1=+%{tx.warning_anomaly_score}'"
>
> that did sorta work but also it resulted in the anomaly score being
> applied twice, causing requests to be blocked that shouldn't have been
>
> so I tried removing just the anomaly score thing:
>
> SecRuleUpdateActionById 920210 "block, noauditlog, t:none,
> msg:'Multiple/Conflicting Connection Header Data Found',
> logdata:'%{MATCHED_VAR}', tag:'application-multi', tag:'language-multi',
> tag:'platform-multi', tag:'attack-protocol', tag:'paranoia-level/1',
> tag:'OWASP_CRS', tag:'capec/1000/210/272', ver:'OWASP_CRS/3.3.5',
> severity:'WARNING'"
>
> and that does seem to work but do I really need all that?
>
> what's the absolute minimum I can do here to add "noauditlog" without
> breaking functionality of the rule?
>
> I also need to add "nolog" to rule 949110 and 980130, so what's the
> simplest possible SecRuleUpdateActionById that would do this without
> breaking them?
>
> also I noticed I can't do this in my modsecurity.conf (because it's
> loaded before the rules), I had to put it in one of my Apache
> configurations that's loaded after the rules
>
> any possible way to make modsecurity.conf process after the rules files
> are loaded so I can use SecRuleUpdateActionById in it instead of in my
> Apache configs?
>
> apache2/mods-enabled/security2.conf contains the following:
>
> IncludeOptional /etc/modsecurity/*.conf
> IncludeOptional /usr/share/modsecurity-crs/*.load
>
> if I swapped the order of these, would it break anything?
>
> Sent with Proton Mail <https://proton.me/mail/home> secure email.
> _______________________________________________
> 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/
>

I previously added "noauditlog" to rule 920210 by editing REQUEST-920-PROTOCOL-ENFORCEMENT.conf (and modified some other rules similarly) but I'm tired of the file getting overwritten by upgrades, I want to be able to manage my rule modifications centrally

tried this first (too good to be true):

SecRuleUpdateActionById 920210 "noauditlog"

didn't work, I guess I'm overwriting everything that's there instead of just adding

so I copied everything from the rule (except ID and phase) and added "nolog" to it, ending up with this:

SecRuleUpdateActionById 920210 "block, noauditlog, t:none, msg:'Multiple/Conflicting Connection Header Data Found', logdata:'%{MATCHED_VAR}', tag:'application-multi', tag:'language-multi', tag:'platform-multi', tag:'attack-protocol', tag:'paranoia-level/1', tag:'OWASP_CRS', tag:'capec/1000/210/272', ver:'OWASP_CRS/3.3.5', severity:'WARNING', setvar:'tx.anomaly_score_pl1=+%{tx.warning_anomaly_score}'"

that did sorta work but also it resulted in the anomaly score being applied twice, causing requests to be blocked that shouldn't have been

so I tried removing just the anomaly score thing:

SecRuleUpdateActionById 920210 "block, noauditlog, t:none, msg:'Multiple/Conflicting Connection Header Data Found', logdata:'%{MATCHED_VAR}', tag:'application-multi', tag:'language-multi', tag:'platform-multi', tag:'attack-protocol', tag:'paranoia-level/1', tag:'OWASP_CRS', tag:'capec/1000/210/272', ver:'OWASP_CRS/3.3.5', severity:'WARNING'"

and that does seem to work but do I really need all that?

what's the absolute minimum I can do here to add "noauditlog" without breaking functionality of the rule?

I also need to add "nolog" to rule 949110 and 980130, so what's the simplest possible SecRuleUpdateActionById that would do this without breaking them?

also I noticed I can't do this in my modsecurity.conf (because it's loaded before the rules), I had to put it in one of my Apache configurations that's loaded after the rules

any possible way to make modsecurity.conf process after the rules files are loaded so I can use SecRuleUpdateActionById in it instead of in my Apache configs?

apache2/mods-enabled/security2.conf contains the following:

IncludeOptional /etc/modsecurity/*.conf

IncludeOptional /usr/share/modsecurity-crs/*.load

if I swapped the order of these, would it break anything?

Sent with [Proton Mail](https://proton.me/mail/home) secure email.

Hi Marcello,

On Mon, Apr 07, 2025 at 11:10:34AM +0200, Marcello Lorenzi wrote:
> Hi All,
> we have a simple reverse proxy and we installed mod_security to check the
> incoming traffic but we noticed a lot of APIs 403 backend errors in the
> audit_log but they were correct for the application side. Is it possible to
> disable the print of the backend 403 and have only the mod_security blocks?

sorry to say but unfortunately there is only one response code,
we can't distinguish it by its source.

What I think is to put an extra response header in the backend
side, and make a rule which checks that response header. If it
exists (with a specified value), then turn off the audit.log for
that transaction (ctl:auditLogEngine=Off). Or something
similar...


a.
 

Hi All,
we have a simple reverse proxy and we installed mod_security to check the
incoming traffic but we noticed a lot of APIs 403 backend errors in the
audit_log but they were correct for the application side. Is it possible to
disable the print of the backend 403 and have only the mod_security blocks?

Thanks in advance,
Marcello

Hi Monah,

If in doubt, a concrete troubleshooting step would be to enable debug
logging (to the highest level), re-test, and see precisely what is
(and what is not) happening.

You should be able to observe in the debug log:

* Rule 900990 executing
    * The action setvar:tx.crs_setup_version=4130 being executed
* Rule 901001 executing
    * The operator &TX:crs_setup_version "@eq 0" being evaluated

Thanks,
Andrew


On Sun, 6 Apr 2025 at 14:19, Monah Baki <mon...@gm...> wrote:
>
> No custom rules.
>
> What I did is I renamed my owasp 4.13.0 to a different folder and moved my owasp crs 4.8.0 back to its original folder, restarted apache and from another machine typed the following:
> curl -I https://osisolutions.net/index.php?f=/../../../../../etc/passwd
>
> root@waf:/usr/local/etc/modsecurity # tail -f /var/log/httpd/osisolutions-error_log
> [Sun Apr 06 09:10:54.062738 2025] [security2:error] [pid 47174] [client 71.126.165.145:53450] ModSecurity: Warning. Pattern match "(?i)(?:[/\\\\x5c]|%(?:2(?:f|5(?:2f|5c|c(?:1%259c|0%25af))|%46)|5c|c(?:0%(?:[2aq]f|5c|9v)|1%(?:[19p]c|8s|af))|(?:bg%q|(?:e|f(?:8%8)?0%8)0%80%a)f|u(?:221[56]|EFC8|F025|002f)|%3(?:2(?:%(?:%6|4)6|F)|5%%63)|1u)|0x(?:2f|5c))(?:\\\\.(?:%0[01]|\\\\?)?|\\\\?\\\\.?|%(?:2( ..." at REQUEST_URI_RAW. [file "/usr/local/etc/modsecurity/owasp-modsecurity-crs/rules/REQUEST-930-APPLICATION-ATTACK-LFI.conf"] [line "53"] [id "930100"] [msg "Path Traversal Attack (/../) or (/.../)"] [data "Matched Data: /../ found within REQUEST_URI_RAW: /index.php?f=/../../../../../etc/passwd"] [severity "CRITICAL"] [ver "OWASP_CRS/4.8.0-dev"] [tag "application-multi"] [tag "language-multi"] [tag "platform-multi"] [tag "attack-lfi"] [tag "paranoia-level/1"] [tag "OWASP_CRS"] [tag "capec/1000/255/153/126"] [hostname "osisolutions.net"] [uri "/index.php"] [unique_id "Z_J9XgOebQ1Fdmj9nC2ctgAAAAA"]
> [Sun Apr 06 09:10:54.063066 2025] [security2:error] [pid 47174] [client 71.126.165.145:53450] ModSecurity: Warning. Pattern match "(?i)(?:[/\\\\x5c]|%(?:2(?:f|5(?:2f|5c|c(?:1%259c|0%25af))|%46)|5c|c(?:0%(?:[2aq]f|5c|9v)|1%(?:[19p]c|8s|af))|(?:bg%q|(?:e|f(?:8%8)?0%8)0%80%a)f|u(?:221[56]|EFC8|F025|002f)|%3(?:2(?:%(?:%6|4)6|F)|5%%63)|1u)|0x(?:2f|5c))(?:\\\\.(?:%0[01]|\\\\?)?|\\\\?\\\\.?|%(?:2( ..." at ARGS:f. [file "/usr/local/etc/modsecurity/owasp-modsecurity-crs/rules/REQUEST-930-APPLICATION-ATTACK-LFI.conf"] [line "53"] [id "930100"] [msg "Path Traversal Attack (/../) or (/.../)"] [data "Matched Data: /../ found within ARGS:f: /../../../../../etc/passwd"] [severity "CRITICAL"] [ver "OWASP_CRS/4.8.0-dev"] [tag "application-multi"] [tag "language-multi"] [tag "platform-multi"] [tag "attack-lfi"] [tag "paranoia-level/1"] [tag "OWASP_CRS"] [tag "capec/1000/255/153/126"] [hostname "osisolutions.net"] [uri "/index.php"] [unique_id "Z_J9XgOebQ1Fdmj9nC2ctgAAAAA"]
> [Sun Apr 06 09:10:54.063240 2025] [security2:error] [pid 47174] [client 71.126.165.145:53450] ModSecurity: Warning. Pattern match "(?:(?:^|[\\\\x5c/;])\\\\.{2,3}[\\\\x5c/;]|[\\\\x5c/;]\\\\.{2,3}(?:[\\\\x5c/;]|$))" at REQUEST_URI. [file "/usr/local/etc/modsecurity/owasp-modsecurity-crs/rules/REQUEST-930-APPLICATION-ATTACK-LFI.conf"] [line "86"] [id "930110"] [msg "Path Traversal Attack (/../) or (/.../)"] [data "Matched Data: /../ found within REQUEST_URI: /index.php?f=/../../../../../etc/passwd"] [severity "CRITICAL"] [ver "OWASP_CRS/4.8.0-dev"] [tag "application-multi"] [tag "language-multi"] [tag "platform-multi"] [tag "attack-lfi"] [tag "paranoia-level/1"] [tag "OWASP_CRS"] [tag "capec/1000/255/153/126"] [hostname "osisolutions.net"] [uri "/index.php"] [unique_id "Z_J9XgOebQ1Fdmj9nC2ctgAAAAA"]
> [Sun Apr 06 09:10:54.063389 2025] [security2:error] [pid 47174] [client 71.126.165.145:53450] ModSecurity: Warning. Pattern match "(?:(?:^|[\\\\x5c/;])\\\\.{2,3}[\\\\x5c/;]|[\\\\x5c/;]\\\\.{2,3}(?:[\\\\x5c/;]|$))" at REQUEST_URI. [file "/usr/local/etc/modsecurity/owasp-modsecurity-crs/rules/REQUEST-930-APPLICATION-ATTACK-LFI.conf"] [line "86"] [id "930110"] [msg "Path Traversal Attack (/../) or (/.../)"] [data "Matched Data: /../ found within REQUEST_URI: /index.php?f=/../../../../../etc/passwd"] [severity "CRITICAL"] [ver "OWASP_CRS/4.8.0-dev"] [tag "application-multi"] [tag "language-multi"] [tag "platform-multi"] [tag "attack-lfi"] [tag "paranoia-level/1"] [tag "OWASP_CRS"] [tag "capec/1000/255/153/126"] [hostname "osisolutions.net"] [uri "/index.php"] [unique_id "Z_J9XgOebQ1Fdmj9nC2ctgAAAAA"]
>
>
>
> Went and reverted back my owasp 4.13.0 folder and ran the same curl command and got
>
> [Sun Apr 06 09:12:38.731325 2025] [security2:error] [pid 47228] [client 71.126.165.145:57026] ModSecurity: Access denied with code 500 (phase 1). Operator EQ matched 0 at TX. [file "/usr/local/etc/modsecurity/owasp-modsecurity-crs/rules/REQUEST-901-INITIALIZATION.conf"] [line "64"] [id "901001"] [msg "CRS is deployed without configuration! Please copy the crs-setup.conf.example template to crs-setup.conf, and include the crs-setup.conf file in your webserver configuration before including the CRS rules. See the INSTALL file in the CRS directory for detailed instructions"] [severity "CRITICAL"] [ver "OWASP_CRS/4.13.0"] [tag "OWASP_CRS"] [hostname "osisolutions.net"] [uri "/index.php"] [unique_id "Z_J9xiNCfPcpnd_qywN4xQAAAAA"]
>
> On Sun, Apr 6, 2025 at 9:08 AM <az...@po...> wrote:
>>
>> Are you using any custom rules or CRS modifications?
>>
>>
>>
>>
>>
>> Citát Monah Baki <mon...@gm...>:
>>
>> > Hi Ervin,
>> >
>> > Here is he output
>> > root@waf:/usr/local/etc/apache24 #  grep -A12 900990
>> > /usr/local/etc/modsecurity/owasp-modsecurity-crs/crs-setup.conf
>> >     "id:900990,\
>> >     phase:1,\
>> >     pass,\
>> >     t:none,\
>> >     nolog,\
>> >     tag:'OWASP_CRS',\
>> >     ver:'OWASP_CRS/4.13.0',\
>> >     setvar:tx.crs_setup_version=4130"
>> >
>> > As far as my apache using
>> > /usr/local/etc/apache24/modules.d/280_mod_security.conf, I am sure because
>> > if I were to comment
>> > LoadModule unique_id_module libexec/apache24/mod_unique_id.so
>> > LoadModule security2_module /usr/local/modsecurity/lib/mod_security2.so
>> >
>> > I get
>> >
>> > root@waf:/home/mbaki # apachectl restart
>> > Performing sanity check on apache24 configuration:
>> > AH00526: Syntax error on line 97 of
>> > /usr/local/etc/modsecurity/owasp-modsecurity-crs/crs-setup.conf:
>> > Invalid command 'SecDefaultAction', perhaps misspelled or defined by a
>> > module not included in the server configuration
>> >
>> > Thanks
>> > Monah
>> >
>> > On Sun, Apr 6, 2025 at 4:54 AM Ervin Hegedüs <ai...@gm...> wrote:
>> >
>> >> Hi Monan,
>> >>
>> >>
>> >> On Sat, Apr 05, 2025 at 04:02:09PM -0400, Monah Baki wrote:
>> >> >
>> >> > ls /usr/local/etc/modsecurity/owasp-modsecurity-crs
>> >> > crs-setup.conf
>> >>
>> >> as Christian wrote this is very strange.
>> >>
>> >> Anyway,
>> >>
>> >> are you sure your engine use this file?
>> >>
>> >> > cat /usr/local/etc/apache24/modules.d/280_mod_security.conf
>> >>
>> >> could you replace this line:
>> >>
>> >> > IncludeOptional
>> >> /usr/local/etc/modsecurity/owasp-modsecurity-crs/crs-setup.conf
>> >>
>> >> by this one:
>> >>
>> >> Include /usr/local/etc/modsecurity/owasp-modsecurity-crs/crs-setup.conf
>> >>
>> >> so just remote the "Optional" string.
>> >>
>> >> And could you show us the output of this command?
>> >>
>> >> grep -A12 900990
>> >> /usr/local/etc/modsecurity/owasp-modsecurity-crs/crs-setup.conf
>> >>
>> >>
>> >> Thanks,
>> >>
>> >>
>> >> a.
>> >>
>> >>
>> >>
>> >> _______________________________________________
>> >> 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/

No custom rules.

What I did is I renamed my owasp 4.13.0 to a different folder and moved my
owasp crs 4.8.0 back to its original folder, restarted apache and from
another machine typed the following:
curl -I https://osisolutions.net/index.php?f=/../../../../../etc/passwd

root@waf:/usr/local/etc/modsecurity # tail -f
/var/log/httpd/osisolutions-error_log
[Sun Apr 06 09:10:54.062738 2025] [security2:error] [pid 47174] [client
71.126.165.145:53450] ModSecurity: Warning. Pattern match
"(?i)(?:[/\\\\x5c]|%(?:2(?:f|5(?:2f|5c|c(?:1%259c|0%25af))|%46)|5c|c(?:0%(?:[2aq]f|5c|9v)|1%(?:[19p]c|8s|af))|(?:bg%q|(?:e|f(?:8%8)?0%8)0%80%a)f|u(?:221[56]|EFC8|F025|002f)|%3(?:2(?:%(?:%6|4)6|F)|5%%63)|1u)|0x(?:2f|5c))(?:\\\\.(?:%0[01]|\\\\?)?|\\\\?\\\\.?|%(?:2(
..." at REQUEST_URI_RAW. [file
"/usr/local/etc/modsecurity/owasp-modsecurity-crs/rules/REQUEST-930-APPLICATION-ATTACK-LFI.conf"]
[line "53"] [id "930100"] [msg "Path Traversal Attack (/../) or (/.../)"]
[data "Matched Data: /../ found within REQUEST_URI_RAW:
/index.php?f=/../../../../../etc/passwd"] [severity "CRITICAL"] [ver
"OWASP_CRS/4.8.0-dev"] [tag "application-multi"] [tag "language-multi"]
[tag "platform-multi"] [tag "attack-lfi"] [tag "paranoia-level/1"] [tag
"OWASP_CRS"] [tag "capec/1000/255/153/126"] [hostname "osisolutions.net"]
[uri "/index.php"] [unique_id "Z_J9XgOebQ1Fdmj9nC2ctgAAAAA"]
[Sun Apr 06 09:10:54.063066 2025] [security2:error] [pid 47174] [client
71.126.165.145:53450] ModSecurity: Warning. Pattern match
"(?i)(?:[/\\\\x5c]|%(?:2(?:f|5(?:2f|5c|c(?:1%259c|0%25af))|%46)|5c|c(?:0%(?:[2aq]f|5c|9v)|1%(?:[19p]c|8s|af))|(?:bg%q|(?:e|f(?:8%8)?0%8)0%80%a)f|u(?:221[56]|EFC8|F025|002f)|%3(?:2(?:%(?:%6|4)6|F)|5%%63)|1u)|0x(?:2f|5c))(?:\\\\.(?:%0[01]|\\\\?)?|\\\\?\\\\.?|%(?:2(
..." at ARGS:f. [file
"/usr/local/etc/modsecurity/owasp-modsecurity-crs/rules/REQUEST-930-APPLICATION-ATTACK-LFI.conf"]
[line "53"] [id "930100"] [msg "Path Traversal Attack (/../) or (/.../)"]
[data "Matched Data: /../ found within ARGS:f: /../../../../../etc/passwd"]
[severity "CRITICAL"] [ver "OWASP_CRS/4.8.0-dev"] [tag "application-multi"]
[tag "language-multi"] [tag "platform-multi"] [tag "attack-lfi"] [tag
"paranoia-level/1"] [tag "OWASP_CRS"] [tag "capec/1000/255/153/126"]
[hostname "osisolutions.net"] [uri "/index.php"] [unique_id
"Z_J9XgOebQ1Fdmj9nC2ctgAAAAA"]
[Sun Apr 06 09:10:54.063240 2025] [security2:error] [pid 47174] [client
71.126.165.145:53450] ModSecurity: Warning. Pattern match
"(?:(?:^|[\\\\x5c/;])\\\\.{2,3}[\\\\x5c/;]|[\\\\x5c/;]\\\\.{2,3}(?:[\\\\x5c/;]|$))"
at REQUEST_URI. [file
"/usr/local/etc/modsecurity/owasp-modsecurity-crs/rules/REQUEST-930-APPLICATION-ATTACK-LFI.conf"]
[line "86"] [id "930110"] [msg "Path Traversal Attack (/../) or (/.../)"]
[data "Matched Data: /../ found within REQUEST_URI:
/index.php?f=/../../../../../etc/passwd"] [severity "CRITICAL"] [ver
"OWASP_CRS/4.8.0-dev"] [tag "application-multi"] [tag "language-multi"]
[tag "platform-multi"] [tag "attack-lfi"] [tag "paranoia-level/1"] [tag
"OWASP_CRS"] [tag "capec/1000/255/153/126"] [hostname "osisolutions.net"]
[uri "/index.php"] [unique_id "Z_J9XgOebQ1Fdmj9nC2ctgAAAAA"]
[Sun Apr 06 09:10:54.063389 2025] [security2:error] [pid 47174] [client
71.126.165.145:53450] ModSecurity: Warning. Pattern match
"(?:(?:^|[\\\\x5c/;])\\\\.{2,3}[\\\\x5c/;]|[\\\\x5c/;]\\\\.{2,3}(?:[\\\\x5c/;]|$))"
at REQUEST_URI. [file
"/usr/local/etc/modsecurity/owasp-modsecurity-crs/rules/REQUEST-930-APPLICATION-ATTACK-LFI.conf"]
[line "86"] [id "930110"] [msg "Path Traversal Attack (/../) or (/.../)"]
[data "Matched Data: /../ found within REQUEST_URI:
/index.php?f=/../../../../../etc/passwd"] [severity "CRITICAL"] [ver
"OWASP_CRS/4.8.0-dev"] [tag "application-multi"] [tag "language-multi"]
[tag "platform-multi"] [tag "attack-lfi"] [tag "paranoia-level/1"] [tag
"OWASP_CRS"] [tag "capec/1000/255/153/126"] [hostname "osisolutions.net"]
[uri "/index.php"] [unique_id "Z_J9XgOebQ1Fdmj9nC2ctgAAAAA"]



Went and reverted back my owasp 4.13.0 folder and ran the same curl command
and got

[Sun Apr 06 09:12:38.731325 2025] [security2:error] [pid 47228] [client
71.126.165.145:57026] ModSecurity: Access denied with code 500 (phase 1).
Operator EQ matched 0 at TX. [file
"/usr/local/etc/modsecurity/owasp-modsecurity-crs/rules/REQUEST-901-INITIALIZATION.conf"]
[line "64"] [id "901001"] [msg "CRS is deployed without configuration!
Please copy the crs-setup.conf.example template to crs-setup.conf, and
include the crs-setup.conf file in your webserver configuration before
including the CRS rules. See the INSTALL file in the CRS directory for
detailed instructions"] [severity "CRITICAL"] [ver "OWASP_CRS/4.13.0"] [tag
"OWASP_CRS"] [hostname "osisolutions.net"] [uri "/index.php"] [unique_id
"Z_J9xiNCfPcpnd_qywN4xQAAAAA"]

On Sun, Apr 6, 2025 at 9:08 AM <az...@po...> wrote:

> Are you using any custom rules or CRS modifications?
>
>
>
>
>
> Citát Monah Baki <mon...@gm...>:
>
> > Hi Ervin,
> >
> > Here is he output
> > root@waf:/usr/local/etc/apache24 #  grep -A12 900990
> > /usr/local/etc/modsecurity/owasp-modsecurity-crs/crs-setup.conf
> >     "id:900990,\
> >     phase:1,\
> >     pass,\
> >     t:none,\
> >     nolog,\
> >     tag:'OWASP_CRS',\
> >     ver:'OWASP_CRS/4.13.0',\
> >     setvar:tx.crs_setup_version=4130"
> >
> > As far as my apache using
> > /usr/local/etc/apache24/modules.d/280_mod_security.conf, I am sure
> because
> > if I were to comment
> > LoadModule unique_id_module libexec/apache24/mod_unique_id.so
> > LoadModule security2_module /usr/local/modsecurity/lib/mod_security2.so
> >
> > I get
> >
> > root@waf:/home/mbaki # apachectl restart
> > Performing sanity check on apache24 configuration:
> > AH00526: Syntax error on line 97 of
> > /usr/local/etc/modsecurity/owasp-modsecurity-crs/crs-setup.conf:
> > Invalid command 'SecDefaultAction', perhaps misspelled or defined by a
> > module not included in the server configuration
> >
> > Thanks
> > Monah
> >
> > On Sun, Apr 6, 2025 at 4:54 AM Ervin Hegedüs <ai...@gm...> wrote:
> >
> >> Hi Monan,
> >>
> >>
> >> On Sat, Apr 05, 2025 at 04:02:09PM -0400, Monah Baki wrote:
> >> >
> >> > ls /usr/local/etc/modsecurity/owasp-modsecurity-crs
> >> > crs-setup.conf
> >>
> >> as Christian wrote this is very strange.
> >>
> >> Anyway,
> >>
> >> are you sure your engine use this file?
> >>
> >> > cat /usr/local/etc/apache24/modules.d/280_mod_security.conf
> >>
> >> could you replace this line:
> >>
> >> > IncludeOptional
> >> /usr/local/etc/modsecurity/owasp-modsecurity-crs/crs-setup.conf
> >>
> >> by this one:
> >>
> >> Include /usr/local/etc/modsecurity/owasp-modsecurity-crs/crs-setup.conf
> >>
> >> so just remote the "Optional" string.
> >>
> >> And could you show us the output of this command?
> >>
> >> grep -A12 900990
> >> /usr/local/etc/modsecurity/owasp-modsecurity-crs/crs-setup.conf
> >>
> >>
> >> Thanks,
> >>
> >>
> >> a.
> >>
> >>
> >>
> >> _______________________________________________
> >> 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/
>

Are you using any custom rules or CRS modifications?





Citát Monah Baki <mon...@gm...>:

> Hi Ervin,
>
> Here is he output
> root@waf:/usr/local/etc/apache24 #  grep -A12 900990
> /usr/local/etc/modsecurity/owasp-modsecurity-crs/crs-setup.conf
>     "id:900990,\
>     phase:1,\
>     pass,\
>     t:none,\
>     nolog,\
>     tag:'OWASP_CRS',\
>     ver:'OWASP_CRS/4.13.0',\
>     setvar:tx.crs_setup_version=4130"
>
> As far as my apache using
> /usr/local/etc/apache24/modules.d/280_mod_security.conf, I am sure because
> if I were to comment
> LoadModule unique_id_module libexec/apache24/mod_unique_id.so
> LoadModule security2_module /usr/local/modsecurity/lib/mod_security2.so
>
> I get
>
> root@waf:/home/mbaki # apachectl restart
> Performing sanity check on apache24 configuration:
> AH00526: Syntax error on line 97 of
> /usr/local/etc/modsecurity/owasp-modsecurity-crs/crs-setup.conf:
> Invalid command 'SecDefaultAction', perhaps misspelled or defined by a
> module not included in the server configuration
>
> Thanks
> Monah
>
> On Sun, Apr 6, 2025 at 4:54 AM Ervin Hegedüs <ai...@gm...> wrote:
>
>> Hi Monan,
>>
>>
>> On Sat, Apr 05, 2025 at 04:02:09PM -0400, Monah Baki wrote:
>> >
>> > ls /usr/local/etc/modsecurity/owasp-modsecurity-crs
>> > crs-setup.conf
>>
>> as Christian wrote this is very strange.
>>
>> Anyway,
>>
>> are you sure your engine use this file?
>>
>> > cat /usr/local/etc/apache24/modules.d/280_mod_security.conf
>>
>> could you replace this line:
>>
>> > IncludeOptional
>> /usr/local/etc/modsecurity/owasp-modsecurity-crs/crs-setup.conf
>>
>> by this one:
>>
>> Include /usr/local/etc/modsecurity/owasp-modsecurity-crs/crs-setup.conf
>>
>> so just remote the "Optional" string.
>>
>> And could you show us the output of this command?
>>
>> grep -A12 900990
>> /usr/local/etc/modsecurity/owasp-modsecurity-crs/crs-setup.conf
>>
>>
>> Thanks,
>>
>>
>> a.
>>
>>
>>
>> _______________________________________________
>> 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/
>>

Hi Ervin,

Here is he output
root@waf:/usr/local/etc/apache24 #  grep -A12 900990
/usr/local/etc/modsecurity/owasp-modsecurity-crs/crs-setup.conf
    "id:900990,\
    phase:1,\
    pass,\
    t:none,\
    nolog,\
    tag:'OWASP_CRS',\
    ver:'OWASP_CRS/4.13.0',\
    setvar:tx.crs_setup_version=4130"

As far as my apache using
/usr/local/etc/apache24/modules.d/280_mod_security.conf, I am sure because
if I were to comment
LoadModule unique_id_module libexec/apache24/mod_unique_id.so
LoadModule security2_module /usr/local/modsecurity/lib/mod_security2.so

I get

root@waf:/home/mbaki # apachectl restart
Performing sanity check on apache24 configuration:
AH00526: Syntax error on line 97 of
/usr/local/etc/modsecurity/owasp-modsecurity-crs/crs-setup.conf:
Invalid command 'SecDefaultAction', perhaps misspelled or defined by a
module not included in the server configuration

Thanks
Monah

On Sun, Apr 6, 2025 at 4:54 AM Ervin Hegedüs <ai...@gm...> wrote:

> Hi Monan,
>
>
> On Sat, Apr 05, 2025 at 04:02:09PM -0400, Monah Baki wrote:
> >
> > ls /usr/local/etc/modsecurity/owasp-modsecurity-crs
> > crs-setup.conf
>
> as Christian wrote this is very strange.
>
> Anyway,
>
> are you sure your engine use this file?
>
> > cat /usr/local/etc/apache24/modules.d/280_mod_security.conf
>
> could you replace this line:
>
> > IncludeOptional
> /usr/local/etc/modsecurity/owasp-modsecurity-crs/crs-setup.conf
>
> by this one:
>
> Include /usr/local/etc/modsecurity/owasp-modsecurity-crs/crs-setup.conf
>
> so just remote the "Optional" string.
>
> And could you show us the output of this command?
>
> grep -A12 900990
> /usr/local/etc/modsecurity/owasp-modsecurity-crs/crs-setup.conf
>
>
> Thanks,
>
>
> a.
>
>
>
> _______________________________________________
> 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/
>

Hi Monan,


On Sat, Apr 05, 2025 at 04:02:09PM -0400, Monah Baki wrote:
> 
> ls /usr/local/etc/modsecurity/owasp-modsecurity-crs
> crs-setup.conf

as Christian wrote this is very strange.

Anyway,

are you sure your engine use this file?
 
> cat /usr/local/etc/apache24/modules.d/280_mod_security.conf

could you replace this line:

> IncludeOptional /usr/local/etc/modsecurity/owasp-modsecurity-crs/crs-setup.conf

by this one:

Include /usr/local/etc/modsecurity/owasp-modsecurity-crs/crs-setup.conf

so just remote the "Optional" string.

And could you show us the output of this command?

grep -A12 900990 /usr/local/etc/modsecurity/owasp-modsecurity-crs/crs-setup.conf


Thanks,


a.

Ofcourse

SecAction \
    "id:900990,\
    phase:1,\
    pass,\
    t:none,\
    nolog,\
    tag:'OWASP_CRS',\
    ver:'OWASP_CRS/4.13.0',\
    setvar:tx.crs_setup_version=4130"

Thanks

On Sat, Apr 5, 2025 at 7:19 PM Christian Folini <chr...@ne...>
wrote:

> Hey Monah,
>
> This is very strange. Filename, location and permissions look ok.
>
> Can you show us rule 900990 from crs-setup.conf, where tx.crs_setup_version
> is being set?
>
> Best,
>
> Christian
> On Sat, Apr 05, 2025 at 04:39:30PM -0400, Monah Baki wrote:
> > Hi Christian,
> >
> > ls -la  /usr/local/etc/modsecurity/owasp-modsecurity-crs/crs-setup.conf
> > -rw-r--r--  1 mbaki mbaki 35639 Mar 31 11:18
> > /usr/local/etc/modsecurity/owasp-modsecurity-crs/crs-setup.conf
> >
> >
> > Also
> >
> > mbaki@waf:~ $ ls -la  /usr/local/etc/modsecurity/owasp-modsecurity-crs/
> > total 320
> > drwxr-xr-x  9 mbaki mbaki   1024 Apr  5 10:47 .
> > drwxr-xr-x  4 root  wheel    512 Apr  5 10:57 ..
> > -rw-r--r--  1 mbaki mbaki    518 Mar 31 11:18 .editorconfig
> > drwxr-xr-x  5 mbaki mbaki    512 Mar 31 11:18 .github
> > -rw-r--r--  1 mbaki mbaki    661 Mar 31 11:18 .gitignore
> > -rw-r--r--  1 mbaki mbaki      0 Mar 31 11:18 .gitmodules
> > -rw-r--r--  1 mbaki mbaki    315 Mar 31 11:18 .linelint.yml
> > -rw-r--r--  1 mbaki mbaki    432 Mar 31 11:18 .pre-commit-config.yaml
> > -rw-r--r--  1 mbaki mbaki    751 Mar 31 11:18 .yamllint.yml
> > -rw-r--r--  1 mbaki mbaki 144155 Mar 31 11:18 CHANGES.md
> > -rw-r--r--  1 mbaki mbaki  28523 Mar 31 11:18 CONTRIBUTING.md
> > -rw-r--r--  1 mbaki mbaki   6564 Mar 31 11:18 CONTRIBUTORS.md
> > -rw-r--r--  1 mbaki mbaki  11489 Mar 31 11:18 INSTALL.md
> > -rw-r--r--  1 mbaki mbaki   2783 Mar 31 11:18 KNOWN_BUGS.md
> > -rw-r--r--  1 mbaki mbaki  11347 Mar 31 11:18 LICENSE
> > -rw-r--r--  1 mbaki mbaki   2871 Mar 31 11:18 README.md
> > -rw-r--r--  1 mbaki mbaki   4543 Mar 31 11:18 SECURITY.md
> > -rw-r--r--  1 mbaki mbaki     89 Mar 31 11:18 SPONSORS.md
> > -rw-r--r--  1 mbaki mbaki  35639 Mar 31 11:18 crs-setup.conf
> > drwxr-xr-x  2 mbaki mbaki    512 Mar 31 11:18 docs
> > drwxr-xr-x  2 mbaki mbaki    512 Mar 31 11:18 plugins
> > drwxr-xr-x  4 mbaki mbaki   2560 Mar 31 11:18 regex-assembly
> > -rw-r--r--  1 mbaki mbaki    222 Mar 31 11:18 renovate.json
> > drwxr-xr-x  2 mbaki mbaki   2048 Apr  5 09:55 rules
> > drwxr-xr-x  5 mbaki mbaki    512 Mar 31 11:18 tests
> > drwxr-xr-x  5 mbaki mbaki    512 Mar 31 11:18 util
> >
> >
> > Thanks
> > Monah
> >
> > On Sat, Apr 5, 2025 at 4:26 PM Christian Folini <
> chr...@ne...>
> > wrote:
> >
> > > Hey Monah,
> > >
> > > Are you sure the file
> > >
> > > /usr/local/etc/modsecurity/owasp-modsecurity-crs/crs-setup.conf
> > >
> > > exists?
> > >
> > > The error message clearly says it can't be read:
> > >
> > > CRS is deployed without configuration!
> > > Please copy the crs-setup.conf.example template to crs-setup.conf, and
> > > include the crs-setup.conf file in your webserver configuration before
> > > including the CRS rules. See the INSTALL file in the CRS directory for
> > > detailed instructions
> > >
> > > Best,
> > >
> > > Christian
> > >
> > > On Sat, Apr 05, 2025 at 04:02:09PM -0400, Monah Baki wrote:
> > > > Hello all,
> > > >
> > > > I am running Freebsd 14.2 and  I upgraded my owasp to v4.13.0.
> However I
> > > am
> > > > seeing in my http error logs the following
> > > >
> > > > [Sat Apr 05 11:24:27.646852 2025] [security2:error] [pid 96152]
> [client
> > > > 23.95.132.51:56151] ModSecurity: Access denied with code 500 (phase
> 1).
> > > > Operator EQ matched 0 at TX. [file
> > > >
> > >
> "/usr/local/etc/modsecurity/owasp-modsecurity-crs/rules/REQUEST-901-INITIALIZATION.conf"]
> > > > [line "64"] [id "901001"] [msg "CRS is deployed without
> configuration!
> > > > Please copy the crs-setup.conf.example template to crs-setup.conf,
> and
> > > > include the crs-setup.conf file in your webserver configuration
> before
> > > > including the CRS rules. See the INSTALL file in the CRS directory
> for
> > > > detailed instructions"] [severity "CRITICAL"] [ver
> "OWASP_CRS/4.13.0"]
> > > [tag
> > > > "OWASP_CRS"]
> > > >
> > > >
> > > > ls /usr/local/etc/modsecurity/owasp-modsecurity-crs
> > > > crs-setup.conf
> > > >
> > > > cat /usr/local/etc/apache24/modules.d/280_mod_security.conf
> > > > IncludeOptional
> > > > /usr/local/etc/modsecurity/owasp-modsecurity-crs/crs-setup.conf
> > > > IncludeOptional
> > > >
> /usr/local/etc/modsecurity/owasp-modsecurity-crs/plugins/*-config.conf
> > > > IncludeOptional
> > > >
> /usr/local/etc/modsecurity/owasp-modsecurity-crs/plugins/*-before.conf
> > > > Include /usr/local/etc/modsecurity/owasp-modsecurity-crs/rules/*.conf
> > > > IncludeOptional
> > > > /usr/local/etc/modsecurity/owasp-modsecurity-crs/plugins/*-after.conf
> > > >
> > > >
> > > > Thanks
> > > > Monah
> > >
> > >
> > > > _______________________________________________
> > > > 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/
>
>
>
> _______________________________________________
> 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/
>

Hey Monah,

This is very strange. Filename, location and permissions look ok.

Can you show us rule 900990 from crs-setup.conf, where tx.crs_setup_version
is being set?

Best,

Christian
On Sat, Apr 05, 2025 at 04:39:30PM -0400, Monah Baki wrote:
> Hi Christian,
> 
> ls -la  /usr/local/etc/modsecurity/owasp-modsecurity-crs/crs-setup.conf
> -rw-r--r--  1 mbaki mbaki 35639 Mar 31 11:18
> /usr/local/etc/modsecurity/owasp-modsecurity-crs/crs-setup.conf
> 
> 
> Also
> 
> mbaki@waf:~ $ ls -la  /usr/local/etc/modsecurity/owasp-modsecurity-crs/
> total 320
> drwxr-xr-x  9 mbaki mbaki   1024 Apr  5 10:47 .
> drwxr-xr-x  4 root  wheel    512 Apr  5 10:57 ..
> -rw-r--r--  1 mbaki mbaki    518 Mar 31 11:18 .editorconfig
> drwxr-xr-x  5 mbaki mbaki    512 Mar 31 11:18 .github
> -rw-r--r--  1 mbaki mbaki    661 Mar 31 11:18 .gitignore
> -rw-r--r--  1 mbaki mbaki      0 Mar 31 11:18 .gitmodules
> -rw-r--r--  1 mbaki mbaki    315 Mar 31 11:18 .linelint.yml
> -rw-r--r--  1 mbaki mbaki    432 Mar 31 11:18 .pre-commit-config.yaml
> -rw-r--r--  1 mbaki mbaki    751 Mar 31 11:18 .yamllint.yml
> -rw-r--r--  1 mbaki mbaki 144155 Mar 31 11:18 CHANGES.md
> -rw-r--r--  1 mbaki mbaki  28523 Mar 31 11:18 CONTRIBUTING.md
> -rw-r--r--  1 mbaki mbaki   6564 Mar 31 11:18 CONTRIBUTORS.md
> -rw-r--r--  1 mbaki mbaki  11489 Mar 31 11:18 INSTALL.md
> -rw-r--r--  1 mbaki mbaki   2783 Mar 31 11:18 KNOWN_BUGS.md
> -rw-r--r--  1 mbaki mbaki  11347 Mar 31 11:18 LICENSE
> -rw-r--r--  1 mbaki mbaki   2871 Mar 31 11:18 README.md
> -rw-r--r--  1 mbaki mbaki   4543 Mar 31 11:18 SECURITY.md
> -rw-r--r--  1 mbaki mbaki     89 Mar 31 11:18 SPONSORS.md
> -rw-r--r--  1 mbaki mbaki  35639 Mar 31 11:18 crs-setup.conf
> drwxr-xr-x  2 mbaki mbaki    512 Mar 31 11:18 docs
> drwxr-xr-x  2 mbaki mbaki    512 Mar 31 11:18 plugins
> drwxr-xr-x  4 mbaki mbaki   2560 Mar 31 11:18 regex-assembly
> -rw-r--r--  1 mbaki mbaki    222 Mar 31 11:18 renovate.json
> drwxr-xr-x  2 mbaki mbaki   2048 Apr  5 09:55 rules
> drwxr-xr-x  5 mbaki mbaki    512 Mar 31 11:18 tests
> drwxr-xr-x  5 mbaki mbaki    512 Mar 31 11:18 util
> 
> 
> Thanks
> Monah
> 
> On Sat, Apr 5, 2025 at 4:26 PM Christian Folini <chr...@ne...>
> wrote:
> 
> > Hey Monah,
> >
> > Are you sure the file
> >
> > /usr/local/etc/modsecurity/owasp-modsecurity-crs/crs-setup.conf
> >
> > exists?
> >
> > The error message clearly says it can't be read:
> >
> > CRS is deployed without configuration!
> > Please copy the crs-setup.conf.example template to crs-setup.conf, and
> > include the crs-setup.conf file in your webserver configuration before
> > including the CRS rules. See the INSTALL file in the CRS directory for
> > detailed instructions
> >
> > Best,
> >
> > Christian
> >
> > On Sat, Apr 05, 2025 at 04:02:09PM -0400, Monah Baki wrote:
> > > Hello all,
> > >
> > > I am running Freebsd 14.2 and  I upgraded my owasp to v4.13.0. However I
> > am
> > > seeing in my http error logs the following
> > >
> > > [Sat Apr 05 11:24:27.646852 2025] [security2:error] [pid 96152] [client
> > > 23.95.132.51:56151] ModSecurity: Access denied with code 500 (phase 1).
> > > Operator EQ matched 0 at TX. [file
> > >
> > "/usr/local/etc/modsecurity/owasp-modsecurity-crs/rules/REQUEST-901-INITIALIZATION.conf"]
> > > [line "64"] [id "901001"] [msg "CRS is deployed without configuration!
> > > Please copy the crs-setup.conf.example template to crs-setup.conf, and
> > > include the crs-setup.conf file in your webserver configuration before
> > > including the CRS rules. See the INSTALL file in the CRS directory for
> > > detailed instructions"] [severity "CRITICAL"] [ver "OWASP_CRS/4.13.0"]
> > [tag
> > > "OWASP_CRS"]
> > >
> > >
> > > ls /usr/local/etc/modsecurity/owasp-modsecurity-crs
> > > crs-setup.conf
> > >
> > > cat /usr/local/etc/apache24/modules.d/280_mod_security.conf
> > > IncludeOptional
> > > /usr/local/etc/modsecurity/owasp-modsecurity-crs/crs-setup.conf
> > > IncludeOptional
> > > /usr/local/etc/modsecurity/owasp-modsecurity-crs/plugins/*-config.conf
> > > IncludeOptional
> > > /usr/local/etc/modsecurity/owasp-modsecurity-crs/plugins/*-before.conf
> > > Include /usr/local/etc/modsecurity/owasp-modsecurity-crs/rules/*.conf
> > > IncludeOptional
> > > /usr/local/etc/modsecurity/owasp-modsecurity-crs/plugins/*-after.conf
> > >
> > >
> > > Thanks
> > > Monah
> >
> >
> > > _______________________________________________
> > > 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/

Hi Christian,

ls -la  /usr/local/etc/modsecurity/owasp-modsecurity-crs/crs-setup.conf
-rw-r--r--  1 mbaki mbaki 35639 Mar 31 11:18
/usr/local/etc/modsecurity/owasp-modsecurity-crs/crs-setup.conf


Also

mbaki@waf:~ $ ls -la  /usr/local/etc/modsecurity/owasp-modsecurity-crs/
total 320
drwxr-xr-x  9 mbaki mbaki   1024 Apr  5 10:47 .
drwxr-xr-x  4 root  wheel    512 Apr  5 10:57 ..
-rw-r--r--  1 mbaki mbaki    518 Mar 31 11:18 .editorconfig
drwxr-xr-x  5 mbaki mbaki    512 Mar 31 11:18 .github
-rw-r--r--  1 mbaki mbaki    661 Mar 31 11:18 .gitignore
-rw-r--r--  1 mbaki mbaki      0 Mar 31 11:18 .gitmodules
-rw-r--r--  1 mbaki mbaki    315 Mar 31 11:18 .linelint.yml
-rw-r--r--  1 mbaki mbaki    432 Mar 31 11:18 .pre-commit-config.yaml
-rw-r--r--  1 mbaki mbaki    751 Mar 31 11:18 .yamllint.yml
-rw-r--r--  1 mbaki mbaki 144155 Mar 31 11:18 CHANGES.md
-rw-r--r--  1 mbaki mbaki  28523 Mar 31 11:18 CONTRIBUTING.md
-rw-r--r--  1 mbaki mbaki   6564 Mar 31 11:18 CONTRIBUTORS.md
-rw-r--r--  1 mbaki mbaki  11489 Mar 31 11:18 INSTALL.md
-rw-r--r--  1 mbaki mbaki   2783 Mar 31 11:18 KNOWN_BUGS.md
-rw-r--r--  1 mbaki mbaki  11347 Mar 31 11:18 LICENSE
-rw-r--r--  1 mbaki mbaki   2871 Mar 31 11:18 README.md
-rw-r--r--  1 mbaki mbaki   4543 Mar 31 11:18 SECURITY.md
-rw-r--r--  1 mbaki mbaki     89 Mar 31 11:18 SPONSORS.md
-rw-r--r--  1 mbaki mbaki  35639 Mar 31 11:18 crs-setup.conf
drwxr-xr-x  2 mbaki mbaki    512 Mar 31 11:18 docs
drwxr-xr-x  2 mbaki mbaki    512 Mar 31 11:18 plugins
drwxr-xr-x  4 mbaki mbaki   2560 Mar 31 11:18 regex-assembly
-rw-r--r--  1 mbaki mbaki    222 Mar 31 11:18 renovate.json
drwxr-xr-x  2 mbaki mbaki   2048 Apr  5 09:55 rules
drwxr-xr-x  5 mbaki mbaki    512 Mar 31 11:18 tests
drwxr-xr-x  5 mbaki mbaki    512 Mar 31 11:18 util


Thanks
Monah

On Sat, Apr 5, 2025 at 4:26 PM Christian Folini <chr...@ne...>
wrote:

> Hey Monah,
>
> Are you sure the file
>
> /usr/local/etc/modsecurity/owasp-modsecurity-crs/crs-setup.conf
>
> exists?
>
> The error message clearly says it can't be read:
>
> CRS is deployed without configuration!
> Please copy the crs-setup.conf.example template to crs-setup.conf, and
> include the crs-setup.conf file in your webserver configuration before
> including the CRS rules. See the INSTALL file in the CRS directory for
> detailed instructions
>
> Best,
>
> Christian
>
> On Sat, Apr 05, 2025 at 04:02:09PM -0400, Monah Baki wrote:
> > Hello all,
> >
> > I am running Freebsd 14.2 and  I upgraded my owasp to v4.13.0. However I
> am
> > seeing in my http error logs the following
> >
> > [Sat Apr 05 11:24:27.646852 2025] [security2:error] [pid 96152] [client
> > 23.95.132.51:56151] ModSecurity: Access denied with code 500 (phase 1).
> > Operator EQ matched 0 at TX. [file
> >
> "/usr/local/etc/modsecurity/owasp-modsecurity-crs/rules/REQUEST-901-INITIALIZATION.conf"]
> > [line "64"] [id "901001"] [msg "CRS is deployed without configuration!
> > Please copy the crs-setup.conf.example template to crs-setup.conf, and
> > include the crs-setup.conf file in your webserver configuration before
> > including the CRS rules. See the INSTALL file in the CRS directory for
> > detailed instructions"] [severity "CRITICAL"] [ver "OWASP_CRS/4.13.0"]
> [tag
> > "OWASP_CRS"]
> >
> >
> > ls /usr/local/etc/modsecurity/owasp-modsecurity-crs
> > crs-setup.conf
> >
> > cat /usr/local/etc/apache24/modules.d/280_mod_security.conf
> > IncludeOptional
> > /usr/local/etc/modsecurity/owasp-modsecurity-crs/crs-setup.conf
> > IncludeOptional
> > /usr/local/etc/modsecurity/owasp-modsecurity-crs/plugins/*-config.conf
> > IncludeOptional
> > /usr/local/etc/modsecurity/owasp-modsecurity-crs/plugins/*-before.conf
> > Include /usr/local/etc/modsecurity/owasp-modsecurity-crs/rules/*.conf
> > IncludeOptional
> > /usr/local/etc/modsecurity/owasp-modsecurity-crs/plugins/*-after.conf
> >
> >
> > Thanks
> > Monah
>
>
> > _______________________________________________
> > 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/
>

Hey Monah,

Are you sure the file

/usr/local/etc/modsecurity/owasp-modsecurity-crs/crs-setup.conf

exists?

The error message clearly says it can't be read:

CRS is deployed without configuration!
Please copy the crs-setup.conf.example template to crs-setup.conf, and
include the crs-setup.conf file in your webserver configuration before
including the CRS rules. See the INSTALL file in the CRS directory for
detailed instructions

Best,

Christian

On Sat, Apr 05, 2025 at 04:02:09PM -0400, Monah Baki wrote:
> Hello all,
> 
> I am running Freebsd 14.2 and  I upgraded my owasp to v4.13.0. However I am
> seeing in my http error logs the following
> 
> [Sat Apr 05 11:24:27.646852 2025] [security2:error] [pid 96152] [client
> 23.95.132.51:56151] ModSecurity: Access denied with code 500 (phase 1).
> Operator EQ matched 0 at TX. [file
> "/usr/local/etc/modsecurity/owasp-modsecurity-crs/rules/REQUEST-901-INITIALIZATION.conf"]
> [line "64"] [id "901001"] [msg "CRS is deployed without configuration!
> Please copy the crs-setup.conf.example template to crs-setup.conf, and
> include the crs-setup.conf file in your webserver configuration before
> including the CRS rules. See the INSTALL file in the CRS directory for
> detailed instructions"] [severity "CRITICAL"] [ver "OWASP_CRS/4.13.0"] [tag
> "OWASP_CRS"]
> 
> 
> ls /usr/local/etc/modsecurity/owasp-modsecurity-crs
> crs-setup.conf
> 
> cat /usr/local/etc/apache24/modules.d/280_mod_security.conf
> IncludeOptional
> /usr/local/etc/modsecurity/owasp-modsecurity-crs/crs-setup.conf
> IncludeOptional
> /usr/local/etc/modsecurity/owasp-modsecurity-crs/plugins/*-config.conf
> IncludeOptional
> /usr/local/etc/modsecurity/owasp-modsecurity-crs/plugins/*-before.conf
> Include /usr/local/etc/modsecurity/owasp-modsecurity-crs/rules/*.conf
> IncludeOptional
> /usr/local/etc/modsecurity/owasp-modsecurity-crs/plugins/*-after.conf
> 
> 
> Thanks
> Monah


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

Hello all,

I am running Freebsd 14.2 and  I upgraded my owasp to v4.13.0. However I am
seeing in my http error logs the following

[Sat Apr 05 11:24:27.646852 2025] [security2:error] [pid 96152] [client
23.95.132.51:56151] ModSecurity: Access denied with code 500 (phase 1).
Operator EQ matched 0 at TX. [file
"/usr/local/etc/modsecurity/owasp-modsecurity-crs/rules/REQUEST-901-INITIALIZATION.conf"]
[line "64"] [id "901001"] [msg "CRS is deployed without configuration!
Please copy the crs-setup.conf.example template to crs-setup.conf, and
include the crs-setup.conf file in your webserver configuration before
including the CRS rules. See the INSTALL file in the CRS directory for
detailed instructions"] [severity "CRITICAL"] [ver "OWASP_CRS/4.13.0"] [tag
"OWASP_CRS"]


ls /usr/local/etc/modsecurity/owasp-modsecurity-crs
crs-setup.conf

cat /usr/local/etc/apache24/modules.d/280_mod_security.conf
IncludeOptional
/usr/local/etc/modsecurity/owasp-modsecurity-crs/crs-setup.conf
IncludeOptional
/usr/local/etc/modsecurity/owasp-modsecurity-crs/plugins/*-config.conf
IncludeOptional
/usr/local/etc/modsecurity/owasp-modsecurity-crs/plugins/*-before.conf
Include /usr/local/etc/modsecurity/owasp-modsecurity-crs/rules/*.conf
IncludeOptional
/usr/local/etc/modsecurity/owasp-modsecurity-crs/plugins/*-after.conf


Thanks
Monah

<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    Hello,<br>
    <br>
    The proper way would something like<br>
    <blockquote>SecRule REQUEST_HEADERS "@contains select" "...,chain"<br>
       SecRule MATCHED_VARS_NAMES @unconditionalMatch
      "ctl:ruleRemoveTargetById=942032;%{MATCHED_VAR}"<br>
    </blockquote>
    Unfortunately, ruleRemoveTargetById doesn't support macro expansion.<br>
    No solution for the moment I'm afraid.<br>
    <br>
    <div class="moz-cite-prefix">On 15/12/2024 04:05, Anant Mudambi via
      mod-security-users wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CALPdRR5W+ha6P=A1O...@ma...">
      <div dir="ltr">Hello,
        <div>Is it possible to write a rule exclusion that finds all
          headers that have a certain string in them and exclude only
          those headers in subsequent rule? Would something like this
          work?</div>
        <div><br>
        </div>
        <div>SecRule REQUEST_HEADERS "@contains select" "...,
          ctl:ruleRemoveTargetById=942032;%{MATCHED_VARS_NAMES}"</div>
        <div><br>
        </div>
        <div>Thanks,</div>
        <div>Anant</div>
      </div>
    </blockquote>
  </body>
</html>

Hi Anant,

On Sat, Dec 14, 2024 at 07:05:08PM -0800, Anant Mudambi via mod-security-users wrote:
> Hello,
> Is it possible to write a rule exclusion that finds all headers that have a
> certain string in them and exclude only those headers in subsequent rule?
> Would something like this work?
> 
> SecRule REQUEST_HEADERS "@contains select" "...,
> ctl:ruleRemoveTargetById=942032;%{MATCHED_VARS_NAMES}"

Unfortunately not, it's not possible.

Even though Apache allows this syntax (a note: you forget to add
the target to your exclusion, I mean the correct form would be
"...;ctl:ruleRemoveTargetById=942032;REQUEST_HEADERS:%{MATCHED_VARS_NAMES}"),
but when it evaluates it gets "%{MATCHED_VARS_NAMES}" as header
name, not the substituted value.

In case of Nginx its parser does not allow this syntax.


Regards,


a.

Hello,
Is it possible to write a rule exclusion that finds all headers that have a
certain string in them and exclude only those headers in subsequent rule?
Would something like this work?

SecRule REQUEST_HEADERS "@contains select" "...,
ctl:ruleRemoveTargetById=942032;%{MATCHED_VARS_NAMES}"

Thanks,
Anant