AWS WAF
[/fusion_title]
AWS WAF is a web application firewall that lets you monitor the HTTP and HTTPS requests that are forwarded to an Amazon API Gateway API, Amazon CloudFront or an Application Load Balancer. AWS WAF also 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, API Gateway, CloudFront or an Application Load Balancer responds to requests either with the requested content or with an HTTP 403 status code (Forbidden). You also can configure CloudFront to return a custom error page when a request is blocked.
Tutorials[fusion_separator style_type=”none” hide_on_mobile=”small-visibility,medium-visibility,large-visibility” class=”” id=”” sep_color=”” top_margin=”25px” bottom_margin=”25px” border_size=”” icon=”” icon_circle=”” icon_circle_color=”” width=”” alignment=”center” /]
How AWS WAF Works
ou use AWS WAF to control how API Gateway, Amazon CloudFront or an Application Load Balancer responds to web requests. You start by creating conditions, rules, and web access control lists (web ACLs). You define your conditions, combine your conditions into rules, and combine the rules into a web ACL.
- Conditions
- Conditions define the basic characteristics that you want AWS WAF to watch for in web requests:
- Scripts that are likely to be malicious. Attackers embed scripts that can exploit vulnerabilities in web applications. This is known as cross-site scripting.
- IP addresses or address ranges that requests originate from.
- Country or geographical location that requests originate from.
- Length of specified parts of the request, such as the query string.
- SQL code that is likely to be malicious. Attackers try to extract data from your database by embedding malicious SQL code in a web request. This is known as SQL injection.
- Strings that appear in the request, for example, values that appear in the
User-Agentheader or text strings that appear in the query string. You can also use regular expressions (regex) to specify these strings.
Some conditions take multiple values. For example, you can specify up to 10,000 IP addresses or IP address ranges in an IP condition.
- Rules
- You combine conditions into rules to precisely target the requests that you want to allow, block, or count. AWS WAF provides two types of rules:
- Regular rule
- Regular rules use only conditions to target specific requests. For example, based on recent requests that you’ve seen from an attacker, you might create a rule that includes the following conditions:
- The requests come from 192.0.2.44.
- They contain the value
BadBotin theUser-Agentheader. - They appear to include SQL-like code in the query string.
When a rule includes multiple conditions, as in this example, AWS WAF looks for requests that match all conditions—that is, it
ANDs the conditions together.Add at least one condition to a regular rule. A regular rule without conditions can’t match any requests, so the rule’s action (allow, count, or block) is never triggered.
- Rate-based rule
- Rate-based rules are like regular rules with an added rate limit. A rate-based rule counts the requests that arrive from IP addresses that satisfy the rule’s conditions. If the requests from an IP address exceed the rate limit in a five-minute period, the rule can trigger an action. You can set the rate limit as low as 100.
Conditions are optional for rate-based rules. If you don’t add any conditions in a rate-based rule, the rate limit applies to all IP addresses. If you combine conditions with the rate limit, the rate limit applies to IP addresses that match the conditions.
For example, based on recent requests that you’ve seen from an attacker, you might create a rate-based rule that includes the following conditions:
- The requests come from 192.0.2.44.
- They contain the value
BadBotin theUser-Agentheader.
In this rate-based rule, you also define a rate limit. In this example, let’s say that you create a rate limit of 1,000. Requests that meet both of the preceding conditions and exceed 1,000 requests per five minutes trigger the rule’s action (block or count), which is defined in the web ACL.
Requests that don’t meet both conditions aren’t counted towards the rate limit and aren’t affected by this rule.
As a second example, suppose that you want to limit requests to a particular page on your website. To do this, you could add the following string match condition to a rate-based rule:
- The Part of the request to filter on is
URI. - The Match Type is
Starts with. - A Value to match is
login.
Further, you specify a
RateLimitof 1,000.By adding this rate-based rule to a web ACL, you could limit requests to your login page without affecting the rest of your site.
- Web ACLs
- After you combine your conditions into rules, you combine the rules into a web ACL. This is where you define an action for each rule—allow, block, or count—and a default action:
- An action for each rule
- When a web request matches all the conditions in a rule, AWS WAF can either block the request or allow the request to be forwarded to the API Gateway API, CloudFront distribution or an Application Load Balancer. You specify the action that you want AWS WAF to perform for each rule.
AWS WAF compares a request with the rules in a web ACL in the order in which you listed the rules. AWS WAF then takes the action that is associated with the first rule that the request matches. For example, if a web request matches one rule that allows requests and another rule that blocks requests, AWS WAF will either allow or block the request depending on which rule is listed first.
If you want to test a new rule before you start using it, you also can configure AWS WAF to count the requests that meet all the conditions in the rule. As with rules that allow or block requests, a rule that counts requests is affected by its position in the list of rules in the web ACL. For example, if a web request matches a rule that allows requests and another rule that counts requests, and if the rule that allows requests is listed first, the request isn’t counted.
- A default action
- The default action determines whether AWS WAF allows or blocks a request that doesn’t match all the conditions in any of the rules in the web ACL. For example, suppose you create a web ACL and add only the rule that you defined before:
- The requests come from 192.0.2.44.
- They contain the value
BadBotin theUser-Agentheader. - They appear to include malicious SQL code in the query string.
If a request doesn’t meet all three conditions in the rule and if the default action is
ALLOW, AWS WAF forwards the request to API Gateway, CloudFront or an Application Load Balancer, and the service responds with the requested object.If you add two or more rules to a web ACL, AWS WAF performs the default action only if a request doesn’t satisfy all the conditions in any of the rules. For example, suppose you add a second rule that contains one condition:
- Requests that contain the value
BIGBadBotin theUser-Agentheader.
AWS WAF performs the default action only when a request doesn’t meet all three conditions in the first rule and doesn’t meet the one condition in the second rule.
On some occasions, AWS WAF might encounter an internal error that delays the response to API Gateway, CloudFront or an Application Load Balancer about whether to allow or block a request. On those occasions CloudFront will typically allow the request or serve the content. API Gateway and an Application Load Balancer typically will deny the request and not serve the content.
The following illustration shows how AWS WAF checks the rules and performs the actions based on those rules.
AWS Shield
[/fusion_title]
AWS provides AWS Shield Standard and AWS Shield Advanced for protection against DDoS attacks. AWS Shield Standard is automatically included at no extra cost beyond what you already pay for AWS WAF and your other AWS services. For added protection against DDoS attacks, AWS offers AWS Shield Advanced. AWS Shield Advanced provides expanded DDoS attack protection for your Amazon Elastic Compute Cloud instances, Elastic Load Balancing load balancers, Amazon CloudFront distributions, Amazon Route 53 hosted zones, and your AWS Global Accelerator accelerators.
A distributed denial of service (DDoS) attack is an attack in which multiple compromised systems attempt to flood a target, such as a network or web application, with traffic. A DDoS attack can prevent legitimate users from accessing a service and can cause the system to crash due to the overwhelming traffic volume.
AWS provides two levels of protection against DDoS attacks: AWS Shield Standard and AWS Shield Advanced.
AWS Shield Standard
All AWS customers benefit from the automatic protections of AWS Shield Standard, at no additional charge. AWS Shield Standard defends against most common, frequently occurring network and transport layer DDoS attacks that target your web site or applications. While AWS Shield Standard helps protect all AWS customers, you get particular benefit if you are using Amazon CloudFront and Amazon Route 53. These services receive comprehensive availability protection against all known infrastructure (Layer 3 and 4) attacks.
AWS Shield Advanced
For higher levels of protection against attacks targeting your web applications running on Amazon Elastic Compute Cloud, Elastic Load Balancing (ELB), Amazon CloudFront, Amazon Route 53, and AWS Global Accelerator, you can subscribe to AWS Shield Advanced. AWS Shield Advanced provides expanded DDoS attack protection for these resources.
As an example of this added protection, if you use Shield Advanced to protect an Elastic IP address, during an attack Shield Advanced will automatically deploy your network ACLs to the border of the AWS network, which allows Shield Advanced to provide protection against larger DDoS events. Typically, network ACLs are applied near your Amazon EC2 instances within your Amazon VPC. The network ACL can mitigate attacks only as large as your Amazon VPC and instance can handle. For example, if the network interface attached to your Amazon EC2 instance can process up to 10 Gbps, volumes over 10 Gbps will slow down and possibly block traffic to that instance. During an attack, Shield Advanced promotes your network ACL to the AWS border, which can process multiple terabytes of traffic. Your network ACL is able to provide protection for your resource well beyond your network’s typical capacity. For more information about network ACLs, see Network ACLs.
As an AWS Shield Advanced customer, you can contact a 24×7 DDoS response team (DRT) for assistance during a DDoS attack. You also have exclusive access to advanced, real-time metrics and reports for extensive visibility into attacks on your AWS resources. With the assistance of the DRT, AWS Shield Advanced includes intelligent DDoS attack detection and mitigation for not only for network layer (layer 3) and transport layer (layer 4) attacks, but also for application layer (layer 7) attacks.
To use the services of the DRT, you must be subscribed to the Business Support plan or the Enterprise Support plan.
AWS Shield Advanced also offers some cost protection against spikes in your AWS bill that could result from a DDoS attack. This cost protection is provided for your Elastic Load Balancing load balancers, Amazon CloudFront distributions, Amazon Route 53 hosted zones, Amazon Elastic Compute Cloud instances, and your AWS Global Accelerator accelerators.
AWS WAF is included with AWS Shield Advanced at no extra cost. For more information about AWS Shield Advanced pricing, see AWS Shield Advanced Pricing.
Types of DDoS Attacks
AWS Shield Advanced provides expanded protection against many types of attacks. For example:
- User Datagram Protocol (UDP) reflection attacks
- An attacker can spoof the source of a request and use UDP to elicit a large response from the server. The extra network traffic directed towards the spoofed, attacked IP address can slow the targeted server and prevent legitimate users from accessing needed resources.
- SYN flood
- The intent of an SYN flood attack is to exhaust the available resources of a system by leaving connections in a half-open state. When a user connects to a TCP service like a web server, the client sends a SYN packet. The server returns an acknowledgment, and the client returns its own acknowledgement, completing the three-way handshake. In an SYN flood, the third acknowledgment is never returned, and the server is left waiting for a response. This can prevent other users from connecting to the server.
- DNS query flood
- In a DNS query flood, an attacker uses multiple DNS queries to exhaust the resources of a DNS server. AWS Shield Advanced can help provide protection against DNS query flood attacks on Route 53 DNS servers.
- HTTP flood/cache-busting (layer 7) attacks
- With an HTTP flood, including GET and POST floods, an attacker sends multiple HTTP requests that appear to be from a real user of the web application. Cache-busting attacks are a type of HTTP flood that uses variations in the HTTP request’s query string that prevent use of edge-located cached content and forces the content to be served from the origin web server, causing additional and potentially damaging strain on the origin web server.
About the AWS DDoS Response Team (DRT)
With AWS Shield Advanced, complex DDoS events can be escalated to the AWS DDoS Response team (DRT), which has deep experience in protecting AWS, Amazon.com, and its subsidiaries.
For layer 3 and layer 4 attacks, AWS provides automatic attack detection and proactively applies mitigations on your behalf. For layer 7 DDoS attacks, AWS attempts to detect and notify AWS Shield Advanced customers through CloudWatch alarms, but does not apply mitigations proactively. This is to avoid inadvertently dropping valid user traffic.
You can also contact the DRT before or during a possible attack to develop and deploy custom mitigations. For example, if you are running a web application and only need ports 80 and 443 open, you can work with the DRT to pre-configure an ACL to only “Allow” ports 80 and 443.
AWS Shield Advanced customers have two options to mitigate layer 7 attacks:
- Provide your own mitigations: AWS WAF is included with AWS Shield Advanced at no extra cost. You can create your own AWS WAF rules to mitigate the DDoS attacks. AWS provides preconfigured templates to get you started quickly. The templates include a set of AWS WAF rules that are designed to block common web-based attacks. You can customize the templates to fit your business needs. For more information, see AWS WAF Security Automations.In this case, the DRT is not involved. You can, however, engage the DRT for guidance on implementing best practices such as AWS WAF common protections.
- Engage the DRT: If you want additional support in addressing an attack, you can contact the AWS Support Center. Critical and urgent cases are routed directly to DDoS experts. With AWS Shield Advanced, complex cases can be escalated to the DRT, which has deep experience in protecting AWS, Amazon.com, and its subsidiaries. If you are an AWS Shield Advanced customer, you also can request special handling instructions for high severity cases.The response time for your case depends on the severity that you select and the response times, which are documented on the AWS Support Plans page.The DRT helps you triage the DDoS attack to identify attack signatures and patterns. With your consent, the DRT creates and deploys AWS WAF rules to mitigate the attack.
When AWS Shield Advanced detects a large layer 7 attack against one of your applications, the DRT might proactively contact you. The DRT triages the DDoS incident and creates AWS WAF mitigations. The DRT then contacts you for consent to apply the AWS WAF rules.
The DRT can help you to analyze suspicious activity and assist you to mitigate the issue. This mitigation often requires the DRT to create or update web access control lists (web ACLs) in your account. However, they need your permission to do so. We recommend that as part of enabling AWS Shield Advanced, you follow the steps in Step 4: (Optional) Authorize the DDoS Response Team to proactively provide the DRT with the needed permissions. Providing permission ahead of time helps prevent any delays in the event of an actual attack.
To use the services of the DRT, you must be subscribed to the Business Support plan or the Enterprise Support plan.