Re: [mod-security-users] SecRuleUpdateActionById
Brought to you by:
victorhora,
zimmerletw
Menu
▾
▴
Re: [mod-security-users] SecRuleUpdateActionById
|
From: Andrew H. <and...@ow...> - 2025-05-05 23:06:44
|
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/
|
