AWS防ddos的架构
DDoS 弹性的 AWS 最佳实践 (opens new window)
# 什么是DDOS攻击
# DoS
拒绝服务 (DoS) 攻击是蓄意使用户无法访问网站或应用程序的尝试，例如通过向其注入大量网络流量。攻击者使用各种消耗大量网络带宽或占用其他系统资源的技术，从而中断合法用户的访问。在其最简单的形式中，单独的攻击者使用单一来源对目标执行 DoS 攻击，如下图所示。
# DDoS
在分布式拒绝服务 (DDoS) 攻击中，攻击者使用多个来源来编排针对目标的攻击。这些来源可能包括受恶意软件感染的计算机、路由器、IoT 设备和其他端点的分布式组。下图显示了参与攻击的受感染主机网络，生成大量数据包或请求来淹没目标。
# DDos攻击方式
开放系统互连 (OSI) 模型中有七层。DDoS 攻击最常见于第 3、4、6 和 7 层。
- 第三层和第四层攻击对应于 OSI 模型的网络层和传输层。AWS 将这些统称为基础设施层攻击。
- 第六层和第七层攻击对应于 OSI 模型的表示层和应用层。AWS 将这些作为应用程序层攻击一起解决。
OSI 模型
| # | 层 | 单元 | 描述 | 示例 |
|---|---|---|---|---|
| 7 | 应用层 | Data | 网络流程到应用 | HTTP 泛洪、DNS 查询泛洪 |
| 6 | 表示层 | Data | 数据表示和加密 | 传输层安全 (TLS) 滥用 |
| 5 | 会话层 | Data | 宿主间通讯 | N/A |
| 4 | 传输层 | Segments | 端到端连接和可靠性 | 同步 (SYN) 泛洪 |
| 3 | 网络层 | Packets | 路径确定和逻辑寻址 | 用户数据报协议 (UDP) 反射攻击 |
| 2 | 数据链路层 | Frames | 物理寻址 | N/A |
| 1 | 物理层 | Bits | 媒体、信号和二进制传输 | N/A |
# 基础设施层攻击
最常见的 DDoS 攻击、用户数据报协议 (UDP) 反射攻击和 SYN 泛洪都是基础设施层攻击。攻击者可以使用这两种方法中的任何一种来生成大量流量，这些流量可能会淹没网络容量或占用服务器、防火墙、入侵防御系统 (IPS) 或负载平衡器等系统上的资源。虽然这些攻击很容易识别，但要有效地缓解它们，必须拥有一个比入站流量洪流更快地扩展容量的网络或系统。这种额外的容量是过滤或吸收攻击流量所必需的，从而释放系统和应用程序以响应合法的客户流量。
# UDP反射攻击
UDP 反射攻击利用了 UDP 是无状态协议这一事实。
- 攻击者可以制作一个有效的 UDP 请求数据包，将攻击目标的 IP 地址列为 UDP 源 IP 地址。
- 攻击者现已伪造（欺骗）UDP 请求数据包的源 IP。UDP 数据包包含欺骗源 IP，由攻击者发送到中间服务器。
- 服务器被诱骗将其 UDP 响应数据包发送到目标受害者 IP，而不是返回到攻击者的 IP 地址。
使用中间服务器是因为它会生成比请求数据包大数倍的响应，有效放大发送到目标 IP 地址的攻击流量。
放大系数是响应大小与请求大小的比率，它取决于攻击者使用的协议：DNS、网络时间协议 (NTP)、简单服务目录协议 (SSDP)、无连接轻量级目录访问协议 (CLDAP)、内存缓存 (opens new window)、字符生成器协议 (CharGen) 或每日报价 (QOTD)。
例如，DNS 的放大系数可以是原始字节数的 28 到 54 倍。因此，如果攻击者向 DNS 服务器发送 64 字节的请求有效载荷，他们可能会向攻击目标生成超过 3400 字节的不需要的流量。与其他攻击相比，UDP 反射攻击会导致更大的流量。下图说明了反射策略和放大效果。
# SYN 洪水攻击
当用户连接到传输控制协议 (TCP) 服务（例如 Web 服务器）时，他们的客户端会发送一个 SYN 数据包。服务器返回同步确认（SYN-ACK）数据包，最后客户端以确认（ACK）数据包响应，完成预期的三次握手。下图说明了这种典型的握手。
在 SYN 泛洪攻击中，恶意客户端发送大量 SYN 数据包，但从未发送最终的 ACK 数据包来完成握手。服务器等待对半开 TCP 连接的响应，最终耗尽容量来接受新的 TCP 连接。这可以防止新用户连接到服务器。攻击试图占用可用的服务器连接，使资源无法用于合法连接。虽然 SYN 泛洪可以达到每秒数千亿比特 (Gbps)，但攻击的主要目的不是增加 SYN 流量。
# 应用层攻击
攻击者可以通过使用第 7 层或应用程序层攻击来瞄准应用程序本身。在这些攻击中，类似于 SYN 泛洪基础设施攻击，攻击者试图使应用程序的特定功能过载，使应用程序对合法用户不可用或无响应。有时，这可以通过仅生成少量网络流量的非常低的请求量来实现。这会使攻击难以检测和缓解。应用层攻击的示例包括 HTTP 泛洪攻击、缓存破坏攻击等。
# HTTP 泛洪攻击
在HTTP 泛洪攻击中，攻击者发送的 HTTP 请求看似来自 Web 应用程序的有效用户。一些 HTTP 泛洪针对特定资源，而更复杂的 HTTP 泛洪则试图模拟人类与应用程序的交互。这会增加使用请求速率限制等常见缓解技术的难度。
# 缓存破坏攻击
缓存破坏攻击是一种 HTTP 泛洪攻击，它使用查询字符串的变体来规避内容分发网络 (CDN) 缓存。CDN 必须为每个页面请求联系原始服务器，而不是能够返回缓存的结果，而这些原始提取会给应用程序 Web 服务器带来额外的压力。
还有其他形式的恶意流量会影响应用程序的可用性。 爬虫机器人会自动尝试访问 Web 应用程序以窃取内容或记录竞争信息，例如定价。蛮力和撞库攻击是经过编程的努力，旨在未经授权访问应用程序的安全区域。这些并不是严格意义上的 DDoS 攻击；但它们的自动化性质看起来类似于 DDoS 攻击，并且可以通过实施本文中介绍的一些相同的最佳实践来缓解它们。
应用层攻击还可以针对域名系统 (DNS) 服务。这些攻击中最常见的是DNS 查询泛滥，攻击者使用许多格式良好的 DNS 查询来耗尽 DNS 服务器的资源。这些攻击还可能包括缓存破坏组件，攻击者在其中随机化子域字符串以绕过任何给定解析器的本地 DNS 缓存。因此，解析器无法利用缓存的域查询，而必须反复联系权威 DNS 服务器，从而放大了攻击。
如果 Web 应用程序是通过传输层安全性 (TLS) 交付的，攻击者还可以选择攻击 TLS 协商过程。TLS 的计算成本很高，因此攻击者通过在服务器上产生额外的工作负载来处理不可读的数据（或无法理解的（密文）作为合法的握手），可以降低服务器的可用性。在这种攻击的变体中，攻击者完成 TLS 握手但永久重新协商加密方法。攻击者可以选择通过打开和关闭许多 TLS 会话来尝试耗尽服务器资源。
# AWS提供的缓解技术
某些形式的 DDoS 缓解措施自动包含在 AWS 服务中。通过使用具有特定服务的 AWS 架构（在以下部分中介绍），以及通过为用户和您的应用程序之间的网络流的每个部分实施额外的最佳实践，可以进一步提高 DDoS 弹性。
所有 AWS 客户都可以免费使用AWS Shield Standard的自动保护。AWS Shield Standard 可抵御针对您的网站或应用程序的最常见和频繁发生的网络和传输层 DDoS 攻击。这种保护始终开启、预先配置、静态，并且不提供报告或分析。它在所有 AWS 服务和每个AWS 区域提供。在 AWS 区域中，会检测到 DDoS 攻击，Shield Standard 系统会自动为流量设定基线，识别异常，并在必要时创建缓解措施。您可以使用 AWS Shield Standard 作为 DDoS 弹性架构的一部分来保护 Web 和非 Web 应用程序。
您还可以利用从边缘位置运行的 AWS 服务（例如 Amazon CloudFront、AWS Global Accelerator 和 Amazon Route 53）来构建针对所有已知基础设施层攻击的全面可用性保护。这些服务是AWS 全球边缘网络的一部分，并且可以在为来自分布在世界各地的边缘位置的任何类型的应用程序流量提供服务时提高应用程序的 DDoS 弹性。您可以在任何 AWS 区域运行您的应用程序，并使用这些服务来保护您的应用程序可用性并为合法最终用户优化您的应用程序的性能。
使用 Amazon CloudFront、Global Accelerator 和 Amazon Route 53 的优势包括：
- 跨 AWS 全球边缘网络访问互联网和 DDoS 缓解能力。这对于减轻可以达到太比特级的更大的容量攻击很有用。
- AWS Shield DDoS 缓解系统与 AWS 边缘服务集成，将缓解时间从几分钟缩短到亚秒级。
- 无状态 SYN Flood 缓解技术在将传入连接传递给受保护服务之前代理和验证传入连接。这可确保只有有效连接才能到达您的应用程序，同时保护您的合法最终用户免受误报。
- 自动流量工程系统，可分散或隔离大量 DDoS 攻击的影响。所有这些服务在攻击到达您的来源之前就在源头隔离攻击，这意味着对受这些服务保护的系统的影响更小。
- 与AWS Web 应用程序防火墙(AWS WAF)结合使用时的应用程序层防御，不需要更改当前应用程序架构（例如，在 AWS 区域或本地数据中心）。
AWS 上的入站数据传输不收费，您无需为 AWS Shield 缓解的 DDoS 攻击流量付费。以下架构图包括 AWS 全球边缘网络服务。
抗 DDoS 参考架构
该架构包括多项 AWS 服务，可帮助您提高 Web 应用程序抵御 DDoS 攻击的弹性。最佳实践摘要表提供了这些服务及其可以提供的功能的摘要。
表 2 - 最佳实践总结
| AWS 边缘 | AWS 区域 | |||||
|---|---|---|---|---|---|---|
| 将 Amazon CloudFront (BP1) 与 AWS WAF (BP2) 结合使用 | 使用全球加速器 (BP1) | 使用亚马逊 Route 53 (BP3) | 将 Elastic Load Balancing (BP6) 与 AWS WAF (BP2) 结合使用 | 在 Amazon VPC (BP5) 中使用安全组和网络 ACL | 使用亚马逊弹性计算云（亚马逊 EC2）自动缩放(BP7) | |
| 第 3 层（例如 UDP 反射）攻击缓解 | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ |
| 第 4 层（例如 SYN 泛洪）攻击缓解 | ✔ | ✔ | ✔ | ✔ | ||
| 第 6 层（例如，TLS）攻击缓解 | ✔ | ✔ | ✔ | ✔ | ||
| 减少攻击面 | ✔ | ✔ | ✔ | ✔ | ✔ | |
| 扩展以吸收应用层流量 | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ |
| 第 7 层（应用层）攻击缓解 | ✔ | ✔(*) | ✔ | ✔ | ✔(*) | ✔(*) |
| 过剩流量和更大规模 DDoS 攻击的地理隔离和分散 | ✔ | ✔ | ✔ | |||
| ✔(*)：如果与带有AWS WAF的Application Load Balancer 一起使用 |
# DDoS 缓解的最佳实践
# 基础设施层防御（BP1、BP3、BP6、BP7）
在传统的数据中心环境中，您可以通过使用过度配置容量、部署 DDoS 缓解系统或借助 DDoS 缓解服务清理流量等技术来缓解基础设施层 DDoS 攻击。
在 AWS 上，自动提供 DDoS 缓解能力；但您可以通过做出最能利用这些功能的架构选择来优化应用程序的 DDoS 弹性，并允许您针对过剩流量进行扩展。
# 弹性负载平衡 (BP6)
大型 DDoS 攻击可能会压垮单个 Amazon EC2 实例的容量。借助 Elastic Load Balancing (ELB)，您可以通过在多个后端实例之间分配流量来降低应用程序过载的风险。Elastic Load Balancing 可以自动扩展，允许您在遇到意外的额外流量时管理更大的容量，例如，由于突发人群或 DDoS 攻击。对于在 Amazon VPC 中构建的应用程序，根据您的应用程序类型，可以考虑三种类型的 ELB：应用程序负载均衡器 (ALB)、经典负载均衡器 (CLB) 和网络负载均衡器 (NLB)。
对于 Web 应用程序，您可以使用 Application Load Balancer 根据内容路由流量并仅接受格式良好的 Web 请求。Application Load Balancer 可阻止许多常见的 DDoS 攻击，例如 SYN 泛洪攻击或 UDP 反射攻击，从而保护您的应用程序免受攻击。当检测到这些类型的攻击时，Application Load Balancer 会自动扩展以吸收额外的流量。由于基础设施层攻击而导致的扩展活动对 AWS 客户是透明的，不会影响您的账单。
对于基于 TCP 的应用程序，您可以使用网络负载均衡器以超低延迟将流量路由到目标（例如，Amazon EC2 实例）。网络负载均衡器的一个关键考虑因素是，任何到达有效侦听器上的负载均衡器的流量都将路由到您的目标，而不是被吸收。
# 使用 AWS 边缘站点进行扩展（BP1、BP3）
访问大规模、多样化的 Internet 连接可以显着提高您优化用户延迟和吞吐量、吸收 DDoS 攻击和隔离故障的能力，同时最大限度地减少对应用程序可用性的影响。AWS 边缘位置提供额外的网络基础设施层，为使用 Amazon CloudFront、Global Accelerator 和 Amazon Route 53 的任何 Web 应用程序提供这些优势。借助这些服务，您可以在边缘全面保护从 AWS 区域运行的应用程序。
# 边缘 Web 应用程序交付 (BP1)
Amazon CloudFront 是一项可用于交付整个网站的服务，包括静态、动态、流媒体和交互式内容。持久连接和可变生存时间 (TTL) 设置可用于从您的来源卸载流量，即使您没有提供可缓存的内容。使用这些 CloudFront 功能可减少返回源的请求和 TCP 连接的数量，从而帮助保护您的 Web 应用程序免受 HTTP 泛洪攻击。
CloudFront 仅接受格式正确的连接，这有助于防止许多常见的 DDoS 攻击（例如 SYN 泛洪和 UDP 反射攻击）到达您的源。DDoS 攻击也在地理上隔离在源头附近，从而防止流量影响其他位置。这些功能可以极大地提高您在大型 DDoS 攻击期间继续为用户提供流量的能力。您可以使用 CloudFront 来保护 AWS 上或互联网上其他地方的来源。
如果您使用的是亚马逊简单存储服务(Amazon S3) 在 Internet 上提供静态内容，AWS 建议您使用 Amazon CloudFront 来保护您的存储桶。您可以使用源访问标识 (OAI) 来确保用户只能使用 CloudFront URL 访问您的对象。
# 边缘域名解析 (BP3)
Amazon Route 53 是一种高度可用且可扩展的域名系统 (DNS) 服务，可用于将流量定向到您的 Web 应用程序。它包括高级功能，如流量、健康检查和监控、基于延迟的路由和 Geo DNS。这些高级功能允许您控制服务如何响应 DNS 请求以提高 Web 应用程序的性能并避免站点中断。
Amazon Route 53 使用随机分片和任播条带化等技术，即使 DNS 服务成为 DDoS 攻击的目标，也可以帮助用户访问您的应用程序。
使用随机分片，委托集中的每个名称服务器都对应一组独特的边缘位置和互联网路径。这提供了更大的容错能力并最大限度地减少了客户之间的重叠。如果委托集中的一个名称服务器不可用，用户可以重试并接收来自不同边缘位置的另一个名称服务器的响应。
任播条带化允许每个 DNS 请求由最佳位置提供服务，从而分散网络负载并减少 DNS 延迟。这为用户提供了更快的响应。此外，Amazon Route 53 可以检测 DNS 查询的来源和数量中的异常情况，并优先考虑来自已知可靠的用户的请求。
# 应用层防御（BP1、BP2）
到目前为止，本文讨论的许多技术都可以有效减轻基础设施层 DDoS 攻击对应用程序可用性的影响。为了同时抵御应用层攻击，您需要实施一种架构，使您能够专门检测、扩展以吸收和阻止恶意请求。这是一个重要的考虑因素，因为基于网络的 DDoS 缓解系统通常无法有效缓解复杂的应用程序层攻击。
# 检测和过滤恶意 Web 请求（BP1、BP2）
当您的应用程序在 AWS 上运行时，您可以同时利用 Amazon CloudFront 和 AWS WAF 来帮助抵御应用程序层 DDoS 攻击。
Amazon CloudFront 允许您缓存静态内容并从 AWS 边缘位置提供它，这有助于减少源站的负载。它还可以通过防止非网络流量到达您的来源来帮助减少服务器负载。此外，CloudFront 可以自动关闭来自慢读或慢写攻击者的连接（例如，Slowloris (opens new window)).
通过使用 AWS WAF，您可以在 CloudFront 分配或 Application Load Balancer 上配置 Web 访问控制列表 (Web ACL)，以根据请求签名过滤和阻止请求。每个 Web ACL 都包含规则，您可以将这些规则配置为字符串匹配或正则表达式匹配一个或多个请求属性，例如统一资源标识符 (URI)、查询字符串、HTTP 方法或标头键。此外，通过使用 AWS WAF 基于速率的规则，当与规则匹配的请求超过您定义的阈值时，您可以自动阻止不良行为者的 IP 地址。
来自违规客户端 IP 地址的请求将收到 403 Forbidden 错误响应，并将一直被阻止，直到请求率降至阈值以下。这对于减轻伪装成常规 Web 流量的 HTTP 泛洪攻击很有用。
# 减少攻击面
构建 AWS 解决方案时的另一个重要考虑因素是限制攻击者以您的应用程序为目标的机会。这个概念被称为攻击面减少。未暴露在 Internet 上的资源更难受到攻击，这限制了攻击者针对您的应用程序可用性的选择。
例如，如果您不希望用户直接与某些资源交互，请确保无法从 Internet 访问这些资源。同样，不要在通信不需要的端口或协议上接受来自用户或外部应用程序的流量。
在下一节中，AWS 提供了最佳实践来指导您减少攻击面并限制应用程序的 Internet 暴露。
# 混淆 AWS 资源（BP1、BP4、BP5）
通常，用户可以快速轻松地使用应用程序，而无需将 AWS 资源完全暴露在互联网上。例如，当您在 Elastic Load Balancing 后面拥有 Amazon EC2 实例时，实例本身可能不需要可公开访问。相反，您可以在某些 TCP 端口上为用户提供对 Elastic Load Balancing 的访问权限，并只允许 Elastic Load Balancing 与实例通信。您可以通过在 Amazon Virtual Private Cloud (Amazon VPC) 中配置安全组和网络访问控制列表 (NACL) 来进行设置。Amazon VPC 允许您预置 AWS 云的逻辑隔离部分，您可以在其中在您定义的虚拟网络中启动 AWS 资源。
# 安全组和网络 ACL (BP5)
您可以选择是在启动实例时指定安全组，还是稍后将实例与安全组相关联。除非您创建允许流量的允许规则，否则流向安全组的所有 Internet 流量都会被隐式拒绝。
例如，如果您有一个使用 Elastic Load Balancing 和多个 Amazon EC2 实例的 Web 应用程序，您可能决定为 Elastic Load Balancing 创建一个安全组（Elastic Load Balancing 安全组），为实例（Web 应用程序服务器）创建一个安全组安全组）。然后，您可以创建一个允许规则以允许 Internet 流量流向 ELB 安全组，并创建另一个规则以允许从 ELB 安全组到 Web 应用程序服务器安全组的流量。这可确保互联网流量无法直接与您的 Amazon EC2 实例通信，从而使攻击者更难了解和影响您的应用程序。
创建网络 ACL 时，您可以指定允许和拒绝规则。如果您想明确拒绝某些类型的流量到您的应用程序，这将很有用。例如，您可以定义拒绝访问整个子网的 IP 地址（作为 CIDR 范围）、协议和目标端口。如果您的应用程序仅用于 TCP 流量，您可以创建一个规则来拒绝所有 UDP 流量，反之亦然。此选项在响应 DDoS 攻击时很有用，因为它允许您在知道源 IP 或其他签名时创建自己的规则来减轻攻击。
# 保护您的来源（BP1、BP5）
如果您将 Amazon CloudFront 与位于您的 VPC 内的源一起使用，您可能希望确保只有您的 CloudFront 分配可以将请求转发到您的源。使用边缘到源请求标头，您可以在 CloudFront 将请求转发到您的源时添加或覆盖现有请求标头的值。您可以使用Origin 自定义标头（例如X-Shared-Secret标头）来帮助验证对您的源发出的请求是否从 CloudFront 发送。
或者，您可以使用AWS Lambda (opens new window)功能自动更新您的安全组规则以仅允许 CloudFront 流量。这有助于确保恶意用户在访问您的 Web 应用程序时无法绕过 CloudFront 和 AWS WAF，从而提高源的安全性。
# AWS Shield Advanced
使用 AWS Shield Advanced您会收到基于以下内容的定制检测：
- 您的应用程序的特定流量模式。
- 抵御包括 AWS WAF 在内的第 7 层 DDoS 攻击，无需额外费用。
- 从AWS Shield 响应团队(AWS SRT)获得 24x7 专业支持。
- 通过AWS Firewall Manager集中管理安全策略.
- 成本保护以防止因与 DDoS 相关的使用高峰而产生的扩展费用。
这种可选的 DDoS 缓解服务有助于保护托管在任何 AWS 区域上的应用程序。该服务可在全球范围内用于 CloudFront、Route 53 和 Global Accelerator。将 Shield Advanced 与弹性 IP 地址结合使用可让您保护网络负载均衡器(NLB) 或Amazon EC2实例。
使用 AWS Shield Advanced 的好处包括：
- 访问 AWS SRT 以帮助减轻影响应用程序可用性的 DDoS 攻击。
- 使用AWS 管理控制台的DDoS 攻击可见性、API 以及 Amazon CloudWatch指标和警报。
- 访问过去 13 个月所有 DDoS 事件的历史记录。
- 访问 AWS Web 应用程序防火墙 (AWS WAF)，无需额外费用即可缓解应用程序层 DDoS 攻击（与 Amazon CloudFront 或 Application Load Balancer 一起使用时）。
- 与 AWS WAF 一起使用时，Web 流量属性的自动基线。
- 无需额外费用即可访问 AWS Firewall Manager，以实现自动策略实施。
- 敏感检测阈值可更早地将流量路由到 DDoS 缓解系统，并且在与弹性 IP 地址一起使用时可以缩短缓解针对 Amazon EC2 或网络负载均衡器的攻击的时间。
- 成本保护使您能够请求对因 DDoS 攻击导致的扩展相关成本进行有限退款。
- 特定于 AWS Shield Advanced 客户的增强服务级别协议。
- 当检测到 Shield 事件时，AWS SRT 主动参与。
- 使您能够捆绑资源的保护组，通过将多个资源视为一个单元来提供一种自助服务方式来为您的应用程序自定义检测和缓解范围。资源分组提高了检测的准确性，最大限度地减少了误报，简化了对新创建资源的自动保护，并加快了缓解对包含单个应用程序的许多资源的攻击的时间。有关保护组的信息，请参阅Shield Advanced 保护组。
# 总结
AWS Shield Advanced需要每月3000$，我们按照AWS推荐的架构，基本也能实现相应的功能。
AWS推荐的架构默认了提供 DDoS 缓解能力，对于小型的DDoS攻击基本无感知。
目前我们除了没有使用到WAF，使用的架构都基于推荐的架构。
- Route 53
- CloudFront
- VPC
- Security Groups
- Elastic Load Balancing
- EC2 Auto Scaling
因为按照我们目前的使用量，时刻开启WAF每月将增加500$左右的费用。
我们有准备一些WAF规则，有问题时可以自动配置上去，生效需要时间（不到1分钟）。
需要做的事情：
将现有的所有静态页面全部部署在s3。
增强监控告警能力，提前发现，提前处理。
增强自动化能力，发现问题时自动配置规则，自动扩容。
将多平台统一，简化一些不能自动化的操作。比如防火墙配置。
程序上的优化，更快的处理。
其他：如更细致的防火墙配置、搭建VPN、设置更强的密码、定时更换密码等。