SecAuditEngine not working as expected

[sfc-gh-abhala]

Hi team, I have been trying to use coraza-proxy-wasm as part of our filter chain for envoy. I am using the version 0.5.0 , however I am not able to configure Audit Logs related ModSecurity directives properly. I am using the following configuration:
{ "plugin_config": { "directives_map": { "default": [ "SecRuleEngine DetectionOnly", "SecDebugLogLevel 3", "SecRequestBodyAccess Off", "SecResponseBodyAccess Off", "Include @crs-setup-conf", "Include @owasp_crs/*.conf", "SecAuditLogFormat JSON" ] }, "default_directives": "default" }, "wasm_path": "/coraza/coraza.wasm" }
This configuration does not talk anything about SecAuditEngine to be On neither in my configuration above nor in crs-setup-conf file and I see that in ModSecurity default value of SecAuditEngine is Off , but still I see Audit logs in the pod something like below:
[2024-12-12 21:24:39.286][80][critical][wasm] [source/extensions/common/wasm/context.cc:1204] wasm log coraza coraza coraza: [client "44.235.12.129"] Coraza: Warning. HTTP header is restricted by policy (/content-encoding/) [file "@owasp_crs/REQUEST-920-PROTOCOL-ENFORCEMENT.conf"] [line "2601"] [id "920450"] [rev ""] [msg "HTTP header is restricted by policy (/content-encoding/)"] [data "Restricted header detected: /content-encoding/"] [severity "critical"] [ver "OWASP_CRS/4.0.0-rc2"] [maturity "0"] [accuracy "0"] [tag "application-multi"] [tag "language-multi"] [tag "platform-multi"] [tag "attack-protocol"] [tag "paranoia-level/1"] [tag "OWASP_CRS"] [tag "capec/1000/210/272"] [tag "PCI/12.1"] [hostname "10.4.116.151"] [uri "/queries/v1/query-request?requestId=2efee4bd-538b-46af-9fac-4a67e9fc6554&request_guid=abdd03e6-a575-470f-a4ea-1d4218b0a67d"] [unique_id "ASxLbDiEhuzzKPpFkiT"][msg_match_1 "HTTP header is restricted by policy (:scheme)"] [data_match_1 "Restricted header detected: :scheme"][msg_match_2 "HTTP header is restricted by policy (authorization)"] [data_match_2 "Restricted header detected: authorization"][msg_match_3 "HTTP header is restricted by policy (x-forwarded-for)"] [data_match_3 "Restricted header detected: x-forwarded-for"][msg_match_4 "HTTP header is restricted by policy (:path)"] [data_match_4 "Restricted header detected: :path"][msg_match_5 "HTTP header is restricted by policy (content-encoding)"] [data_match_5 "Restricted header detected: content-encoding"][msg_match_6 "HTTP header is restricted by policy (accept)"] [data_match_6 "Restricted header detected: accept"][msg_match_7 "HTTP header is restricted by policy (x-forwarded-proto)"] [data_match_7 "Restricted header detected: x-forwarded-proto"][msg_match_8 "HTTP header is restricted by policy (x-request-id)"] [data_match_8 "Restricted header detected: x-request-id"][msg_match_9 "HTTP header is restricted by policy (:authority)"] [data_match_9 "Restricted header detected: :authority"][msg_match_10 "HTTP header is restricted by policy (:method)"] [data_match_10 "Restricted header detected: :method"][msg_match_11 "HTTP header is restricted by policy (content-length)"] [data_match_11 "Restricted header detected: content-length"][msg_match_12 "HTTP header is restricted by policy (x-envoy-external-address)"] [data_match_12 "Restricted header detected: x-envoy-external-address"][msg_match_13 "HTTP header is restricted by policy (content-type)"] [data_match_13 "Restricted header detected: content-type"][msg_match_14 "HTTP header is restricted by policy (user-agent)"] [data_match_14 "Restricted header detected: user-agent"][msg_match_15 "HTTP header is restricted by policy (accept-encoding)"] [data_match_15 "Restricted header detected: accept-encoding"]
I see that for the above rule here , there is no SecDefaultAction something like:
SecDefaultAction "phase:1,log,auditlog,pass"
then how it is being triggered to generate AuditLogs ?

I am trying to understand here how I can control logging, because here I am not sure what is triggering the SecAuditEngine to be On. I even tried to explicitly mention SecAuditEngine Off but still seeing the Audit logs being triggered.

Also I saw that the logs are not coming in JSON format but I saw that being fixed in this PR , is there a plan to release a new wasm module ? Otherwise we will have to pull the latest commit and build our own wasm module locally?

[amanbhala]

@anuraaga @jcchavezs @M4tteoP

[M4tteoP]

Hi, the log you are showing is a debug/error log, not an audit one. It is the output generated by a single rule (920450) that matched multiple times. You can tweak their verbosity via SecDebugLogLevel.
Audit logs come with more details of the whole transaction, and are not working in version 0.5.0. To have an idea of how they look like, you can look at the line that comes with AuditLog:{"transaction":... in this comment. To have them working, as you correctly said, (note: they will be printed alongside any other envoy log line, just with the AuditLog: prefix in front), you have to pull a recent commit and build the module from there, not relying on the 0.5.0 tag.

[sfc-gh-abhala]

@M4tteoP thanks for the info. Is there a plan to release a new wasm version given that there are all these changes and the last release happened in January,24 ? This would be great for us as we don't have to build the wasm module ourselves when building our image locally.