How to log in Anomaly Scoring mode + change the default http status 403 ??

[johan fillon]

Hello everybody,

I'm currently setting up modsecurity-crs in a kubernetes environment.
I'm currently using the docker image modsecurity-crs:3.3-nginx on our development version with paranoya level 1 and the following settings :

SecRuleEngine DetectionOnly
SecAuditEngine RelevantOnly
SecAuditLogRelevantStatus "^(?:5|4(?!04))"
SecAuditLogParts ABCDEFGHIJKZ # log all parts
SecAuditLogType HTTPS # logger https
SecAuditLog http://x.x.x.x:x# URL logstash

my crs-setup.conf is like this

SecDefaultAction "phase:1,log,auditlog,pass"
SecDefaultAction "phase:2,log,auditlog,pass"
SecAction "id:900200,phase:1,nolog,pass,t:none,setvar:'tx.allowed_methods=GET HEAD POST OPTIONS PATCH DELETE'"
SecAction "id:900230,phase:1,nolog,pass,t:none,setvar:'tx.allowed_http_versions=HTTP/1.0 HTTP/1.1 HTTP/2 HTTP/2.0'"
SecCollectionTimeout 600

This configuration works well, I receive the logs of false positives in my ELK without blocking requests.

If I contact you it's on two points that I can't get it to work:
1-activate the blocking in Anomaly scoring mode while keeping the logs in the ELK.
2-block with HTTP status 412 instead of 403

1-In the current configuration when I modify SecRuleEngine DetectionOnly to SecRuleEngine On, the blocking becomes effective and bad requests fall in 403, but I have no more log transmitted to my ELK and if I try to log with these parameters

SecAuditLogType Serial
SecAuditLogFormat JSON
SecAuditLog /var/log/modsec_audit.log

it's the same the file is never fed and remains empty.
Have you ever encountered this problem? Is it a configuration error?

2-For the second point where I wish to block by falling in 412 I modify the file RESPONSE-999-EXCLUSION-RULES-AFTER-CRS.conf that I deposit in directory rules with the following configuration :

SecRuleUpdateActionById 949110 "t:none,deny,log,auditlog,status:412"
SecRuleUpdateActionById 959100 "t:none,deny,log,auditlog,status:412"

Queries seem to be correctly blocked with a 412 status, but since I don't have a log, I can't check on I'm still in Anomaly Scoring mode.
Is this the right way to change the failure status for all requests blocked by ModSecurity-CRS?

I hope I'm in the right place to ask my questions

Thank you in advance for the people who will take the time to read me
Have a nice day.
Johan

Translated with www.DeepL.com/Translator (free version)

[Ruben van Vreeland]

Hi Johan,

I might be able to guide you in the right direction.

1: nolog is specified in your rule. This disables logging.

2. I don't see your CRS configuration in full, but in your crs-setup.conf you should have the following directive: SecDefaultAction "phase:1,log,auditlog,deny,status:403"

Hope this helps! 

Op di 28 jul. 2020 om 10:59 schreef johan fillon <johan....@gmail.com>:

--
You received this message because you are subscribed to the Google Groups "ModSecurity Core Rule Set project" group.
To unsubscribe from this group and stop receiving emails from it, send an email to modsecurity-core-rule-...@owasp.org.
To view this discussion on the web visit https://groups.google.com/a/owasp.org/d/msgid/modsecurity-core-rule-set-project/a545b291-61c9-49e2-9a20-6fa884bbd932o%40owasp.org.

[johan fillon]

Hello Ruben, thanks for your answer.

Having a nolog in my configuration on the lines

SecAction "id:900200,phase:1,nolog,pass,t:none,setvar:'tx.allowed_methods=GET HEAD PATCH OPTIONS DELETE'"

SecAction "id:900230,phase:1,nolog,pass,t:none,setvar:'tx.allowed_http_versions=HTTP/1.0 HTTP/1.1 HTTP/2 HTTP/2.0'"

seems normal because I do not want to log these two actions which are not rules, but definitions of variables.

my full crs-setup.conf is :

# Anomaly scoring mode
SecDefaultAction "phase:1,nolog,auditlog,pass"
SecDefaultAction "phase:2,nolog,auditlog,pass"

SecAction "id:900200,phase:1,nolog,pass,t:none,setvar:'tx.allowed_methods=GET HEAD POST OPTIONS PATCH DELETE'"
SecAction "id:900230,phase:1,nolog,pass,t:none,setvar:'tx.allowed_http_versions=HTTP/1.0 HTTP/1.1 HTTP/2 HTTP/2.0'"
SecCollectionTimeout 600

SecAction "id:900990,phase:1,nolog,pass,t:none,setvar:tx.crs_setup_version=330"
SecAction "id:900000,phase:1,nolog,pass,t:none,setvar:tx.paranoia_level=1"
SecAction "id:900100,phase:1,nolog,pass,t:none,setvar:tx.critical_anomaly_score=5,setvar:tx.error_anomaly_score=4,setvar:tx.warning_anomaly_score=3,setvar:tx.notice_anomaly_score=2"
SecAction "id:900110,phase:1,nolog,pass,t:none,setvar:tx.inbound_anomaly_score_threshold=5,setvar:tx.outbound_anomaly_score_threshold=5"

I got a good look at your idea of setting default actions:
SecDefaultAction "phase:1,log,auditlog,deny,status:403"

but according to the documentation (https://www.modsecurity.org/CRS/Documentation/anomaly.html) if I apply these settings I am no longer in Anomaly scoring mode and I would then be in Traditional Detection mode which is not the desired operation.

In fact I want to log only the requests that are blocked by the waf according to an error code (parameter SecAuditEngine RelevantOnly and SecAuditLogRelevantStatus) and get all the rules that allowed to reach the threshold.

As quoted in the documentation I tried to update the rules that perform blocking after reaching the threshold this way:
SecRuleUpdateActionById 949110 "t:none,log,auditlog,deny,status:412"
SecRuleUpdateActionById 959100 "t:none,log,auditlog,deny,status:412"

In this case the requests are correctly blocked with a 412 code, but no log is transmitted on this block, it seems that the auditlog parameter which refers to my ELK is not taken into account.

Sincerely, Johan

Le mardi 28 juillet 2020 20:56:17 UTC+2, Ruben van Vreeland a écrit :

Hi Johan,

I might be able to guide you in the right direction.

1: nolog is specified in your rule. This disables logging.

2. I don't see your CRS configuration in full, but in your crs-setup.conf you should have the following directive: SecDefaultAction "phase:1,log,auditlog,deny,status:403"

Hope this helps! 

Op di 28 jul. 2020 om 10:59 schreef johan fillon <johan...@gmail.com>:

To unsubscribe from this group and stop receiving emails from it, send an email to modsecurity-core-rule-set-project+u...@owasp.org.