projectcontour
Add ModSecurity CRS support
In order to implement a production grade ingress controller in many organizations, security mandates that a WAF be placed in front of applications to prevent poorly written web applications from being exploited easily. Currently, a few projects in the ingress ecosystem implement modsecurity's CRS as a WAF to solve for this purpose. One of these is Nginx , other vendors like gloo hide this functionality behind a licensed toolset.
This feature request is to implement a basic functionality of the ModSecurity CRS as third party add on.
https://modsecurity.org
To add to this, it looks like there might be an implementation by a third party on envoy, though I've never looked into the code, or used it in any capacity.
@z0r0 thank you for your issue. I think my knowledge is very out of date, when you say mod security I think of the apache module. Can you please tell me more about the mod security product. Thanks
It's really just a library for parsing requests against a ruleset. It's most commonly known as a module that was loaded with apache, but there's implementations within nginx, envoy (apparently) apache, and possibly even native python bindings looking at the github pages of the CRS maintainers, Spiderlabs.
Basically, it's a parsing engine, and a ruleset to make sure that a given http request doesn't violate the thresholds for any of the rules. To see the rules and how they work, you could take a look at the ruleset, here
Thank you for your reply.
At the moment we rely on upstream envoy to provide the docker image which we reference in our manifests. At the moment we don’t have the bandwidth to take on the responsibility of delivering envoy directly so until this mod security work is available upstream it’s unlikely we would add the plumbing to expose this via envoy.
Totally understood. Would there be the possibility to implement this as functionality similar to how the ext_authz functionality works? see here The functionality is relatively similar in that the logic could simply be to forward to a third party service and to respond to the request appropriately.
I think that the difference being that depending on the implementation of the authz filter, stacking those filters could be a configuration problem.
That’s a possibility, I think there is an issue for that method somewhere in the backlog. This would make the mod security service a critical component of contour so we’d want to approach how we exposed that to HTTPProxy authors in a way that didn’t incur and undue support overhead.
On 27 Nov 2019, at 13:28, Ian Abreu [email protected] wrote:
Totally understood. Would there be the possibility to implement this as functionality similar to how the ext_authz functionality works? see here The functionality is relatively similar in that the logic could simply be to forward to a third party service and to respond to the request appropriately.
I think that the difference being that depending on the implementation of the authz filter, stacking those filters could be a configuration problem.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.
Awesome. let me know if/how I can help if this gets picked up. It's been a while since I've implemented ModSecurity out of the box, but it's the easiest of the WAF products to get working, and has the widest support base.
I'm also willing to contribute time here, though my golang experience is near non-existent.
Thank you. I've assigned this issue to the backlog for prioritisation by our PM.