questions about WAF detection only mode

[zufardhiyaulhaq]

In most WAF implementations, we can set up monitor-only or count-only mode while still allowing access to the upstream services.

This stage is one of the important steps when rollouts WAF, at least in my company.

I see that in Coraza, we can use https://coraza.io/docs/seclang/directives/#secruleengine to DetectionOnly

I have 2 queries:

are there any good resources to understand the order of directives?

"SecDebugLogLevel 9",
"SecRuleEngine On",
"Include @crs-setup-demo-conf",
"Include @owasp_crs/REQUEST-901-INITIALIZATION.conf"

what if SecRuleEngine is already in @crs-setup-demo-conf?

is coraza-proxy-wasm already support detectionOnly mode? in plugins.go, it's only checking if SecRuleEngine is off, there are no mechanism to detect if it's DetectionOnly.

coraza-proxy-wasm/wasmplugin/plugin.go

Line 237 in fe78932

if tx.IsRuleEngineOff() {

[M4tteoP]

Hi!

What if SecRuleEngine is already in @crs-setup-demo-conf?

The latest directive occurrence will be enforced. So, if @crs-setup-demo-conf would contain a SecRuleEngine the previous SecRuleEngine On would be not effective. This is not the case because crs-setup-demo-conf is meant to configure CRS-specific settings, main Engine settings like SecRuleEngine are part of coraza.conf (E.g. https://github.com/corazawaf/coraza-proxy-wasm/blob/main/wasmplugin/rules/coraza.conf-recommended.conf#L3-L7).
I will follow up soon with a PR with more clarity around conf and conf aliases.

is coraza-proxy-wasm already support detectionOnly mode?

Yes, definitely. Running with detectionOnly mode leads to not enforcing disruptive actions, but still performing all the checks and logging.

in plugins.go, it's only checking if SecRuleEngine is off, there are no mechanism to detect if it's DetectionOnly.

detectionOnly mode is a configuration that is propagated to the Coraza Engine. It will enforce this behavior, not returning interruptions. This logic is transparent to the connector, therefore in plugins.go there is currently no need to explicitly enforce some actions based on DetectionOnly, everything is already done under the hood by Coraza.

[zufardhiyaulhaq]

I already test today and seems DetectionOnly works.
seems like we just missing the metrics

[jcchavezs]

@zufardhiyaulhaq could you elaborate a bit more on this?

seems like we just missing the metrics

[zufardhiyaulhaq]

@jcchavezs currently there are no metrics that indicate this is detection only mode, not really sure if we need this though.

[zufardhiyaulhaq]

@jcchavezs I am more concerning that the log output from envoy is hard to parse.

[jcchavezs]

We have metrics in place https://github.com/corazawaf/coraza-proxy-wasm#waf-metrics and they work the same both in On and DetectionOnly, I am not sure we want to differentiate. Please do check if those metrics are good enough otherwise we can add more. About logs, currently in proxy-wasm we output the audit logs in stdout but we always thought we should be able to forward them and now we have the right API for that so I am up to listen to use cases.

[github-actions]

This issue has been open 30 days waiting for feedback. Remove the stale label or comment, or this will be closed in 14 days.

[github-actions]

This issue was closed because it has been inactive for 14 days since being marked as stale.

[srinivasbandgi-ds]

Can we re-open this issue ?
waf_filter_tx_interruptions metrics are published only when SecRuleEngine On is set. We don't see any metric in case of SecRuleEngine DetectionOnly where it would have blocked so many requests.

[jcchavezs]

Totally also this is linked to corazawaf/coraza#1008 as we only can access this metrics if the interruption is being raised.

[github-actions]

This issue has been open 30 days waiting for feedback. Remove the stale label or comment, or this will be closed in 14 days.

[github-actions]

This issue was closed because it has been inactive for 14 days since being marked as stale.