Add Support for WAF

[danehans]

Description:

Add WAF support. The implementation should focus on coraza-proxy-wasm but allow other WAF solutions in the future.

• Create a design doc for the user-facing API. See Add authn policy design with JWT only #529 (draft) as an example.
• Update xds IR.
• Update the Kube provider to reconcile the WAF Custom Resource.
• Update the resource translator to translate the WAF Custom Resource into IRs.
• Update the xds translator to translate the xds IR into xds APIs, e.g. ECDS.
• Add a user-facing doc and link into Sphinx docs, e.g. user_docs.rst.
• Others?

This issue depends on #71 and/or #24.

[nacx]

The coraza-proxy-wasm project leverages the coraza library via WASM so that it can be used in plain Envoy sidecars and gateways. Since Envoy Gateway is already written in Go, support for WAF could be native using directly the Coraza library without the need for the WASM module.

[danehans]

@nacx thanks for providing input on this issue. To make sure I understand your comment, are you suggesting that this feature be implemented as an ExternalProcessor filter instead of a Wasm filter?

[nacx]

My bad. I was mixing the runtime with the control plane, so the suggestion won't apply beyond the fact that coraza is fully written in go and that the project could leverage that, if needed. But at runtime, the wasm module should be the way to go.

[arkodg]

this issue shouldnt depend on #71, both the issues are orthogonal, #71 is about exposing a user facing API for WASM, this issue might use WASM which is an internal implementation detail

[Xunzhuo]

this issue shouldnt depend on #71, both the issues are orthogonal, #71 is about exposing a user facing API for WASM, this issue might use WASM which is an internal implementation detail

Yes, I am willing to design and implement #71 and this issue, since I am familiar with proxy-wasm. But not sure for the issues priorities, maybe this can be done in v0.3.0, but I can not promise this, this depends on the status of issues I already assigned in v0.3.0 and the priority of wasm extension support.

[anuraaga]

Hi all - copying some points from the email thread on this.

It can be useful to align with OWASP as there is a large ecosystem and a lot of history there in applying WAF for compliance such as with payment processing. Coraza is an implementation of OWASP that fully supports its coreruleset and configuration language. It has made Envoy support a priority, accepting changes for building to Wasm with TinyGo and including a TinyGo-based build in CI to prevent regressions when integrated to Envoy.

We will be doing more scientific analysis of coraza-proxy-wasm's performance in the next couple of weeks - for now, we see unscientific numbers of ~3ms of overhead for requests with small payloads. It will be important to get distributions correlated with payload size, and a comparison of WAF via coraza directly in a Go server vs using wasm middleware. Will followup here when having some more useful numbers.

If going with wasm, though, we need to get the wasm support itself in Envoy out of alpha state and need to understand what is required for that and the staffing for it.

[zhshw]

@danehans hi brother, start this plan. write the design document first. Let's implement it together

[danehans]

Let's first get v0.3 released and then review the backlog, prioritize issues, understand capacity, etc. as part of v0.4 planning.

[zhshw]

Using WASM to implement WAF may require attention to the performance of buffer copy. This is not Zero-copy network I/O, Benckmark is required

Other:

• Using Native mode
• Some HTTP rules are pushed to the firewall of EBPF

[jcchavezs]

Using WASM to implement WAF may require attention to the performance of buffer copy. This is not Zero-copy network I/O, Benckmark is required

While this is true, CRS based solution for WAF (current industry standard) does not rely on copying intensive amount of bytes to the buffer, in fact, CRS encourages to limit the body analysis to a limit which is good enough to accept/discard a request (see https://github.com/corazawaf/coraza/blob/v3/dev/coraza.conf-recommended#L44). In addition to that, in WASM you usually optimize the memory bouncing from host to guest and viceversa and do earlye valuations (e.g. of body payload) to avoid unnecessary copies (see for example https://github.com/corazawaf/coraza-proxy-wasm/pull/131/files#diff-f0f28df9e4cde667685c065052f983c9c3f46861be7762bd142174e9ffca5c3fR16-R19). Finally you don't inspect all the payloads but a certain number of mimetypes instead.

In any case, I am up for benchmarking of WASM solutions like coraza and also would discard any solution that would involve custom envoy builds (like tailoring a specific filter) as it is a burden of maintenance.

[jcchavezs]

Some news on this: @intel has been working together with @corazawaf team to improve performance and reduce memory consumption in coraza-proxy-wasm. You can see a detailed thread on performance findings and improvements https://owasp.slack.com/archives/C02BXH135AT/p1677616370248079. There still room for performance improvement and this has been our focus on the last months (see https://github.com/corazawaf/coraza/pulls?q=is%3Apr+%28performance+OR+memory%29+is%3Aclosed+)

[arkodg]

thats great news @jcchavezs, thanks for the update on the work !
while coraza-proxy-wasm undergoes perf improvements, it would be great to start ideating on

• what would the end user WAF API would look like
• which persona will configure the WAF - Infra Admin or App Dev
• Above q will help answer which extension to use -
  • If Infra Admin, this will most likely be a Direct Policy Attachment resources on the Gateway
  • If App Dev, this could be an Extension Filter

Currently with nginx ingress annotations you can

• enable-modsecurity: "true"
• enable-owasp-modsecurity-crs: "true"

[jcchavezs]

what would the end user WAF API would look like

I think the config that would work for 9x% of the cases would be

rules: 
  -Include @owasp_crs/*.conf

to enable entire coreruleset but also allows user to pass custom configs.

which persona will configure the WAF - Infra Admin or App Dev

Usually it is infra admin as such policies are enabled globally (e.g. for PCI compliance), also because this does not belong to the app dev domain as security enforcements in the app domain happens at code level.

Currently with nginx ingress annotations you can

Infra Admins are used to deal with modsec rules, having booleans for modsecurity sounds very restrictive, settings like SecRuleEngine, SecDebugLogLevel or simply the ability of leveraging custom rules (imagine log4shell network patching before it was release in CRS) cannot be done with such restrictive settings. Moreso, nginx setup expects the config to be taylored in a file which isn't trivial to distribute.

[github-actions]

This issue has been automatically marked as stale because it has not had activity in the last 30 days.

[siegenthalerroger]

Pretty sure this is still relevant.

[github-actions]

This issue has been automatically marked as stale because it has not had activity in the last 30 days.

[siegenthalerroger]

Pretty sure this is still relevant.

[github-actions]

This issue has been automatically marked as stale because it has not had activity in the last 30 days.

[avthart]

Still relevant

[github-actions]

This issue has been automatically marked as stale because it has not had activity in the last 30 days.

[nacx]

Still relevant

[UXabre]

Is there any status update on this? Would really like to see this fly. I see that some people have proposed to help, if somebody has done some work but haven't gotten around, perhaps we can help to get this back up the rails?

I fear this message will be lost to the endless gh bot messages but just wanted to offer help in this as indeed....still verry much relevant

[zirain]

@jcchavezs are you still around this?
@UXabre are you interesting on taking this?

[arkodg]

a good start would be to add an integration doc highlighting how a WAF like Coraza can be integrated into Envoy Gateway using extension points ( WASM, ext_proc, etc )

[UXabre]

ok cool, I have read some pointers online on how to possible get this, now I'll have to deep dive in Envoy Gateway internals as well to understand where to potential integration points lie next to reading up on the proposals above on how to configure this thing.

To be continued

[github-actions]

This issue has been automatically marked as stale because it has not had activity in the last 30 days.

[pdefreitas]

Still relevant

[github-actions]

This issue has been automatically marked as stale because it has not had activity in the last 30 days.

[foosinn]

Hey,

i gave it a quick try and it actually seems to work:

---
apiVersion: gateway.envoyproxy.io/v1alpha1
kind: EnvoyExtensionPolicy
metadata:
  name: waf
spec:
  targetRefs:
    - name: default
      group: gateway.networking.k8s.io
      kind: Gateway
  wasm:
    - name: wasm-filter
      failOpen: false
      rootID: waf
      code:
        type: Image
        image:
          url: ghcr.io/corazawaf/coraza-proxy-wasm:0.5.0
      config:
        default_directives: default
        directives_map:
          default:
            [
              "SecDebugLogLevel 9",
              "SecRuleEngine On",
              "Include @crs-setup-conf",
              "Include @owasp_crs/*.conf",
            ]

[github-actions]

This issue has been automatically marked as stale because it has not had activity in the last 30 days.