Open tzuryby opened 1 year ago
cc @snowp
I am not sure if it's good choice to implement WAF by the generic matching. The generic matching is complex enough for now. Will it be better if we implement it as a independent filter?
But we are open to this question. A more detailed proposol would be welcome.
@wbpcode thanks for your feedback.
The suggestion to this path (basic WAF implemented on top of generic matching) was actually made by @mattklein123.
We will indeed come with a more detailed proposal soon. Meanwhile, this PR, which has some feedback, is in motion.
I am not sure if it's good choice to implement WAF by the generic matching. The generic matching is complex enough for now. Will it be better if we implement it as a independent filter?
The idea is to build a WAF filter where the actions are WAF actions specific to that filter. But for matching I think it's fine to have matching on other types of things which is also relevant to other parts of Envoy?
FYI https://github.com/envoyproxy/envoy/pull/24627 should be close to be merged for "Query string args"
The Ability to Parse Args Is Essential for a WAF
We, Curiefense maintainers, willing to extend Generic Matching so it can act as de-facto Native WAF for Envoy users.
The vision is simple: Curiefense users will be able to activate the security policy in a given runnign environemtn, using generic-matching, since the rules will be renderd as such.
We have work on a PoC that already has the capabilitied to do so (attached yaml), yet, without the ability to parse and match entries in the queryString and request body, the WAF cannot be considered useful.
The table below describe the current capabilities and the missing ones, and tagged them with their priority (P1..P4)
Capabilities map
So far, we have added support for the following Curiefense policy generation
Curiefense team involved: