当 DDoS 攻击流量汹涌而来,你的第一反应可能是“把流量引走”。但引到哪里?怎么引?这背后就是流量调度策略的博弈。从简单粗暴的“黑洞”到精细化的“清洗中心”,每一步都涉及取舍。本文结合 AWS 官方文档,梳理不同调度策略的适用场景、操作步骤和常见误区。
黑洞路由:最原始的“丢车保帅”
黑洞(Blackhole)路由是最简单的流量调度方式:将攻击目标 IP 的流量全部丢弃。在 AWS 中,你可以使用 VPC 网络 ACL 或安全组实现类似效果,但更典型的是在边界路由器上配置黑洞路由。它的优点是即时生效、成本极低,但缺点也很明显:合法用户也会被“误伤”,服务完全不可用。
在 AWS 的 DDoS 响应指南中,明确提到 AWS 会自动缓解第 3/4 层攻击,但对于第 7 层,默认不会自动缓解,以避免误伤合法流量。这暗示了黑洞策略的粗暴性——它通常是最后的手段,仅在攻击流量远超业务流量、且业务中断损失可接受时使用。
清洗中心:精细化调度的核心
清洗中心(Scrubbing Center)是更高级的调度策略:将可疑流量引流到专门的清洗设备,过滤掉攻击流量后,再将干净流量回注到源站。AWS 的 Shield Advanced 就提供了类似能力:当检测到攻击时,会自动将 VPC 网络 ACL 部署到 AWS 网络边界,以提供更大规模的防护。这实际上就是一种“引流”操作。
清洗调度的关键在于引流和回注。通常通过 BGP 路由通告实现:将目标 IP 的流量指向清洗设备,清洗后再通过隧道或专线回注。AWS 的全球基础设施天然支持 Anycast,可以将流量分散到多个边缘节点,这为清洗调度提供了基础。
典型场景:从攻击检测到调度决策
假设你的业务部署在 AWS 上,使用 EC2 实例。当攻击发生时,你会经历以下步骤:
- 检测告警:CloudWatch 监控到流量异常,触发告警。
- 评估影响:判断攻击类型和规模。如果主要是第 3/4 层洪水,AWS 会自动缓解;如果是第 7 层,需要手动介入。
- 选择调度策略:如果攻击规模不大,可以依赖 AWS 自动缓解;如果攻击持续且严重,可能需要启用 Shield Advanced 的自动部署网络 ACL,或者自行配置黑洞。
- 执行调度:根据策略,调整路由或 ACL 规则。
- 验证恢复:确认合法流量是否恢复,攻击是否被阻断。
这里的关键是:不要一开始就选择黑洞,而应优先考虑清洗。AWS 官方建议,对于第 7 层攻击,默认不自动缓解,因为可能误伤。因此,你需要自己提供缓解措施,比如配置 WAF 规则或使用第三方清洗服务。
取舍与失败条件
每种调度策略都有代价。黑洞的代价是业务完全中断;清洗的代价是成本和复杂度。清洗中心需要额外的带宽和设备,且引流和回注可能增加延迟。如果清洗设备自身被攻击,也会成为瓶颈。
失败条件也很明确:如果攻击流量超过清洗能力,或者调度配置错误(如回注路径不通),都会导致服务不可用。此外,如果攻击者直接攻击源站 IP(绕过清洗),调度策略就失效了。
常见误区
一个常见误区是认为“黑洞可以作为一种防护手段”。实际上,黑洞只是应急措施,长期使用会损害业务。另一个误区是“清洗中心可以完全替代其他防护”。AWS 的 Well-Architected 框架强调安全支柱,建议分层防护,而不是单一依赖流量调度。
还有一个误区是忽视第 7 层攻击的调度。很多团队只关注网络层,但应用层攻击(如 HTTP 洪水)需要更精细的调度,比如基于会话的引流。AWS 文档指出,对于第 7 层,默认不自动缓解,需要你主动配置。
如何选择调度策略?
选择策略时,你需要考虑:
- 攻击规模:小流量可用本地缓解,大流量需要清洗或黑洞。
- 业务容忍度:如果业务不能中断,优先清洗;如果可容忍,可考虑黑洞。
- 成本预算:清洗中心成本高,黑洞几乎免费。
- 自动化能力:AWS 提供了自动缓解,但第 7 层需要手动。
在 AWS 环境中,你可以结合 Shield Standard 和 Shield Advanced:前者自动缓解第 3/4 层,后者提供增强功能。根据 AWS 文档,Shield Standard 是默认开启的,而 Shield Advanced 需要付费订阅。
总结:调度是手段,不是目的
流量调度策略的目标是“在攻击下保持业务可用”。从黑洞到清洗中心,不是简单的升级,而是要根据场景选择。对于大多数业务,清洗中心是更优解,但需要投入。对于极端情况,黑洞是保底手段。理解这些策略的边界,才能在 DDoS 防护中游刃有余。
参考资料
延伸阅读
