AWS built its own Web Application Firewall and named the service AWS WAF, and we’re going to take a detailed look at how we can get started using this WAF to protect our AWS cloud applications in this article.
Prefer watching tutorials over reading them? Here you go:
We also created an interactive diagram for this post that you can access here. (It may ask you to create a free account in order to view. You do not need paid features to view this diagram so you can ignore that!)
What is the AWS WAF?
The AWS WAF is a web application firewall that gives us control over HTTP requests. It’s a managed WAF service that integrates with many resources running in AWS. You don’t have to install any additional software to get it up and running. On top of that, it provides out-of-the-box managed rule sets for you to use, which we’ll take a look at in this lesson.
You can use it to protect resources like:
- Application Load Balancers (ALBs)
- Amazon CloudFront distributions (which is their CDN service)
- Amazon API Gateway APIs (which is their API management service)
- AWS AppSync GraphQL APIs (which is their GraphQL service)
- Amazon Cognito user pools (which is their customer identity and access management service that we’ll talk about later in the course)
- Amazon ECS containers (which is their Elastic Container Service)
It uses three different components:
- Web ACLs – which are web access control lists that are made up of rules
- Rules – which are statements that define inspection criteria and the action to take if the web request matches that criteria
- Rule groups – which are reusable groups of rules
We just mentioned how AWS provides managed rules we can use out of the box, and that’s made possible by rule groups that we can use. Or we can create our own rule groups.
Let’s take a look at what these rules and web ACLs look like, but first, a quick note on pricing.
A note on AWS WAF pricing
If you plan on following along with this article, keep in mind that you will be charged a small amount.
AWS WAF incurs additional charges, and works like this:
- AWS charges for each web ACL that you create, and each rule that you create per web ACL
- You also get charged for the number of web requests processed by the web ACL
- Monthly fees are prorated hourly
Please refer to this page for the latest pricing, since AWS may change it after we’ve recorded this lesson.
As of the date of this recording, the pricing is as follows:
|$5.00 per month
|$1.00 per month
|$0.60 per 1 million requests
|Intelligent Threat Mitigation
|Additional costs, see pricing page
This means that if you follow along and create these resources, and then delete them shortly after, you should be charged less than $1. If you forget to delete them, you may get charged a few dollars for the month.
Creating and using Web ACLs and Rules
Let’s pull up the AWS WAF service by searching for it.
We’ll now click on “Create web ACL.” From there, we’ll want to provide a “Name,” “Description,” and “CloudWatch metric name.“
We can then select a resource type between:
- CloudFront distribution
- Regional resources (ie: ALB)
After that, we can select the region, and this should match the region we have that resource in or plan to create it in.
If you don’t have any resources launched that you can associate this WAF to yet, then you can always add that later. We don’t, so I won’t mess with this setting.
We’re now ready to create our first rules.
Creating our first rule
Click on “Add Rules” and for the sake of time, we’re going to select “Add managed rule groups” which will give us a list of pre-created rules.
From there, you’ll see a list of managed rule groups from AWS and from other organizations. Let’s expand the “AWS managed rule groups.”
AWS and third-party managed rule groups
At the top, you’ll see “Paid rule groups” which are specialized rule groups to protect against account takeovers and automated bots.
Using free AWS managed rule groups
If we keep scrolling, we’ll find the “free rule groups” that we can use, like:
- Admin protection
- Amazon IP reputation list
- Known bad inputs
- SQL database
Let’s select the “Amazon IP reputation list” by clicking on the toggle next to it labeled “Add to web ACL.”
We can then minimize this tab and click on “Add rules” at the bottom.
We’ll now see this manage rule group added to our list of rules, and we’ll see that we’ve consumed 25 out of 1500 units for our web ACL capacity.
Configuring our rules
Below that, we can see the “default web ACL action for requests that don’t match any rules” and this means that we will allow requests to go through if they don’t match any of the rules above.
Optionally, you can add a custom header to each request that was allowed to go through and AWS WAF will automatically prefix the custom header with
Now, if something like a bot is suspected, AWS WAF will ask the client to pass a challenge like a CAPTCHA challenge, before it can proceed. If the client passes that challenge, we may not want to challenge them again if they go to another one of our applications or domains. If that’s the case, we can add those other app domains under the “Token domain list.” This isn’t something we need to do right now though.
Let’s click on “Next.”
Setting a rule priority
After that, we’ll be asked to set rule priorities. This is important because the first rules that match will be the ones that get evaluated. This will make more sense in a moment when we talk about the different rule actions, but let’s keep moving forward for now.
Configuring CloudWatch Metrics for our WAF
Next, we are able to create CloudWatch Metrics. If you’ve never used CloudWatch before, it’s an AWS service that lets you observe and monitor your resources on AWS or on-premises. We’ll talk more about this as a separate section later in the course, but know that you do get some free metrics and more with CloudWatch as part of your free tier account, and you can find more information here, so if you’re following along and you’re still part of the free tier, this step should not incur additional charges.
Creating our first WAF Web ACL
I’ll leave the defaults and move forward. We get to review our settings one more time, and then we can create our WAF Web ACLs!
Reviewing important settings and configurations
From there, let’s click on the Web ACL name. This new screen will display a bunch of useful information, including:
- Requests per 5 minute period and Sampled requests
- Bot controls (if we were to enable it)
- Associated AWS resources (which we don’t have any at the moment but we could easily add them here later on)
- Custom response bodies (that let you customize responses to blocked requests)
- Logging and metrics (which lets you control overall settings)
Let’s go back to rules for a moment. Click on the name of the rules list we are using.
The AWS user interface is quite confusing when it comes to trying to figure out exactly what this rule list does. For example, if we scroll down to “Rules in AWSManagedRulesAmazonIpReputationList” we just see that each list’s “Rule action” is set to “Use action defined in the rule” which is not at all helpful.
If we pull up its documentation, we can get more information. We’ll see that:
- “These rules use the source IP address from the web request origin”
- “The Amazon IP reputation list rule group contains rules that are based on Amazon internal threat intelligence”
- “This is useful if you would like to block IP addresses typically associated with bots or other threats
Then we see a more detailed breakdown of each list included in this group:
|Inspects for IP addresses that have been identified as bots.
Rule action: Block
|Inspects for connections from IP addresses that are performing reconnaissance against AWS resources.
Rule action: Block
|Inspects for IP addresses that have been identified as actively engaging in DDoS activities.
Rule action: Count
But what does the rule action of count mean? We can easily figure out that a rule action of block will block the request, but what about count?
Understanding rule actions of Block vs Count
An AWS WAF count action will count the request but it doesn’t allow or block it. Instead, it will continue evaluating the rest of the rules to see if any other rules matches the request. This is useful when:
a) you want to keep track of how many times this type of request has been counted, and
b) it lets you insert custom headers into the request and you can also add labels that other rules can then match against
So count is more of a passive approach, whereas block would prevent the request and give a response of
HTTP 403 (Forbidden); allow would permit the request, or we could challenge the requester to check if it’s a bot or not.
Remember when we talked about rule priorities? This is why it matters.
If you have a higher rule priority that blocks a request before it counts it, then it won’t be counted. If you want to count that type of request before blocking or allowing it, then you have to set the counting rule as a higher priority rule in order for it to get evaluated.
Other AWS WAF features
We’ve now looked at the core of what AWS WAF offers, but there are other features to consider that we’ll just briefly mention and that you can find in the menu:
- Bot control that we’ve already mentioned but we haven’t enabled due to cost
- Application integration SDKs for additional user telemetry and improved bot detection
- IP sets to provide a collection of IP addresses and ranges that we want to use together in a rule statement
- Regex pattern sets
- Our own rule groups that we can create
- AWS Marketplace resources that we can use
I’d like to point out that in the AWS Marketplace, you can find OWASP Top 10 rule sets. So if your organization is wanting to set up AWS WAF rules to protect against the OWASP Top 10 attacks, then that would be a great starting point.
Now that we’re done with these resources, don’t forget to delete them in order to stop accruing charges. We can go to “Web ACLs” in the menu, then select the name, and click on delete. From this point on, you will no longer accrue charges for WAF resources.
We’ve just looked at how we can create and configure the AWS Web Application Firewall which can be used in front of some of our AWS resources such as CloudFront, the Application Load Balancer, and more. This will oftentimes be our very first or one of the first lines of defenses, and so it is important to understand how it integrates and how it can be configured.