Introducing AWS WAF | Hacker News Reader

Introducing AWS WAF

aws.amazon.com

229 pointshepha197997 comments

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.

my only question is why Amazon didn't give it a strange name (like most of the other AWS products)!

Maybe they decided that "WAF" was sufficiently ambiguous. My first guess was s/firewall/framework/.

I'd have given them major kudos if they'd called it Web Traffic Firewall instead.

The first alternative name which came to my mind was "API Condom", but I like your idea more.

Amazon WTF

If your application is on the web, it is being attacked. There's no whether about it.

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.

Noone ever got promoted over "making a service better!". Maybe we should change that :).

if it's bad enough (i.e. threatening the business or at risk of losing customer trust), you can and will be promoted after making things better.

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.

EFS is still in preview 6 months later since announcement. Let's see if it goes GA during reInvent.

Really hoping it does...

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. :(

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"?

Isn't it for ELBs as well?

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."

So, yeah, it's a CLoudfront feature.

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.

> Creating things like Lambda to make NoOps possible is better

I think its hilarious that there's an idea of NoOps. That's like thinking you can automate software development to machine learning.

This is not a WAF like what CloudFlare or Sucuri offers.

It is basically the ability to create filtering rules at a high $ per rule.

Real WAF/IDS products come with a large set of rules that are well tested and have a research team behind it.

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.

In general, if you're not using SNI, you're doing it wrong.

There are probably a dozen orgs who can legitimately claim to absolutely need to support pre-SNI clients, but those shouldn't be on AWS.

>> In general, if you're not using SNI, you're doing it wrong.

Does that apply to wildcard SSL certs, too?

Even as of a year ago the major parts of Android, including the downloads application, didn't support SNI.

Cloudfront works with dynamic content and acts much like Varnish does in those scenarios.

The blog article is a bit more descriptive https://aws.amazon.com/blogs/aws/new-aws-waf/

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.

That's the question, is discarding traffic at the edge a billable event? If so what's the savings over spinning up new instances?

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.

its cute you think thats any kind of deterrant.

Yes, if you cheaply command resources. AFAIK the only way to make this economically viable is to illegally use others' resources (eg botnets)

Hold on, you're telling me someone willing to launch a DDoS attack against a competitor might use illegally gained resources to do so?

Yeah, I guess much more sensible (for customer) is to only count the traffic that passes WAF successfully.

> $5 per web ACL per month.

Really?

> Limits:

> Web ACLs per AWS account: 10

> Rules per AWS account: 50

> Conditions per AWS account: 50

> IP address ranges (in CIDR notation) per IP match condition: 1000

Huh? Is this really intended for production, with such low arbitrary limits?

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...

It's $0.60 per 1M requests in addition to the $5 arbitrary pricing.

+ $1 per rule

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.

[1] only a handful of countries use it, and they don't have English as their primary language: https://en.wikipedia.org/wiki/Decimal_mark#Examples_of_use (row 5)

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.

Interested to know how one could send anything less than a full email :)

they did specify a rate. so it could just be a really slow connection for some mail servers.

While I grant you the "don't use English as primary language", "a handful of countries" does not stand up to scrutiny: https://en.wikipedia.org/wiki/Decimal_mark#/media/File:Decim...

I don't even need to count to figure out that 80+ countries use that system :)

That's a map of decimal marks, not group delimiters. They're not the same thing, nor are they always opposites.

From the page you linked:

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, 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.

> $5 per web ACL per month.

Each Web ACL is basically a group that can contain multiple rules.

As noted, limits are easily raised with a quick email to Amazon.

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?

I like AWS direction towards security. But...

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.

Give a try to Wallarm, NAXSI, Signal Sciences.

None of solutions you've mentioned works in the cloud!

But yep. If you're looking for WAF for NGINX, these are good options.

BTW, mod_security is now compatible with NGINX too.

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.

OK - that's what I thought. I'm loathe to get rid of my own monitoring, simply because it makes it harder to set up DR with another cloud provider.

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.

I wonder why didn't they do it as a config on the ELB instead of a new service.

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?

You could have CloudFront in front of your application servers, though, and it could be doing passthrough requests for non-cacheable assets.

Not that I'd ever want this, because CloudFront is dog slow compared to other CDNs, but yeah..

You can put you entire application in front of Cloudfront.

It works better if you do it the other way around ;)

I had not had sufficient coffee before answering the question :D

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

Will be interesting to see how this competes with Cloudflare and Incapsula

It doesn't. It comes with no rules and they charge quite a bit per rule entry.

CloudFlare, Sucuri and Incapsula all come with pre-package, well-tested rules.

Looks like release notes[1] are currently 404'ed

[1] https://aws.amazon.com/releasenotes/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.

Wouldn't hold my breath, given that the request to include their CA in Mozilla's trust store has gone nowhere in about 4 months:

https://bugzilla.mozilla.org/show_bug.cgi?id=1172401

FYI, Amazon recently purchased a widely distributed CA root: https://www.awstrust.com/repository/

I think the idea is that the security stacks doesn't have holes in it.

; )

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?

Yeah, Amazon's naming conventions are insane. I feel like it's a good reflection of the industry's apparent love of producing jargon.

At least with this one they kept it to a name that is already reasonably well used?

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.

Check out https://www.expeditedssl.com/aws-in-plain-english

Thank god. There are too many third party WAFs that drop SSL connections and Amazon does not support those.

Wake me up when AWS supports IPv6.

Wake me up when there are users with IPv6-only connections. It will be a very long nap...

Chicken, egg. That won't happen until it's almost universally supported in the core of the Internet.

How about users that get better performance over ipv6. like many many mobile users out there.

You can have your tool accessible by some piece of shit CGN and web proxy. or direct over ipv6

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.

Edit: spelling correction

Would love to read about people's experience with this, also the kind of use cases where this is a great fit.

No mention of a critical aspect of a service like this: what is the per request load time overhead?

I'd imagine that depends on the rules you set up. Better to benchmark.

Does anyone know what they use under the covers?

I've been told it's nginx, in the same style of how CloudFlare uses it for their edge locations.

Is that also what Amazon uses for CloudFront?

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.

And here I thought this was an April Fools joke and they implemented Wife Approval Factor in the cloud.

Reply on news.ycombinator.com