How to Secure Our Resources From DDoS Attacks With AWS WAF & Shield?

21 min readNov 1, 2022

In this article, we will learn in detail about WAF, DDoS attacks, and Amazon WAF & Shield.

We will create the necessary environment for WAF test. For this, we will build an Application consisting of Static Web Server (EC2 instance), Load Balancer, Target Group. We will mitigate an application layer DDoS attack on the web server that we build, by defining rules and then by creating rule groups with defined rules and later by associating them to Web ACLs, step by step.

Then, we will create a test script and apply it to the web server that we build. Finally, we will examine and analyze the output on AWS WAF dashboard charts and CloudWatch.

Topics we will cover:

1. What is WAF ?

2. AWS WAF & Shield

2.1. AWS WAF

2.2. AWS Shield

3. DDoS Attacks

4. How to mitigate DDoS attacks?

5. Mitigating attacks using AWS Shield Standart

5.1. Creating Rule Groups and Rule

5.2. Creating Web ACLs

6. Test to web ACL

6.1. Create a web application

6.2. Build an Application (Static Web Server, ALB, Target Group)

6.2.1. Create an Apache Web Server with a static website at EC2 console

6.2.2. Create a Target group

6.2.3. Create Application Load Balancers (ALB)

7. Control The Application that we created

8. Create the test script

9. Notice the output

10. AWS WAF Dashboard Charts

11. Subscribe to Shield Advanced

12. As a result

13. Next post: “Cloud Security, The Capital One Case, and The Shared Security Model”

14. References

If you like the article, I will be happy if you click on the Medium Following button to encourage me to write more, and not miss future articles.

Your clap, follow, or subscribe, they help my articles to reach the broader audience. Thank you in advance for them.

1. What is WAF?

When a website is online, it can become the target of many different types of attacks aimed at causing trouble and taking the site offline. DDoS (Distributed Denial of Service) attacks are a very common problem. Protection against DDoS attacks is of primary importance for your internet-facing applications. It overloads IT resources with malicious traffic where they cannot function properly. (1)

While creating an environment for the application, it’s equally important to secure the application and protect the data. Otherwise, If not properly secured, the application data might get into the wrong hands as in the case of the Capital One incident. Capital One hosted a Web Application on EC2 and it was not secured properly. An ex-AWS employee was able to exploit this vulnerability and download reams of customer data from S3. Later it was found that the data from 30 other organizations were also downloaded from AWS.(2) Capital One used AWS WAF (Web Application Firewall) to protect the Web Application, but it was not configured properly because of which the hacker was able to get the access to the data in S3 and download it.

Figure 1 — Working of a Web Application Firewall (WAF).

WAF is one of the protection methods in cases like the above. By deploying a WAF for a web application, a shield is placed between the web application and the internet. This shield helps protect web applications from malicious attacks, and unwanted internet traffic, including bots, injection, and application-layer denial of service. It responds to requests either with the requested content or with an HTTP status code: “403 Forbidden” (see figure 1).

2. AWS WAF & Shield

AWS WAF & Shield is a web application firewall that lets you monitor the HTTP and HTTPS requests that are forwarded to Amazon CloudFront, an Amazon API Gateway REST API, an Application Load Balancer, an AWS AppSync GraphQL API, or an Amazon Cognito user pool.(3) You do this by defining a web access control list (ACL) and then associating it with one or more web application resources that you want to protect.

AWS WAF and AWS Shield (Standart) are part of the AWS Edge Services ecosystem. The difference between both is that AWS WAF (Web Application Firewall) protects the application layer, whereas AWS Shield protects the OSI model’s infrastructure layers (Figure 3).(4) AWS Shield is a managed Distributed Denial of Service (DDoS) protection service, whereas AWS WAF is an application-layer firewall that controls access via Web ACL’s.

Figure 3 — Difference between AWS WAF / AWS Shield and Levels at which they operate in the OSI model.

2.1. AWS WAF

AWS WAF is a managed web application firewall service that helps you protect your web applications at the application layer (layer 7) from common web exploits that could affect application availability, compromise security, and/or consume excessive resources, via Web ACL’s. It lets you control access to your content by configuring rules that allow, block or monitor (count) web requests (HTTP and HTTPS) based on web security rules that you specify, such as the IP addresses that the requests originate from.(5)

AWS WAF protects the following resource types: Amazon CloudFront distribution, Amazon API Gateway REST API, Application Load Balancer, AWS AppSync GraphQL API, and Amazon Cognito user pool.

AWS WAF can help you mitigate;(6)

Distributed denial of service (DDoS) attacks : Try to exhaust your application resources so that they are not available to your customers. At Layer 7, DDoS attacks are typically well-formed HTTP requests that attempt to exhaust your application servers and resources.

Web application attacks : Try to exploit a weakness in your application code or its underlying software to steal web content, gain control over web servers, or alter databases; these can involve HTTP requests with deliberately malformed arguments.

Bots : Generate a large portion of the internet’s website traffic. Some good bots associated with search engines, crawl websites for indexing. However, bad bots may scan applications, looking for vulnerabilities and scraping content, poison backend systems, or disrupt analytics.

For example, you can use AWS WAF to protect against attacks such as cross-site request forgery, cross-site scripting (XSS), file inclusion, and SQL injection, among other threats in the OWASP Top 10(Open Web Application Security Project).(7)

Pricing:

AWS Shield Standard is automatically enabled when you use AWS services like Elastic Load Balancing (ELB), Application Load Balancer, Amazon CloudFront, and Amazon Route 53. You don’t pay fees for AWS Shield Standard protection. If you enable AWS WAF protections in addition to AWS Shield Standard, you pay the standard AWS WAF fees. (8)

AWS WAF charges are based on the number of web access control lists (web ACLs) that you create, the number of rules that you add per web ACL, and the number of web requests that you receive. There are no upfront commitments.

Web ACL: $5.00 per month (prorated hourly), Rule: $1.00 per month, Request: $0.60 per 1 million requests.

AWS WAF Bot Control: Bot Control AMR subscription is $10 per month per WebACL.

Request Fee: $1.00 per Million requests inspected.

Captcha: $0.40 per 1k captcha attempts analyzed.

Challenge: $0.40 per 10k challenge responses served.

AWS WAF Fraud Control: Account Takeover Prevention subscription is $10.00 per month. $1.00 per thousand login attempts analyzed.

Free tiers:

Bot Control: first 10 million requests inspected per month.

Targeted Bot Control: first 1 million requests inspected per month.

Fraud Control: Account Takeover Prevention free usage tier includes the first 10,000 attempts analyzed per month.

2.2. AWS Shield

AWS Shield, a managed Distributed Denial of Service (DDoS) protection service that safeguards applications running on AWS. There are two tiers of AWS Shield:

2.2.1. AWS Shield Standard

All AWS customers benefit from the automatic network layer protections of AWS Shield Standard and at no cost. AWS Shield Standard defends against the most common, frequently occurring network and transport layer (Layer 3 and 4) DDoS attacks to maximize the availability of AWS services.(9)

AWS Shield Standard is available to all AWS customers at no extra cost. It protects you from 96% of the most common attacks today, including SYN/ACK floods, Reflection attacks, and HTTP slow reads. This protection is applied automatically and transparently to your Elastic Load Balancers, CloudFront distributions, and Route 53 resources.(10)

2.2.2. AWS Shield Advanced

For customized protection against sophisticated (Layer 3 to 7) threats targeting your applications, you can subscribe to AWS Shield Advanced. AWS Shield Advanced provides more sensitive detection and tailored mitigations against large and complex DDoS attacks, near real-time visibility into attacks, and integration with AWS WAF, a web application firewall for defense against Layer 7 attacks. AWS Shield Advanced also gives you 24–7 access to the AWS Shield Response Team (SRT) and cost protection against scaling costs stemming from DDoS attacks.(9)

AWS Shield Advanced has $3000 / month + additional data transfer fees. AWS WAF is included with AWS Shield Advanced at no additional cost.

3. DDoS Attacks :

DDoS attacks target a web app’s servers by overwhelming its capacity, often by using bots and other tools.

· The workload on cloud services is artificially increased with imitation messages or repeated communication requests.

· The network is overloaded with traffic, which reduces its responsiveness and cripples its performance.

· Multiple cloud service requests are sent to consume excessive memory and processing resources.

Protecting your business from the impact of Distributed Denial of Service (DDoS) attacks is as important as any other cyberattack.

4. How to mitigate DDoS attacks?

Manually mitigating an application layer DDoS attack with AWS Shield Standard, If you determine that the activity in the events page for your resource represents a DDoS attack, you can create your own AWS WAF rules in your web ACL to mitigate the attack. This is the only option available if you aren’t a Shield Advanced customer. (12)

If you use Shield Advanced, AWS automatically mitigates network and transport layer (layer 3 and layer 4) Distributed Denial of Service (DDoS) attacks. During an attack Shield Advanced automatically deploys your Amazon VPC network ACLs to the border of the AWS network. For this, you can subscribe to AWS Shield Advanced (See below: item 11. Subscribe to Shield Advanced).

5. Mitigating attacks using AWS Shield Standart

Firstly, for manually mitigating an application layer DDoS attack with AWS Shield Standard, we start by defining rules and then create rule groups with defined rules and associate them with Web ACLs.

5.1. Creating Rule Groups and Rule

For this, go to AWS WAF & Shields (We can easily access the WAF service when we search for “waf” on the AWS Console.) → Rule Groups → Click Create Rule Groups button (see Figure 5). Here we select “US East (N. Virginia)” because we created our application in this region.

Note: If you will build an architecture diagram with CloudFront, you must choose “Global CloudFront”.

Step 1: Describe rule group

Give a name to the Rule group and select a region for it. If you don’t give a name “CloudWatch metric name”, it will be the same as the rule group’s name. Here we chose US East (N. Virginia) again (See Figure 6), Click on next.

Note: For Name, enter a friendly name to help you identify the AWS resources that are protected.

Step 2.1. Creating Rule

In every rule group and web ACL, rules define how to inspect web requests and what to do when a web request matches the inspection criteria. For each rule, you specify whether you want to block matching web requests or allow them or count matching requests. When Clicking on “next” in figure 6, “Add rules and set capacity” page opens. When we click on “add rule” button (see figure 7),

Figure 7 — Add rules and set capacity page.

“Add rule” page opens. It consists of three parts; Rule, Request and Action (figure 8–9).

In the Part of Rule: Give a name to rule, then select a type: “Regular rule” or “Rate-based rule”. We selected “Rate-based rule” (Figure 8).

Step 2.1.1. Creating Rate-based rule

If we choose “Rate-based rule”, the following options in figure 9 will appear. Rate-based rules count the requests that arrive from a speciﬁed IP address every ﬁve minutes. The rule can trigger an action if the number of requests exceeds the rate limit. The action will trigger designated in the web ACL. Options:

Step 2.1.1.1. Request rate details (figure 9-a)

“Rate limit” is the maximum number of requests from a single IP address that are allowed in a five-minute period. This value is continually evaluated, and requests will be blocked once this limit is reached. The IP address is automatically unblocked after it falls below the limit. Rate limit must be between 100 and 20.000.000 We type 100 in “Rate limit” for test.

“IP address to use for rate limiting”: We selected “Source IP address”.

If we choose “IP address in header” the following options will appear;

“Header field name”: X-Forwarded-For (XFF) is the most commonly used header for the client and proxy IP addresses. If you’re using a different header, you can enter the name here.

And the following options will appear too;

“Fallback for missing IP address”: Match status to apply if the request doesn’t have a valid IP address in the specified position. Note that, if the specified header isn’t present at all in the request, AWS WAF doesn’t apply the rule to the request.

Match: Treat as matching.

No match: Treat as non matching.

“Criteria to count request towards rate limit”: Choose whether to count all requests for each IP address or to only count requests that match the criteria of a rule statement. We selected “Consider all requests”.

Or, choosing “Only consider requests that match the criteria in a rule statement”.

Step 2.1.1.2. Action (figure 9-b)

Here, you choose an action to take when a request matches the statements above. We chose “block”.

“Block” option: This action terminates the web ACL evaluation of the request. By default, the AWS resource responds with an HTTP 403 (Forbidden) status code, but you can customize the response.

So, if requests from a single IP address in a five-minute period is reached 100, it will be blocked. The IP address is automatically unblocked after it falls below 100. Requests that do not meet both conditions will not be counted towards the rate limit (=100) and would not be blocked by this rule.

“Count” option: AWS WAF counts the request but doesn’t determine whether to allow it or block it. You can use the count action to track your web traffic without modifying how you handle it. You can use this for general monitoring and also to test your new web request handling rules. When you want to allow or block requests based on new properties in the web requests, you can first configure AWS WAF to count the requests that match those properties. This lets you confirm your new configuration settings before you implement new allow or block actions.

“Captcha” option: Run CAPTCHA checks against requests that match your criteria. so, you can implement CAPTCHA controls against requests to help reduce bot traffic to your protected resources.

Note: You are charged additional fees when you use the CAPTCHA rule action.

Note: You can select different options according to your system security requirement on the Add Rule page.

Step 3. Set rule priority

AWS WAF evaluates the rules in the order shown, starting from the top. Move rules up or down to change the evaluation order in figure 10.

Step 4. Review and create a rule group

Check your rule group settings, make any changes you need, then choose “Create” to create the rule group. Then click on “Create rule group” buton in figure 11 and finished creating rule, appear “cmakkaya-test-webACL-for-LoadBalancer” in the rule group page in figure 12.

Figure 11 — Review and create rule group page.

5.2. Creating Web ACLs

We created rule groups with defined rules and now we will associate them with a Web ACLs.

For this, go to AWS WAF&Shield → Web ACLs → Click on Create Web ACL button (see Figure 13).

Note: Here we select “US East (N. Virginia)” because we created our application in this region.

Step 1. Describe web ACL and associate it to AWS resources:

Give a name to Web ACLs in figure 14.

Description (optional), type a description about web ACLs to help you identify the AWS resources that are protected.

If you don’t, give a name “CloudWatch metric name”, it will be the same as Web ACLs’ name.

Choose a Resource type, we selected “Regional resources (Application Load Balancer, API Gateway, AWS AppSync, Amazon Cognito User Pools”.

Region: Choose the AWS region to create this web ACL in.US East (N. Virginia)).

Note: If you use CloudFront distributions, the region comes automatically to “Global CloudFront”

Click on “Add AWS resources” button (See Figure 15) then Add AWS resources on the page opened (See Figure 15).

Figure 14 — Describe web ACL and associate it to AWS resources page.

In figure 15, in the name pane, we chose the Application Load Balancer’s name that we created earlier.

Note: If you didn’t create Application Load Balancer and others earlier, You can create them by following in sequence the steps described in “6. Test to web ACL” to create the necessary environment for WAF test.

Click on “add” in figure 15 then Click on “next” in figure 14.

Step 2. 1. Add rules and rule groups

Click on “Add rules” then chose “Add my own rules and rule groups” in figure 16.

“Add my own rules and rule groups” page opens (see figure 17).

Figure 16 — Add rules and rule groups page.

2. 2. Add my own rules and rule groups

In rule type, chose “Rule group” then,

Give a name to “Rule” then,

In Rule group, we chose the Rule group’s name that we created earlier. (See Figure 17).

Then click on “Add rule”.

Figure 17 — Add my own rules and rule groups page.

Step 2. 3. Add rules and rule groups page reopens

Rule group’s name that we created appears in “rules” pane, under “name”. (see figure 18)

“Web ACL rule capacity units used” “2/1500 WCUs”, means Rule group that we created used 2 units.

Note: The total capacity units used by the web ACL can’t exceed 1500.

“Default web ACL action for requests that don’t match any rules” pane:

Default action: We chose “Allow”, so we allow requests that don’t match any rules to reach our resource.

Then click on “next”.

Figure 18 — Add rules and rule groups pages.

Step 3. Set rule priority pages open

The rules are prioritized in order they appear. If there was more than one rule, we would adjust it with “move up/move down” (see figure 19).

Step 4. Configure metrics pages open

CloudWatch metrics allow you to monitor web requests, web ACLs, and rules. If you want, you change its name.

In addition, we chose “Enable sampled requests” in “Request sampling options”. So, AWS sends 30 sample requests to us to verify rule (see figure 20).

Note: If you disable request sampling, you can’t view requests that match your web ACL rules.

Figure 20 — Add rules and rule groups pages.

Step 5. Review and create web ACL

Check your web ACL settings, make any changes you need, then choose “edit”.

If there aren’t any changes then click on “Create web ACL” button and finish creating web ACL,

Now, appear “cmakkaya-test-webACL-LoadBalancer” in web ACL page in figure 21.

Click on “cmakkaya-test-webACL-LoadBalancer”.

So, we can see ACLs that we created about information in figure 22.

Note: We can perform operations using AWS CLI with: aws waf list-web-acls

6. Test to web ACL

Now, it is time to test the Rate Limit ACL. For this, we will use a web application that we created earlier. If you didn’t create we application earlier, you can create it by following the steps described in below, to create the necessary environment for WAF test.

6.1. Create a web application

You can create a web application with only Load Balancer and Instance for testing as in figure 23, or create a web application with CloudFront for test as in figure 24.

Of course, if you choose the test in figure 24, you must associate created the CloudFront with the AWS WAF (in the rule group and Web ACLs).

Figure 23 — Build a simple Application with only Load balancer and Instance for testing.

Figure 24 — Build an Application with CloudFront for test.

6.2. Build an Application (Static Web Servers, ALB, Target Group)

Following the steps described below, to create the necessary environment for WAF&Shield test.

6.2.1. Create an Apache Web Server with static website on EC2 console.

Go to Instances on EC2 console, click on Launch instance, its link.

Amazon Machine Image (AMI) : Amazon Linux 2 AMI (HVM), SSD Volume Type

Instance Type : t2.micro

Network : Select your default VPC

Subnet : Select a public subnet

Auto-assign Public IP : Enabled

Security Group : VPC : Default VPC

Inbound Rules: Type: SSH TCP 22 — -> Source: Anywhere 0.0.0.0/0.

Type: HTTP TCP 80 — -> Source: Anywhere 0.0.0.0/0.

Outbound Rules: Keep it as it is. (Attention: This configuration is just test. )

User data : Paste the text from the script below:

#!/bin/bash -x
#update os
yum update -y
#install apache server
yum install -y httpd
# create a custom index.html file
chmod -R 777 /var/www/html
echo "<html>
<head>
<title> Web Server Running in AWS</title>
</head>
<body>
<h1>This web server is protected by AWS WAF</h1>
</body>
</html>" > /var/www/html/index.html
# start apache server
systemctl start httpd
systemctl enable httpd

Click on “Launch instance”.

6.2.2. Create target group

Go to Target Group on EC2 console, its link.

Target Type: Instances

Target group name: MyTargetGroup

Protocol: HTTP

Port: 80

Protocol Version: HTTP1

Health Checks: Use Defaults

Register Targets: Select the instance you created above and click on ‘Include as pending below’

Click on “Create target group”.

6.2.3. Create Application Load Balancers (ALB)

Go to Application Load Balancer on EC2 console, its link.

Load balancer name : MyLoadBalancer

Scheme : Internet Facing

IP Address Type : IPV4

Network Mapping : VPC : Select your default VPC (same as that selected for EC2 instance above)

Mappings: Select all availability zones.

Security Groups : Same with Instances

Listeners and Routing : Protocol : HTTP

Port : 80

Default Action: Forward to MyTargetGroup (target group created above)

Click on “Create Load Balancer”.

7. Control The Application that we created

Go to Application Load Balancer on EC2 console, its link.

Choose our ALB that we crated, then go to DNS name in the Description pane below, and copy DNS name, for example our DNS name is “cmakkaya-test-ALB-for-WAF-173332589.us-east-1.elb.amazonaws.com”

Paste it into your web browser, you must see the page below:

Figure 25 — Static Web Application page is running.

8. Create the test script

In the Linux terminal, create a load test using BashScript and run it to test our website whether protected by AWS WAF or not. To learn how to do this, see my article “Creating a Load Test using BashScript and Trying on a website protected by AWS WAF”

9. Notice the output

When the script runs (see figure 26), notice what happens shortly after the count exceeds 100 (Note: Because of the way AWS samples (30 units), this number will go above 100 in a short time).

Request exceeded 100 and AWS WAF blocks requests based on the conditions that we specify. We can’t access the static website anymore (see figure 27).

AWS WAF blocks web requests from the load test script, and returns HTTP status code 403 (Forbidden), see figure 28.

Figure 27 — “403 (Forbidden)” Request exceeded 100 and AWS WAF blocks requests.

Figure 28 –AWS WAF blocks a web request and returns HTTP status code “403 (Forbidden)” in browser.

10. AWS WAF Dashboard Charts

Explore also the AWS WAF Dashboard for this WebACL. When the test script run, the Dashboard showing the Web ACLs that we created is empty. We adjusted the Dashboard time range: 15 minutes, and clock: from UTC to local time by clicking the custom button (see figure 28).

When requests exceeded 100, AWS WAF Dashboard warned us “All Blocked request 134” (see figure 29).

Figure 28 — AWS WAF Dashboard for WebACL at the begining.

Figure 29– AWS WAF Dashboard, When requests exceeded 100.

By clicking “View in Amazon CloudWatch”, we can see the results in Amazon CloudWatch, and set alarm too (see figure 30).

Figure 30 — To see the results in Amazon CloudWatch.

11. Subscribe to Shield Advanced:

For this in the left menu; go to AWS WAF & Shield → AWS Shield → Getting started.

Click on Subscribe to Shield Advanced in figure 31.

Click on “Subscribe to Shield Advanced” in Figure 32.

Figure 32 — Subscribe to Shield Advanced pages.

In opening the page in Figure 33;

We see a general overview. On this page; We can add our resources to protect with the Shield Advanced page, see “events” and “global threat dashboard”, and configure AWS SRT Support.

We can see the list of protected resources that gives us more details in Figure 34.

12. As a result

In many cases, AWS Shield Standard protection is suﬃcient for our needs. Thanks to the web ACL that we created and tested; we saw, that if the same IP address does more than 100 requests in a five-minute period, AWF WAF will block them by returning a “403 forbidden” HTTP code, with a cost of $6 / month ($5.00 per web ACL per month + $1.00 per rule per month).

However, there is a big difference between Denial of Service (DoS) and Distributed Denial of Service (DDoS) attacks. As distributed means different IP addresses, AWF WAF will not detect any DDoS if each IP does less than 100 requests(in our example that we specified in figure 9-a, clause 5.1.) per 5-minute period. AWF offers another service called AWS Shield Advanced to protect you against DDoS attacks (see item 2.2.2. and to use see item 11 above).

If you liked the article, I would be happy if you click on the Medium Following button to encourage me to write and not miss future articles.

Your clapping, following, and subscribing, help my articles to reach a broader audience. Thank you in advance for them.

For more info and questions, please contact me on Linkedin or Medium.

13. Next post

In the next post, “Cloud Security, The Capital One Case, and The Shared Security Model”.

We talk about Capital One Financial Corporation's Data Theft Impacts on IT. Also, We will talk about the importance of the human factor in cloud security. In this context, we will examine the Capital One case and draw attention to the outcome of the case and the lessons to be learned from it, what are the company’s mistakes? We will talk about what changes it has caused in the IT industry. Finally, we will talk about the Shared Responsibility Model.

The later post will be about “Subscribing and Using The AWS Shield Advanced For Higher Levels Of Protection Against Attacks Targeting The App” In this article, we review AWS Shield Advanced, which provides us with more customized protection against sophisticated (Layer 3 to 7) threats targeting our applications. We will learn to subscribe to, configure, and use it.

The 4th article of this series will be about “AWS Best Practices for DDoS Mitigation and Security Techniques”. We will create the necessary environment to mitigate DDoS attacks by using “AWS Best Practices”. Then, we will test it on a web application that we will build. Finally, we will examine and analyze the output on AWS WAF dashboard charts and CloudWatch, step by step.

Happy Clouding…

Don’t forget to follow my LinkedIn or Medium account to be informed about new articles.