If you run a web application in the cloud, sooner or later you have to deal with security and protect it from malicious input. AWS WAF Security Automations can be a handy alternative to expensive or more complex security products.

What is AWS WAF Security Automations?

AWS WAF Security Automations is a set of CloudFormation stacks that are meant to protect your websites or web applications based on malicious behavior on behalf of the client. It is open source and can be obtained here.

TL;DR

AWS WAF Security Automations might be your low hanging fruit when it comes to having at least some web application security installed for your infrastructure. It comes at a price of a certain effort of iterations and redeployments until it finally runs with the features you selected. The documentation is partially outdated. It uses AWS WAF classic, which has been superseded by AWS WAF v2. The WAF rules generated by this framework are de facto static and can be, but are not meant to be modified or extended.

What does this article cover?

My motivation is to support you with your decision whether AWS WAF Security Automations is worth a shot before you invest your time and effort. The article will present some key aspects that might be valuable input to you and already be enough to answer that question.

What does this article not cover?

Given that I am not a professional penetration tester (I have some knowledge in that field and I know some tools used for such assessments), I cannot make a statement whether the WAF rules provided by AWS actually make sense nor where to expect blind spots. Bear in mind that this framework does not receive the same attention like a typical commercial product does.

History

AWS WAF Security Automations was introduced in 2016, has seen a few iterations in 2018, and AWS finally gave it some proper attention by the end of 2019. AWS include it in their AWS Solutions Library from February 2020 on, dedicating it an extensive documentation and an implementation guide.

As of today (June 2020) the most recent version is 2.3.2, while version 3.x is in the making.

Typical scopes of WAF solutions

There are multiple aspects that one usually wants to have covered with a WAF solution.

- Protection against attacks based on high number of requests per second e.g. (D)DoS

- Protection against scanners and probes

- Protection against attacks with forged malicious content attempting texploit a misconfiguration

- Adaptive behavior through blocking requester IPs that are identified as malicious

AWS WAF Security Automations allows you to address all three of those aspects.

For a much deeper explanation of web attack types and possible ways of remediation please refer to the OWASP Top 10.

Architecture

Source: https://docs.aws.amazon.com/solutions/latest/aws-waf-security-automations/architecture.html

At the core — Security

This WAF solution is protecting your infrastructure either by integrating it with a CloudFront distribution, an Application load balancer or both. Some of its components are of a pass-through nature, which means that those process every request handled by CloudFront or an ALB. Such mechanisms are responsible for protecting from SQL injection and XSS request content patterns. Implementation wise those are basically WAF rules.
Other components work on the side, analyzing logs and interpreting those for traces of suspicious behavior that also have a time component and take actions based on that. Actions for that matter mean implementing a feedback loop through adding a malicious IP address to the WAF’s IP blacklist. This mechanism is mainly used to detect DDoS or scanning behavior, evaluating request patterns not only by their content, but also by their rate per time interval.

Another interesting approach provided is a honeypot infrastructure. This is an addition to the IP backlisting part. A honeypot would register requests to given paths under your application that are not part of its regular funcionality, but rather imply an intention of reconnaissance on the requester’s behalf. In short: An HTTP request to the path http://ecample.com/.git would not fall under the scope of your application’s functionality, but rather suggest an activity of reconnaissance. As a consequence such requests’ source IP would be added to the IP blacklist.

At the core — Deployment

The solution comes as a set of CloudFormation templates that are deployed via bash scripts. Bear in mind that the current documentation explaining that part is wrong. CloudFront distributions “live” in the us-east-1 region, so if your Application Load Balancer resides in a different region than us-east-1, you need to deploy another WAF Security Automations stack’s instance in the ALB’s region for being able to attach it to it.

Things to consider

Custom rules

Internally, the CloudFormation stacks responsible for the WAF rules generate some stack code dynamically via Lambda. There is no rule file or whatsoever. Changing the rules or adding your own ones requires you to change the Lambda functions generating the CloudFormation code. I strongly advise against taking that path.

Rate limitation

Rate limitations can be configured in one of the following three ways:

- WAF rate limitation (minimum configurable rate is 2000 requests per 5 minute interval)

- Per access log file via Lambda based processing (evaluation scope does not cross log file boundaries)

- Across all log files via Athena queries (expensive) fed to a Lambda function

IP Blacklisting

To populate your IP blacklist you can use these configs in combination:

- 3rd party IP reputation lists

- CloudFront or ALB access log analysis via Lambda or Athena

- Manual selection through a list of provided list of IPs to either block or allow

- Honeypot infrastructure

Roll it out gradually

Ideally first deploy this solution to your staging or test environment where it cannot interfere with your production components and potentially negatively impacting your business. There is a CloudWatch Dashboard being deployed along with it and this is the first spot you’d want to check if there are benign requests being blocked, assuming that on test or staging you’re not exposed to public traffic or potential attacks. The WAF rules are based on string patterns and there is always the risk for false positives.

Conclusion

AWS WAF Security Automations is a low hanging fruit when it comes to WAF solutions — it is free and commercial solutions can be expensive. However, it takes a few deployment iterations to understand its requirements and dependencies. However, that is probably the case for any other solution as well. The fact that the documentation is outdated and pull requests with fixes addressing that are left to rot does not help. Do not expect a product that works out of the box by pushing a single button.

At the core it uses the outdated AWS WAF classic. Currently AWS WAF v2 is what you want to use and AWS claim that the upcoming WAF security automations will be based on WAF v2. The fact that this requires a complete rewrite does not make me optimistic enough to expect that to happen in the near future. This brings us to another important aspect — custom rules. Realistically this is probably out of reach given the effort it would require. So either AWS WAF security automations does its job for you as it is or you continue your evaluation by picking another product.

Disclaimer

This article represents my personal views and experiences. Your results may vary. Reproduce those at your own risk.

About me

I am the Cloud Lead behind epek.app, a new project and roadmap planning app on the horizon. However, most of the time I am doing contracting work related to AWS DevOps, Cloud Security and Cloud Solution Architect projects. I’ve come a long way starting with Linux in 1997, did FPGA design, Linux Kernel development and finally found my happy spot in the cloud.