As more organizations have embraced the cloud, new security challenges have arisen, but new security tools have also become available. In this article, we will discuss how to configure and use AWS WAF (Amazon Web Services’ Web Application Firewall) to protect web applications and APIs hosted in an AWS cloud environment.
What is AWS WAF?
AWS WAF helps to protect front-end AWS services from various types of attacks and known vulnerabilities. In an AWS environment, your application might be running on EC2 Virtual Machines or ECS Containers, or using Serverless services like API Gateway. This means that your web applications or web APIs can be exposed through different endpoints.
AWS WAF can block hostile traffic and provide both web application security and API security. Currently it can help in securing these endpoints:
To start protecting your AWS resources, you first need to create an Access Control List (ACL). Each web ACL contains a set of Rules or Rule Groups. Rule Groups are reusable, plus you can use managed Rule Groups across multiple web ACLs.
A WAF rule defines the common attack patterns to watch for in the incoming requests, as well as the action to take whenever a request matches a pattern. You can build your own rules based on your requirements or use existing rules offered by AWS or within the AWS Marketplace.
Each rule defines what to check for and what action to perform if needed. There are three actions available:
- Allow all incoming requests except those you specifically block.
- Block all incoming requests except those you specifically allow.
- Count only the requests that match your configured rule properties.
For example, you can have a very simple rule to block all requests coming from a particular country or set of IP addresses.
You can add multiple rules to one web ACL until it reaches the ACL total capacity. By default, each web ACL has 1,500 capacity units. (Note: You can increase the default capacity by contacting AWS Support.) AWS calculates these units differently for each rule. For example, in terms of processing power, checking a request against a list of reputed IP addressing rules costs less than checking against known Windows-specific exploits.
As mentioned above, each WAF rule can have an action of allow, block or count. Allow and block are terminating actions, so if you have multiple rules in your web ACL, the first to come up with a match will return with the configured action and stop the evaluation of the remaining rules. Count is a non-terminating action, so if you have defined a count rule and it matches with a request, the WAF will register the count and move on to evaluate the remaining rules in the ACL.
Set Up AWS WAF
Let’s create a web ACL and assign rules to protect against known threats.
Create a Web ACL
First, you need to create a web ACL and associate it with existing AWS resources. In the example below, we associate the web ACL with an Amazon AppSync GraphQL endpoint. The application is deployed and already running:
Note: Amazon AppSync is a serverless, fully-managed GraphQL engine to build large-scale GraphQL applications with features like real-time updates and offline capabilities.
Next, you have to assign rules to your ACL. You can select from managed rules or create your own.
Assigning ACL Rules
For this example, we will use one of the managed rule groups, a list of which you can access via AWS Marketplace:
Most rules provided by AWS are free, but the Bot rule is not (and thus, it’s under the ”Paid rule groups”):
Each rule has an associated capacity that will be counted against the total available capacity of the web ACL. Below, we select the “Core rule set” to protect against a wide range of common vulnerabilities including the OWASP Top 10:
Now, you should be able to see the consumed and remaining capacity of your web ACL. You can also configure the default action to be triggered if none of the rules defined in this rule set match the request pattern; here, it is set to “Allow”:
If there are multiple rules in your web ACL, you can prioritize them to be evaluated in a specific order. As mentioned earlier, allow and block are terminating actions, so prioritizing the rules in the correct order is important:
Here, we have only one rule set, so all the rules inside that single rule will be evaluated in the order they’re in until a match is found.
Configure Logging and Metrics
Monitoring and logging are important aspects of security, and so AWS WAF provides logging and metrics capabilities to show how incoming requests are being processed. The logs and metrics also help to ensure that False Positive alarms aren’t being generated (i.e., that the configured rules aren’t affecting valid requests).
Seeing AWS WAF in Action
After creating the web ACL and waiting for a few minutes to let it collect the request logs, the dashboard starts showing the metrics and sampling requests.
You can also expand each of the collected sampled requests to view further information:
So far, we’ve seen how to configure and get AWS WAF up and running. Now let’s discuss some uses for it.
Practical Use Cases of AWS WAF
Aside from processing incoming requests and deciding to allow, block, or count, AWS WAF has other useful features suitable for modern use cases.
Bot Control
Some bots (such as search engine crawlers) can be beneficial, but many are hostile or are otherwise unwelcome. Therefore, bot management is an important aspect of web security. AWS WAF provides Bot Control managed rule groups that can be used with other rules to protect your applications. While this is a convenient feature, it does come at an additional cost.
Rate Limiting
The regular WAF rules are meant to allow, block, or count the number of requests coming in, but you can configure the rules to specifically limit access as well. Rate-based rules are the same as regular rules, but instead of allowing or blocking the requests, they monitor how many requests arrive from individual IP addresses in a five-minute period. This helps configure a specific number of requests each IP address is allowed to generate in a given time period.
Request Response Customization
By default, when a request is blocked, AWS WAF sends an HTTP 403 response back to the client. If you want to change this, you can customize the default response. In some cases, you may also want to customize the request or redirect it based on the HTTP headers. For example, requests coming from bots may be redirected to a cached data source instead of loading the data from the database.
AWS WAF APIs
AWS WAF APIs allow you to customize rules programmatically and manage security policies as part of CI/CD or other automated processes. If you are managing multiple AWS accounts, this can help maintain consistency across different environments. AWS offers another service, Firewall Manager, to centrally manage all your WAF rules, but it can only apply rules under different AWS accounts in AWS Organization.
Now, let’s look at some of the limitations of AWS WAF.
Limitations of AWS WAF
Today’s threat landscape is diverse and constantly expanding. AWS WAF is a useful service in many ways, but for most organizations, it will not be sufficient to fully protect cloud workloads.
Manual Configuration
To use AWS WAF properly, admins need to understand all potential threats, and configure the ACL rules to protect against them. Doing this completely and correctly requires a level of security expertise that many admins do not have.
Another significant limitation is that ACL rules, once defined, don’t change or adapt on their own. Admins need to monitor the threat environment (which is always evolving) and customize AWS WAF settings to address new threats in alignment with current security requirements. This can be difficult and time-consuming.
For effective web security, your organization needs a solution that is initially configured by experts (or is set up with the assistance of experts), and then is managed and updated for you, with no time or expertise needed from your team. AWS WAF does not provide this.
Delayed Updates
AWS WAF allows admins to update rules in real time, although it may take a short while (a few seconds to a few minutes) before the new rule is applied to all the necessary edge points.
While applying the rules, associated AWS resources may receive a delayed response about allowing or blocking incoming requests due to internal errors. If this happens and the associated resource is a CloudFront distribution, then it will usually allow the request to pass through; for all other regional services like Application Load Balancers or AppSync GraphQL endpoints, the request will be denied by AWS WAF.
Architectural Limitations
AWS WAF can only be configured to AWS services within one AWS account. However, most enterprises use either a multi-account or multi-cloud strategy, where their entire application is shared between multiple geographic locations. Maintaining a consistent baseline security configuration in such environments is difficult, time-consuming, and error-prone. AWS provides additional services like Firewall Manager to configure WAF rules across different AWS accounts or AWS Shield Advanced to further tighten security and prevent DDoS attacks, but these are not useful or applicable in all situations.
Limited Protection
AWS WAF is not a complete security platform, nor is it meant to be. There are many threats that it is not designed to protect against. Even among the threats that it does cover, in many cases its protection is fairly rudimentary.
Summary
Cloud-using organizations need protection for their workloads, and AWS WAF is a popular choice. Its ease of setup, integration with other AWS services, and pricing model are all very attractive.
However, for most organizations, the base-level security that AWS WAF provides will not be sufficient. Additional services (such as AWS Firewall Manager and AWS Shield Advanced) and paid add-ons from AWS Marketplace will close some of these gaps, but not all of them, nor will they solve the problem of a self-managed solution being error-prone and difficult to maintain consistently.
In these circumstances, Reblaze can help. Reblaze is a comprehensive security platform that runs natively on AWS; it provides robust protection that the built-in services (AWS WAF, AWS Shield, etc.) do not. Along with a next-gen WAF that is more flexible and powerful than AWS’s, it also includes DDoS protection, advanced bot management, session flow control, ATO (Account Takeover) Prevention, API security, a mobile SDK, and more, in an all-in-one suite that does not require additional purchases or add-ons. Plus, Reblaze is not limited to AWS environments; it can also protect your workloads across Microsoft Azure, Google Cloud Platform, Digital Ocean, hybrid architectures, containers and service meshes, and more. And because it is a fully managed service, your web security is maintained and kept up-to-date for you by a team of security experts.
For more information about Reblaze, or to schedule a demo, you can contact us here.
