当攻击流量同时打在网络层和应用层时，单一防护手段往往顾此失彼。网络层 DoS（L3/L4）与 CC 攻击（L7）的清洗逻辑截然不同：前者靠容量和自动缓解，后者靠规则和人工干预。理解这两类攻击的边界，才能设计出有效的分层清洗方案。本文以 AWS 官方文档为依据，拆解各层级的应对机制。
先分清：网络层攻击与 CC 攻击的边界
网络层攻击（如 SYN Flood、UDP Flood）利用协议漏洞或大量流量耗尽带宽和连接表，目标是让服务不可达。而 CC 攻击（Challenge Collapsar）是应用层攻击，模拟真实用户请求，消耗服务器 CPU、数据库连接等资源，更难识别。AWS Shield 文档明确指出，Shield Standard 和 Advanced 分别覆盖 L3/L4 和 L7 的防护，但两者的处理方式完全不同。
L3/L4 自动缓解：无需人工干预的默认防线
AWS Shield Standard 会自动为所有 AWS 资源提供网络层（L3/L4）防护，无需额外配置。它持续检测流量，一旦发现异常，自动启动缓解措施，丢弃恶意流量。这种自动化是“分层清洗”的第一层：它不依赖人工，直接在内网边界阻断攻击。对于常见攻击向量（如 SYN Flood、UDP reflection），Shield 的检测算法能快速识别并缓解，甚至覆盖未知的零日攻击向量。
Shield Advanced 的增强：扩展清洗能力
如果业务对可用性要求极高，可以升级到 Shield Advanced。它提供更强的缓解能力，尤其是在攻击规模较大时。文档提到，当保护 EC2 实例时，Shield Advanced 会自动将 VPC 网络 ACL 部署到 AWS 网络边界，从而在更靠近攻击源的位置进行清洗。这意味着“分层清洗”的第二层：将防护边界前移，减少进入 VPC 的恶意流量，降低对内部资源的影响。
L7 攻击的困境：为什么不能全自动
应用层（L7）攻击则完全不同。AWS 文档明确说，默认情况下，Shield 不会自动对 L7 攻击应用缓解措施，因为误伤合法用户的风险太高。L7 攻击的流量特征与正常请求相似，自动阻断可能影响业务。因此，L7 防护需要“人工判断 + 规则配置”，这是分层清洗的第三层：在应用层通过 WAF 规则、速率限制、行为分析等手段，精准识别并阻断恶意请求。
可执行的 L7 应对策略
根据 AWS 的事件响应指南，应对 L7 攻击有几种选择：
- 自定义缓解：在 WAF 中配置规则，例如基于 IP 速率限制、地理位置过滤、验证码挑战等。
- 使用托管规则：利用 AWS 托管规则集，快速封禁常见攻击模式（如 SQL 注入、XSS）。
- 扩展资源：临时增加后端容量，吸收攻击流量，为缓解争取时间。
- 结合 CDN：将静态内容缓存到边缘节点，减少源站压力，同时利用 CDN 的清洗能力。
这些策略并非互斥，而是可以组合使用。例如，先通过 CDN 过滤大部分流量，再在源站 WAF 层做精细控制。
分层清洗的总体架构
结合 AWS 的实践，一个完整的分层清洗方案应包含：
- 网络层自动缓解：依赖云服务商（如 AWS Shield）的 L3/L4 防护，自动清洗大流量攻击。
- 边缘清洗：通过 CDN 或 Anycast 网络，在靠近用户的位置分散和过滤流量，减轻源站压力。
- 应用层精细控制：在 WAF 层配置规则，识别并阻断恶意请求，同时允许合法流量通过。
- 监控与响应：设置 CloudWatch 告警，及时感知攻击，并制定应急响应预案。
每一层都有明确的职责和边界，层层递进，才能有效防御混合型攻击。
常见误区与失败条件
很多团队在设计防护时容易陷入几个误区：
- 只依赖单一层：以为网络层清洗可以解决一切，结果 CC 攻击穿透到应用层，导致服务不可用。
- 过度依赖自动缓解：在 L7 层也期望全自动，但自动规则可能误伤正常用户，造成业务损失。
- 忽视监控：没有配置告警，攻击发生后数小时才发现，错过了最佳响应时机。
分层清洗方案失败的条件通常包括：未明确各层职责、缺乏人工干预机制、监控告警缺失等。因此，务必根据业务特点，合理配置每一层。
总结与行动建议
网络层 DoS 与 CC 攻击的分层清洗，核心在于理解 L3/L4 与 L7 的差异，并分别采用自动和手动策略。AWS 的实践表明，网络层自动缓解是基础，应用层精细控制是关键。建议您：
- 评估当前业务是否启用了云服务商的基础 DDoS 防护（如 AWS Shield Standard）。
- 对于关键业务，考虑升级到高级防护（如 Shield Advanced），并配置 WAF 规则。
- 建立监控告警和应急响应流程，确保攻击发生时能快速介入。
分层清洗不是一次性配置，而是持续优化的过程。根据攻击趋势和业务变化，定期调整规则和容量，才能保持防御有效性。
参考资料
延伸阅读