-
Notifications
You must be signed in to change notification settings - Fork 50
[RFC] Web Application Firewall #206
Comments
That's a hard question, I already though many times about this topic. At first, I wanted to explore the possibilities to have firewall for all expose ports at the Docker level, so we can control access to applications themselves. But I'm not sure this is possible if the firewall is in a container (or maybe with a privileged or pid=host container ?), and I really don't want to install a firewall in the node itself. You suggest firewall in the proxy, I didn't though about that but I believe this is an excellent idea. This is the easiest way to control access to all web applications and Clouder is mostly designed toward them. The way I see it, we should have a firewall, in a container, with a web access so non-technical people can easily administer and grant access, which can control access to containers exposed ports, and url forwarded by the proxy. I do believe I'm asking too much... |
We're actually talking about two different types of firewalls here, although I agree on the need for the other too. Honestly I've been able to make IpTables meet all my needs for port/IP based rules with proper config. Interestingly enough, I also made a ghetto web UI for the managing of IP Tables rules in some disparate routers which I could probably adapt for us fairly easily. What I'm referring to is a Web Application Firewall. This sits in front of HTTP applications & packet sniffs in order to provide an extra layer of security. This is to circumvent active exploit attempts such as SQL Injection probing, XSS, RCE, RFI, protocol violations, etc. ModSecurity implements all of OWASP's Core Rule sets, which are described here and here in more detail. |
Oh ok I understand better now. As a first step, I believe we shall keep it simple and implement it at the proxy level then. |
Step at a time! I'll toss this on our internal dev board, we should see some code soon 😄 |
Any thoughts on whether this should be an option or just built in (mandatory)? |
Hum good question... For now I'd say built in, let's keep it simple we'll see later if the need arise for insecure. |
Another nail in the security shield for us should be a Web Application Firewall.
I'm thinking something like ModSecurity built as a module & included into our proxy would be the best bet here.
Alternatively we could run the firewall as its own service, and proxy desired traffic through it.
Benefits of the former method is security by default, for everything. Downfall is that opt-out would be at the proxy image level, so you're either fully secure or fully insecure - no middle ground.
If we go the route of the secondary proxy, we would gain the benefit of opt-in/out security at the application level. The downfall of this method is that our network architecture will explode in terms of difficulty. We also still wouldn't be able to run secure & insecure on the same port - because the two proxy listeners would conflict.
Thoughts? Other techs/strategies?
cc @LasLabs @YannickB
The text was updated successfully, but these errors were encountered: