Re: [mod-security-users] SecRuleUpdateActionById

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

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