-
Notifications
You must be signed in to change notification settings - Fork 4.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Holistic approach to WAF #7918
Comments
Sorry for the long delay. At a high level this LGTM. My preference would be to start with a config proto only PR and we can discuss further there? |
envoyproxy#7918 Signed-off-by: Prakasam Kannan <[email protected]>
@mattklein123 Is there any progress being made on this? The PR seems to have staled out. We could use WAF in our ingress deployment and would be wiling to contribute. |
None that I know of. I think the folks at Reblaze/Curiefense are still theoretically working on this but I haven't seen any traction. Basically I would like to just do a filter that relies on generic matching that can apply various WAF like actions (tar pit, etc.). |
Stopping by to say that It would be great if there was a native filter implementation for WAF ! |
I'm in favor of the OWASP approach now that I have learned more about it. My main concerns involve the reliance on WASM due to:
We will need to reconcile both of the above moving forward. |
In the wake of the recent CVEs, it's become more clear that we need a holistic approach to WAF, primarily allowing for both blocking, blackholing, etc. both L4 and L7 traffic based on various input parameters.
We have various bits and pieces of this today including RBAC, IP tagging, but we need to look through the type of blocking actions that users want to perform and likely build explicit L4 and L7 WAF filters. We also need to think about how these filters would be dynamically populated with block rules via config, streaming API, etc.
The text was updated successfully, but these errors were encountered: