In general, I'm not a huge fan of using WAFs to protect web applications -- I've spent too much of my career bypassing WAFs to have a lot of confidence in them. That said, using a WAF can hugely improve application security visibility, if not increase actual resilience.
The AWS WAF is, presumably, going to give application developers and owners significantly more insight into whether their apps are getting attacked. Congratulations to the Amazon team for shipping something that has the potential to make a really big difference.
At this point, my only question is why Amazon didn't give it a strange name (like most of the other AWS products)!
From the defensive side, WAFs can be quite helpful for alerting. It's detection, typically not prevention (against a dedicated attacker at least), but it helps.
I've seen attack traffic on machines within 30 minutes of adding an IP address to a domains DNS records. Before the web server was even up to record the we attempts, it was being hit with ssh brute force attempts.
I wish AWS would stop launching new services, and spend some time improving the usability and features of their existing services. So many of their products feel half finished, and could be so much better if they invested more time in improving them rather than trying to compete with every cloud service out there.
A lot of Amazon services seem to be "improved" by reducing prices (so, better hardware or technology underneath the hood).
But I entirely agree; it's a good time for Amazon to look at the suite of products and make them a tad more cohesive. It can be a bit disjointed at times, especially when trying to tie multiple services together.
I wonder if the drivers are:
* Culture of always having to be seen to innovate
* (Percieved) Competition to keep launching new features to stay ahead
With that said there have been improvements; for example EFS building on top of EBS.
The price drop that really gets me is EBS snapshot pricing. It's 3x the cost of the S3 storage that it is built upon, and it didn't used to be.
This, combined with the dearth of reasonably priced instances with large on-instance storage, artificially inflates our bills to the point that we're seriously considering abandoning AWS. just EBS snapshots are a full percent of our revenue.
My biggest gripe with snapshots is there is no actual way to see how much each snapshot consumes in S3. There is no Cloudwatch metric or any other way to see per snapshot or even per volume.
Sure, there is a billing per region but that's just not granular enough.
And we had snapshots for how many years?
As for the price, when did it more than tripled? I don't remember any blog or tweet or any other announcement. Anybody got a link?
The lack of visibility into per-snapshot cost is insane. We had a problem with the old deduplication process that meant that identically timed snapshots for identical servers with identical data could sometimes cost more than 2x the others. We only found this because we happened to have more the expensive volumes in one region than the others, so our snapshot bill was mysteriously $10k/month higher in that region.
We have essentially no idea how much many of our backups actually cost.
The price didn't triple, what happened was they dropped S3 pricing substantially but never dropped snapshot pricing, even though it's based on S3.
I'm just hoping for NFS 4.1 support so that I can start using it on my Windows Server 2012R2 instances. Currently, EFS uses NFS 4.0 which is incompatible with NFS 4.1 for some reason. :(
I would like Amazon to keep introducing third-gen cloud services like Lambda and API Gateway.
Polishing up stuff like EC2 to make DevOps easier is great. Creating things like Lambda to make NoOps possible is better, and the two activities should not be mutually exclusive.
Looks like this should have really been Cloudfront feature instead of it's own service. It only works with Cloudfront after all. Is that so it does not appear like a "price increase of Cloudfront"?
Is there any indication that it is?
From WAF doc: "AWS WAF is a web application firewall that lets you monitor the HTTP and HTTPS requests that are
forwarded to Amazon CloudFront and lets you control access to your content. Based on conditions that
you specify, such as the IP addresses that requests originate from or the values of query strings, CloudFront
responds to requests either with the requested content or with an HTTP 403 status code (Forbidden).
You can also configure CloudFront to return a custom error page when a request is blocked."
Now any of those talented people and teams can productize that valuable knowledge and deploy it on Amazon's infrastructure, rather than only the couple dozen people that can get jobs at Cloudflare/Sucuri/etc. They've just been handed a huge market of potential customers that have access to a WAF but don't have the expertise to develop rulesets of their own.
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.
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?
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.
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.
It would be really nice if this were integrated directly with ELB and/or API Gateway. The CloudFront requirement makes it quite expensive - especially for people using custom SSL certificates (without resorting to SNI).
CloudFront (or any CDN) is great for serving static/cached content, but for the kind of services WAF is designed to help protect, it wouldn't make a lot of sense to use CloudFront (apart from WAF) as it would just be passing the requests through to another load balancer/server.
With AWS WAF you pay only for what you use. AWS WAF pricing is based on how many rules you deploy and how many web requests your web application receives. There are no minimum fees and no upfront commitments.
Does this mean the amount would increase exponentially during a DDOS attack? Could I sink my theoretical competitor into bankruptcy if I know they are an AWS WAF client simply by DDOSing them?
A site on AWS is already paying per-request or per-GB for instance count, load balancing, data transfer, etc. Adding the WAF would reduce the cost of a DDOS by discarding requests at the edge, before they can generate additional compute, IO and data transfer costs for your backend.
Let's say someone with a botnet is downloading a 5MB file from your server a million times a day. The WAF rule to block those requests would cost you $1 + (1 * $0.60 per million requests) = $1.60. The data transfer if you don't block those requests would cost $450. You save $448.40 per day, or 99.6%, on just the data transfer.
> Does this mean the amount would increase exponentially during a DDOS attack? Could I sink my theoretical competitor into bankruptcy if I know they are an AWS WAF client simply by DDOSing them?
One call to Amazon and they'll forgive the bill. More attempts at DDOS Amazon services would likely trigger FBI investigation.
that's only prevention.
If you need more they will raise it to a lot. currently AWS SMS has a really low email sending limit too, like 5mails/s however if you ask for a raise they raise that too something like 100.000mails/s.
That thousands separator notation is ambiguous when communicating outside of a country that uses it as a standard[1]. You mean 100k mails/s, I think? Using a SI prefix like that is the easiest way to deal with it, or thinsp (u+2009) seems to be the international standard for digit group separation.
edit: regarding the disagreement over "only a handful" in a reply: that map is showing the separator between units and fractional part I think, not the thousands/millions/etc grouping separator.
yeah, sorry. I just forgotten about it.
currently I work so much with the german thousand seperators that I totally forgotten about the other standards.
currently i use scala's bigdecimal library which handles these things really great.
While before I used python where I sometimes needed to manually convert between them.
but you are right I shouldn't use anything like that in a global forum.
The convention for digit group separators varies but usually seeks to distinguish the delimiter from the decimal mark. Typically, English-speaking countries employ commas as the delimiter—10,000—and other European countries employ periods or spaces: 10.000 or 10 000. Because of the confusion that can result in international documents, the superseded SI/ISO 31-0 standard advocates the use of spaces and the International Bureau of Weights and Measures and International Union of Pure and Applied Chemistry advocate the use of a "thin space" in "groups of three".
Yeah that sounds comparatively exorbitant to me. It's not exactly "only pay for what you use" in the sense they normally apply it. I was expecting $0.0000x per request or something...
Besides the service interface side, how does this compare to something like an F5, baracuda or the IBM ISAM WAF?
Does it target layer 7, packet filtering, ssl termination or tie in with the identity service?
Any comparisons in functionality to some of the existing options would be interesting, anyone have any good links?
Who needs WAF with basic, static rules in 2015 when applications are deployed several times a day? Mod_security in a cloud? Well. Be ready to get a dedicated person to support it to avoid false positives. And I guess it's still easy to by-pass.
I don't have a lot of experience with WAFs in production - if I already use Nginx in front of my applications with appropriate rules and filters (which in turn feeds into graphite and Nagios), what more would the WAF buy me?
I think nothing. The main benefit would be that you don't need to maintain Graphite and Nagios, you can just set your rules and trust Cloudwatch to work.
When you say nginx you mean NAXSI, right? If that's the case, it wouldn't buy you much if anything. It may be cheaper to drop traffic at their waf than your own though.
It is not clear, do you deploy this in-front of your load balancers, after? They mention CloudFront, but that doesn't make much sense, because you want a WAF to protect your application, not just static assets right?
I hope they allow to re-use ModSecurity rules in future, much like CloudFlare already allows. Some of the web attack detection techniques require you to maintain state which you can't today with AWS WAF
Now the only pice missing are AWS SSL certificates, for a one stop shop on the whole security stack. Perhaps tomorrow at the AWS keynote. Fingers crossed.
It seems like every week Amazon is launching a new web service with a generic abbreviation, and often also a non-descriptive name. Wasn't there something else a few days ago?
I basically stopped having enough mental capacity for that after S3, EBS, Glacier, EC2 (which I just looked up, I spelled it E2), and maybe SES.
How on earth do people survive in that ecosystem without a glossary right by their side?
That's a reasonable complaint but I don't think it's warranted here. WAF is the industry standard term for this kind of service so “Amazon WAF” seems a lot less unhelpful than most of their other names.
It should be mentioned that this service is not a stand alone service but is rather used in conjunction with the CloudFront service - once a WAF ACL has been configured it can be attached to a CloudFront distribution.
Instead of releasing things every month, they should start supporting all regions especially the EU should have more support like all services inside EU Frankfurt since with the court order of the european's it would greatly help to satisfy everybody.
The AWS WAF is, presumably, going to give application developers and owners significantly more insight into whether their apps are getting attacked. Congratulations to the Amazon team for shipping something that has the potential to make a really big difference.
At this point, my only question is why Amazon didn't give it a strange name (like most of the other AWS products)!