layer DDoS attacks (when used with Amazon CloudFront or ALB). • Automatic baselining of web traffic attributes, when used with AWS WAF. • Access to AWS
29 pages
29 KB – 35 Pages
PAGE – 2 ============
Notices Customers are responsible for making their own independent assessment of the information in this document. This document: (a) is for informational purposes only, (b) represents current AWS product offerings and practices, which are subject to change withou t notice, and (c) does not create any commitments or assurances from AWS and without warranties, representations, or conditions of any kind, whether express or implied. T he responsibilities and liabilities of AWS to its customers are controlled by AWS agreements, and this document is not part of, nor does it modify, any agreement between AWS and its customers. © 20 2 1 Amazon Web Services, Inc. or its affiliates. All rights reserved.
PAGE – 3 ============
Contents Introduction .. .. .. .. 1 Denial of Service Attacks .. .. .. . 1 Infrastructure Layer Attacks .. .. .. 3 Applic ation Layer Attacks .. .. .. . 5 Mitigation Techniques .. .. .. 7 Best Practices for DDoS Mitigation .. .. 11 Attack Surface Reduction .. .. .. .. 18 Obfuscat ing AWS Resources (BP1, BP4, BP5) .. . 18 Operational Techniques .. .. .. . 21 Visibility .. .. .. 21 Support .. .. .. 28 Conclusion .. .. .. . 30 Contributors .. .. .. .. 30 Further Reading .. .. .. .. 30 Document revisions .. .. .. .. 31
PAGE – 4 ============
Abstract to protect your business from the impact of Distributed Denial of Service ( DDoS ) attacks, as well as other cyberattacks. Keeping customer trust in your service by maintaining the availability and responsiveness of your application is high priority . You al so want to avoid unnecessary direct costs when your infrastructure must scale in response to an attack. Amazon Web Services ( AWS ) is committed to providing you with the tools, best practices, and services to defend against bad actors on the internet. Using the right services from AWS help s ensure high availability, security, and resiliency . In this whitepaper, AWS provide s you with prescriptive DDoS guidance to improve the resiliency of applications running on AWS. This includes a DDoS – resilient reference a rchitecture that can be used as a guide to help protect application availability . This whitepaper also describe s different attack types, such as infrastructure layer attacks and application layer attacks . AWS explain s which best practices are most effectiv e to manage each attack type. In addition, the services and features that fit into a DDoS mitigation strategy are outlined and how each one can be used to help protect your applications is explained . Th is paper is intended for IT decision makers and secur ity engineers who are familiar with the basic concepts of networking, security, and AWS. Each section has links to AWS documentation that provides more detail on the best practice or capability.
PAGE – 5 ============
Amazon Web Services AWS Best Practices for DDoS Resiliency 1 Introduction Denial of Service Attack s A Denial of Service (DoS) attack is a deliberate attempt to make a website or application unavailable to users, such as by flooding it with network traffic. Attackers use a variety of techniques that consume large amounts of network bandwidth or tie up other system resources, disrupting access for legitimate users. In its simplest form, a lone attacker uses a single source to carry out a DoS attack against a target, as shown in the following image. Diagram of a DoS Att a ck I n a DDoS attack, an attacker uses multiple source s to orchestrate an attack against a target. These sources can include distributed groups of malware infected computers, routers, IoT devices, and other endpoints. The following diagram shows a network of compromised host participates in the attack, generating a flood of packets or requests
PAGE – 6 ============
Amazon Web Services AWS Best Practices for DDoS Resiliency 2 to overwhelm the target. Diagram o f a DDoS Attack There are seven layers in the Open Systems Interconnection (OSI) model and they are described in the Open Systems Interconnection (OSI) Model table . DDoS attacks are most common at layers three , four , six, and seven. Layer three and four a ttack s correspond to the Network and Transport layers of the OSI model. Within this paper, AWS refer s to these collectively as infrastructure layer attacks . Layer s six and seven attacks correspond to the Presentation and Application layers of the OSI model. AWS wi ll address these together as application layer attacks . E xamples of these attack types are discussed in the following sections. Open Systems Interconnection (OSI) Model # Layer Unit Description Vector Examples 7 Application Data Network process to application HTTP floods, DNS query floods 6 Presentation Data Data representation and encryption TLS abuse
PAGE – 8 ============
Amazon Web Services AWS Best Practices for DDoS Resiliency 4 Memcached, CharGen, or QOTD . For example, the amplification factor for DNS can be 28 to 54 times the original number of bytes. So, if an a ttacker sends a request payload of 64 bytes to a DNS server, they can generate over 3400 bytes of unwanted traffic to an attack target. UDP reflection attacks are accountable for larger volume of traffic in compar ison to other attacks . The UDP Reflection A ttack f igure illustrates the reflection tactic and amplification effect. UDP Reflection Attack SYN Flood Attacks When a user connects to a Transmission Control Protocol ( TCP ) service, such as a web server, their client sends a SYN synchronizatio n packet. The server returns a SYN – ACK packet in acknowledgement, and finally the client responds with an acknowledgement ( ACK ) packet, which completes the expected three – way handshake. The following im age illustrates this typical handshake.
PAGE – 9 ============
Amazon Web Services AWS Best Practices for DDoS Resiliency 5 SYN 3 – way Handshake In a SYN flood attack, a malicious client sends a large number of SYN packets, but never sends the final ACK packets to complete the handshakes. The server is left waiting for a response to the half – open TCP connections and eventually runs out of capacity to accept new TCP connections. This can prevent new users from connecting to the server. The attack is trying to t ie up available server connections so that resources are not available for legitimate connections . While SYN floods can reach up to hundreds o f Gbps, t he purpose of the attack is not to increase SYN traffic volume . Application Layer Attacks An attacker may target the application itself by using a layer 7 or application layer attack. In these attacks, similar to SYN flood infrastructure attacks, the attacker attempts to overload specific functions of an application to make the application unavailable or unresponsive to legitimate users. Sometimes this can be achieved with very low request volumes that generate only a small volume of network traffi c. This can make the attack difficult to detect and mitigate. Examples of application layer attacks include HTTP floods, cache – busting attacks, and WordPress XML – RPC floods. In an HTTP flood attack , an attacker sends HTTP requests that appear to be from a valid user of the web application. Some HTTP floods target a specific resource, while more complex HTTP floods attempt to emulate human interaction with the application.
PAGE – 10 ============
Amazon Web Services AWS Best Practices for DDoS Resiliency 6 This can increase the difficulty of using common mitigation techniques like request ra te limiting. Cache – busting attacks are a type of HTTP flood that use variations in the query string to circumvent content delivery network (CDN) caching. Instead of being able to return cached results, the CDN must contact the origin server for every page request, and these origin fetches cause additional strain on the application web server. With a WordPress XML – RPC flood attack , also known as a WordPress pingback flood, an attacker targets a website hosted on the WordPress content management software. The attacker misuses the XML – RPC API function to generate a flood of HTTP requests. The pingback feature allows a website hosted on WordPress (Site A) to notify a different WordPress site (Site B) through a link that Site A has created to Site B. Site B then attempts to fetch Site A to verify the existence of the link. In a pingback flood, the attacker misuses this capability to cause Site B to attack Site A. This type of attack has a clear signature: WordPress is typically present in the User – Agent of the HTT P request header. Scraper bots automate attempts to access a web application to steal content or record competitive information, such as pricing. Brute force and credential stuffing attacks are programmed efforts to gain unauthorized access to secure areas of an application. These are not strictly DDoS attacks; but their automated nature can look similar to a DDoS attack and they can be mitigated by implementi ng some of the same best practices covered in this paper. Application layer attacks can also target Domain Name System (DNS) services. The most common of these attacks is a DNS query flood in which an attacker uses many well – formed DNS queries to exhaust t he resources of a DNS server. These attacks can also include a cache – busting component where the attacker randomizes the subdomain string to bypass the local DNS cache of any given resolver. As a result, the resolver ueries and must instead repeatedly contact the authoritative DNS server, which amplifies the attack. If a web application is delivered over Transport Layer Security ( TLS ) , an attacker can also choose to attack the TLS negotiation process. TLS is computatio nally expensive so an attacker, by generating extra workload on the server to process unreadable d ata (or unintelligible (ciphertext)) as a legitimate handshake . In a variation of this attack, an attacker completes the TLS handshake but perpetually renegotiates the encryption method. A n attacker can alternatively attempt to exhaust server resources by opening and closing many TLS sessions.
PAGE – 11 ============
Amazon Web Services AWS Best Prac tices for DDoS Resiliency 7 Mitigation Techniques Some forms of DDoS mitigation are included automatically with A WS services. DDoS resilience can be improved further by using an AWS architecture with specific services , covered in the following sections, and by implementing additional best practices for each part of the network flow between users and your application . All AWS customers can benefit from the automatic protections of AWS Shield Standard at no additional charge. AWS Shield Standard defends against the most common and frequently occurring network and transport layer DDoS attacks that target your website or applications. This protection is always on, pre – configured, static, and provides no reporting or analytics. It is offered on all AWS services and in every AWS Region . In AWS Regions, DDoS attacks are detected and the Shield Standard system automatically ba selines traffic, identifies anomalies, and, as necessary, creates mitigations. You can use AWS Shield Standard as part of a DDoS – resilient architecture to protect both web and non – web applications. Y ou can also utilize AWS services that operate from edge l ocations, such as Amazon CloudFront , AWS Global Accelerator, and Amazon Route 53 to build comprehensive availability protection against all known infrastructure layer attacks. T hese services are part of the AWS Global Edge Network and can improve the DDoS resilienc y of your application when serv ing any type of application traffic from edge locations distributed around the world. You can run your application in any AWS Region and use these services to protect your application availability and optimize the pe rformance of your application for legitimate end users. B enefits of using CloudFront , AWS Global Accelerator, and Amazon Route 53 include: Access to internet and DDoS mitigation capacity across the AWS Global Edge Network. This is useful in mitigating larg er volumetric attacks, which can reach terabit scale. AWS Shield DDoS mitigation systems are integrated with AWS edge services, reducing time – to – mitigate from minutes to sub second. Stateless SYN Flood mitigation techniques proxy and verify incoming connec tions before passing them to the protected service. This ensures that only valid connections reach your application while protecting your legitimate end users against false positives drops.
29 KB – 35 Pages