2 ms·

This sounds like ModSecurity - AWS style. The problem with WAF has always been ensuring you have a good ruleset. You need to be extremely careful with aggressiv

This sounds like ModSecurity - AWS style. The problem with WAF has always been ensuring you have a good ruleset. You need to be extremely careful with aggressive rules or you can break your application in area's you don't expect. It takes lots and lots of trial and error writing out a safe ruleset that doesn't break stuff. I wonder what the cycle would look like trying to get this right on AWS? One area I can see this being used for my purposes right now is to limit URL patterns down to IP restrictions for /admin type area's on a web app. This means this can be done A) Outside of app source code and B) without having to do any fancy reverse proxy work and setup of subdomains.

deleted 11y ago
[deleted]
lotyrin 11y ago
Yeah, and if I'm adding WAF to my application, I'd want it to be something I can run on a developer's laptop for fast iteration cycles -- Vagrant up, change WAF rules, run the integration suite. If the WAF is up in the cloud, I guess I have to wait until staging the code to see if something legitimate gets snared by the WAF?
- dogma1138 11y ago
  You can always run a reverse proxy in AWS behind a WAF that then points back to your development machine, it's a complicated solution but it's not new. If you host your servers internally and you are big organization you have WAF's/Application Firewalls, IPS/IDS, and possibility a DB FW like imperva as well. Does this lead to issues with deployments? yes, but it doesn't affect your code, if the WAF breaks you application 9/10 unless you use something silly like SQL queries in the URL (yes this has been seen before...) it's up to your security team to adjust the rule set during the pre-prod testing.
rmdoss 11y ago
A good and well researched ruleset is 99% of the WAF solution. Being able to create rules is interesting, but doesn't make it a WAF that can compete with ModSecurity, Sucuri, Barracuda and others. These products have serious research and testing behind their WAF products to cover a large variety of attacks (SQLi, XSS, virtual patching, etc, etc). But it is kind nice to be able to filter traffic based on the HTTP payloads, instead of just the IPs/tcp ports like before.
deleted 11y ago
[deleted]

deleted 11y ago

[deleted]

lotyrin 11y ago

Yeah, and if I'm adding WAF to my application, I'd want it to be something I can run on a developer's laptop for fast iteration cycles -- Vagrant up, change WAF rules, run the integration suite. If the WAF is up in the cloud, I guess I have to wait until staging the code to see if something legitimate gets snared by the WAF?

dogma1138 11y ago
You can always run a reverse proxy in AWS behind a WAF that then points back to your development machine, it's a complicated solution but it's not new. If you host your servers internally and you are big organization you have WAF's/Application Firewalls, IPS/IDS, and possibility a DB FW like imperva as well. Does this lead to issues with deployments? yes, but it doesn't affect your code, if the WAF breaks you application 9/10 unless you use something silly like SQL queries in the URL (yes this has been seen before...) it's up to your security team to adjust the rule set during the pre-prod testing.

rmdoss 11y ago

A good and well researched ruleset is 99% of the WAF solution. Being able to create rules is interesting, but doesn't make it a WAF that can compete with ModSecurity, Sucuri, Barracuda and others. These products have serious research and testing behind their WAF products to cover a large variety of attacks (SQLi, XSS, virtual patching, etc, etc). But it is kind nice to be able to filter traffic based on the HTTP payloads, instead of just the IPs/tcp ports like before.

deleted 11y ago

[deleted]