Problem Statement

Denial-of-service attacks are characterized by an explicit attempt by attackers to prevent legitimate use of a service. There are two general forms of DoS attacks: those that crash services and those that flood services. The most serious attacks are distributed.

In a Distributed Denial of Service (DDoS) attack, an attacker uses multiple sources— such as distributed groups of malware infected computers, routers, IoT devices, and other endpoints—to orchestrate an attack against a target. As illustrated in Figure below, a network of compromised hosts participates in the attack, generating a flood of packets or requests to overwhelm the target.

In the OSI (Open Systems Interconnection) model (1 – Physical, 2 – Data Link, 3 – Network, 4 – Transport, 5 – Session, 6 – Presentation, 7 – Application), DDoS attacks are most common at layers 3, 4, 6, and 7. In this blog, we will focus on how DDoS attacks can be prevented at the Application Layer (Layer 7).

To defend against application layer attacks requires you to implement an architecture that allows you to specifically detect, scale to absorb, and block malicious requests. This is an important consideration because network-based DDoS mitigation systems are generally ineffective at mitigating complex application layer attacks.

On AWS, you can use WAF (Web Application Firewall) and CloudFront are two services that can help defend against application layer DDoS attacks.

Amazon CloudFront allows you to cache static content and serve it from AWS edge locations, which can help reduce the load on your origin. It can also help reduce server load by preventing non-web traffic from reaching your origin. Additionally, CloudFront can automatically close connections from slow reading or slow writing attackers.

By using AWS WAF, you can configure web access control lists (Web ACLs) on your CloudFront distributions or Application Load Balancers to filter and block requests based on request signatures. Each Web ACL consists of rules that you can configure to string match or regex match one or more request attributes, such as the URI, query string, HTTP method, or header key. In addition, by using AWS WAF’s rate-based rules, you can automatically block the IP addresses of bad actors when requests matching a rule exceed a threshold that you define. Requests from offending client IP addresses will receive 403 Forbidden error responses and will remained blocked until request rates drop below the threshold. This is useful for mitigating HTTP flood attacks that are disguised as regular web traffic. To block attacks from known bad acting IP addresses, you can create rules using IP match conditions or use Managed Rules for AWS WAF offered by sellers in the AWS Marketplace that will block specific malicious IP addresses that are included in IP reputation lists. Both AWS WAF and Amazon CloudFront also allow you to set georestrictions to block or whitelist requests from selected countries. This can help block attacks originating from geographic locations where you do not expect to serve users. To help identify malicious requests, review your web server logs or use AWS WAF’s logging and Sampled Requests features. With AWS WAF logging, get detailed information about traffic that is analyzed by your Web ACL. Information that is contained in the logs include the time that AWS WAF received the request from your AWS resource, detailed information about the request, and the action for the rule that each request matched. Sampled Requests provides details about requests that have matched one of your AWS WAF rules for a period of time in the past 3 hours. You can use this information to identify potentially malicious traffic signatures and create a new rule to deny those requests. If you see a number of requests with a random query string, make sure to whitelist only the query string parameters that are relevant to be cached for your application (using ‘Query String Whitelist’ in CloudFront). This technique is helpful in mitigating a cache busting attack against your origin.

If you are subscribed to AWS Shield Advanced, you can engage the AWS DDoS Response Team (DRT) to help you create rules to mitigate an attack that is hurting your application’s availability. DRT can only gain limited access to your account, and only with your explicit authorization. For more information, see the Support section in this document. You can use AWS Firewall Manager to centrally configure and manage AWS WAF rules across your organization. Your AWS Organizations master account can designate an administrator account, which is authorized to create Firewall Manager policies. These policies allow you to define criteria, like resource type and tags, which determine where rules are applied. This is useful in case you have many accounts and want to standardize your protection. Firewall Manager also allows you to create policies that manage AWS Shield protected resources and VPC security groups.