亚马逊AWS官方博客

为你的游戏服务器加点“盐” – 利用 WAF+SALT 动态规则高效抵御七层 DDoS 攻击

导言

游戏行业长期以来一直是 DDoS 攻击的主要目标。DDoS 攻击具有来源广泛,强度大,攻击源分散等特点,使得其防御难度大大增加。相较于传统的 3/4 层 DDoS 攻击,7 层攻击更为隐蔽,流量更难标记,因此防范难度更高。在本篇博客中,我们将探索利用 WAF+SALT 动态规则来高效抵御七层 DDoS 攻击的解决方案。

DDoS 攻击概要

首先,让我们了解一下什么是 DDoS 攻击。DDoS 攻击利用互联网上大量的资源向某个目标服务发送请求,其目的是给目标服务资源造成压力,抢占正常用户的服务时间,从而导致服务不可用,影响攻击目标的客户体验。通常情况下,这些攻击资源大多来自于互联网上被感染的主机、路由器或 IoT 设备,因此往往具有地理位置分散的特点。这使得 DDoS 攻击不仅流量大,而且难以识别,无法通过简单地将某些 IP 地址加入黑名单来阻止攻击行为。在应用层,我们更多会遇到 HTTP Flood 和 HTTP Slowloris 等攻击。相较于 3/4 层的攻击,7 层的攻击手段更为丰富,因此防御应用层的 DDoS 攻击往往具有更高的难度。下面,我们来着重了解一下和本方案相关的两种攻击类型:

  • HTTP Flood – HTTP Flood 攻击是一种常见的 DDoS 攻击类型,旨在通过发送大量的 HTTP 请求来超载目标服务器,使其无法处理合法用户的请求。攻击者利用大量的合法 HTTP 请求发送到目标服务器,消耗其带宽和处理资源,从而使其无法正常提供服务。这种攻击通常涉及大量的僵尸计算机或恶意脚本,可以模拟大量的用户请求,造成服务器资源耗尽,导致服务不可用。
  • HTTP Slowloris – HTTP Slowloris 攻击旨在通过发送大量的半连接(Half-open connections)来占用服务器的连接资源,从而使其无法处理合法用户的请求。攻击者通过向目标服务器发送大量的 HTTP 请求,但是在建立连接后只发送部分请求头,而不完整发送 HTTP 请求,然后保持连接打开状态,不断发送字节以保持连接,同时又不完全发送 HTTP 请求,从而使服务器的连接资源被占用,导致服务器无法处理新的请求,最终导致服务不可用。Slowloris 攻击利用了服务器在等待完整的 HTTP 请求时会保持连接打开的特性,因此可以用较少的资源就能够造成服务器拒绝服务的情况。

方案相关的服务介绍

AWS WAF AWS WAF(Web Application Firewall)是亚马逊云科技的一款托管式网络安全服务。通过 Web 安全规则过滤或监控传入的七层流量,从而帮助用户缓解来自应用层的 DDoS 攻击。

WAF 服务的关键特性

  1. WAF 提供多层次的安全性防护。用户可以创建规则,根据多种条件(包括 IP 地址、HTTP 标头和正文,或自定义 URI)来筛选 Web 流量。
  2. WAF 是一个全托管的服务。在防护过程中所需的资源全部由系统自动提供,用户无需担心。同时,用户也可以直接使用 WAF 提供的防护规则。
  3. 支持自定义安全规则。用户也可以根据自身需求定义自己的安全规则。其灵活的规则引擎能够在个位数毫秒的延迟内检查传入请求的任何部分。
  4. WAF 对应用和架构没有任何侵入性。接入 WAF 无需修改应用程序或调整现有架构,甚至不需要配置 TLS 证书或更改 DNS 设置。

SALT(盐)

SALT 的概念源自加密领域,简单来说,它是一个随机的字符串。在用户首次向服务端注册时,服务端会将用户提供的密码与随机生成的 SALT 字符串拼接起来,并通过加密算法进行散列,最后将结果保存到数据库中。同时,SALT 也作为用户信息的一部分被保存下来。在用户登录时,服务端会提取用户的 SALT 值,将其与用户提供的密码进行拼接,并使用相同的加密算法进行散列,最后将结果与数据库中保存的密码进行比对,以验证密码的正确性。这种做法的好处在于,即使加密后的密码泄露,黑客也无法利用彩虹表进行逆向解密,从而无法获取到用户的原始密码。受到加密领域中 SALT 的启发,我们在 WAF 的 DDoS 防护中采用了类似的机制,以加强 WAF 规则的安全性。

WAF + SALT 动态防护规则的具体实现

首先,让我们回顾一下我们所面对的 DDoS 攻击问题。正如前面提到的,WAF 对攻击面的防护是多样的。在这里,我们将重点放在应用层的 DDoS 防护上,主要针对的是 HTTP Flood 泛洪攻击和 HTTP Slowloris 慢速攻击。

当前现有基于 WAF 的 DDoS 防护方案

架构图:

我们来看一个真实案例,这是一个游戏客户的安全防护架构。主体架构相对简单,客户端发送 HTTP 请求到 ALB(应用负载均衡器),然后 ALB 将请求转发到后端的 Lambda 服务进行处理。客户选择将 WAF 接入到 ALB 中,对客户端的 HTTP 请求进行过滤和筛选。筛选条件基于自定义的 Web ACL 规则:如果 HTTP 标头完全匹配某个特定值,则将请求放行转发到 ALB;如果不匹配该条件,则 WAF 将其直接过滤掉。

让我们想象一个情景:如果攻击者拦截并分析了客户端发送的请求信息,甚至破解了校验规则,即 HTTP 标头的值,攻击者就可以利用全球部署的被感染硬件资源模仿客户端,并结合已经破解的规则向服务端发送大量请求,从而进一步消耗服务端资源。这就是我们刚刚提到的应用层 HTTP Flood 泛红攻击,HTTP Slowloris 同理。在这种情况下,一旦 WAF 的静态规则被破解,就会失去防护能力,所有请求都会直接穿透 WAF 到达 ALB。

那么,如何增强 WAF 安全规则的安全性和防护能力呢?我们采用了为 WAF 规则加盐的方式,将其从静态规则转变为动态规则,从而实现更好的防护效果。

基于 WAF+SALT 的 DDoS 动态防护方案

让我们深入了解基于 WAF + SALT 的 DDoS 动态防护方案的具体架构和实施方式。

架构图 :

首先,请求处理的主体架构被保留,即 API Gateway、WAF 和 Lambda。在新方案中,我们增加了两个服务:CloudFront 和 S3。CloudFront 是内容分发网络,用于在边缘站点缓存静态/动态内容,而 S3 则是亚马逊云科技推出的对象存储服务,在这个架构中作为 CloudFront 的源站。架构整体是基于 Serverless 与 CDK 来开发实现的:

AWS  CDK: AWS CDK 是一种基础设施即代码(Infrastructure as Code)工具,通过编程语言(如 TypeScript、Python、Java 等)来定义云资源。本方案中所需的 AWS 全部服务资源是通过 CDK 进行创建和部署的,具体资源创建的代码细节,请参考 bootstrap.sh 文件。

基于这个架构,我们的目标是在受到应用层 DDoS 攻击时,能够自动更新 Web ACL 规则安全规则,并通过 S3 和 CloudFront 将更新同步给客户端。这样一来,我们不仅实现了 DDoS 防护,还确保了客户端的正常访问,达到了动态防护的目的。

需要说明的是,该方案需要客户端的配合。例如,当客户端在匹配规则更新后收到返回 403 的情况时,需要通过其实现的重试机制向 CloudFront 获取更新后的规则索引。

重要代码文件梳理:

  1. waf-config.json: 客户端和服务端共同维护的文件,当后端更新 rule index 时,客户端可以根据此文件中的 HeaderIndexValueMap 中找到对应的 rule value。
  2. bootstrap.sh: 通过这个脚本文件,CDK 资源的创建和部署得以自动化。执行完该脚本后,API Gateway、Lambda、WAF、CloudFront、S3 等资源会被创建。
  3. waf-updater.sh: 该脚本文件随机选择规则索引,并将其同步至 S3,S3 将规则索引缓存到 CloudFront 中,并生成新的 Web ACL rule。同时,脚本逻辑还包括使 CloudFront 缓存失效的操作,以确保客户端获取到最新的规则索引。

接下来,让我们思考一下当受到 DDoS 攻击时,新方案的整体防护流程会是怎样的?以刚刚提到的例子为例,当 header value 泄漏后,攻击者发起 HTTP Flood 攻击,此时:

  1. 架构流程图步骤 1.1 – 1.3: 游戏后端可以通过执行<waf-updater.sh>脚本文件,随机选择一个规则索引,生成新的 Web ACL 规则,将规则索引同步到 S3 中(规则索引以小文件对象的形式存储在 S3),并将其缓存到 CloudFront 中。随着新规则的变化,攻击者无法再利用先前获取的 header 信息顺利通过 WAF 的筛选。所有来自攻击者的请求都会被最新的 Web ACL 规则全部过滤掉,从而实现了防护效果。
  2. 架构流程图步骤 2.1 – 2.5: 客户端的正常访问会收到 403 错误,在重试机制的帮助下,客户端会主动访问 CloudFront 获取更新后的规则索引,然后在 waf-config 文件中找到对应的规则值,并将其添加到请求中。这样,客户端的访问就能够顺利通过 WAF 到达 ALB 进行后续处理。这一方案实现了保障用户正常访问的目的。

对于其他非游戏客户,也可以基于此方案进行扩展或裁剪,以达到应对七层网络攻击的目的。

那么,SALT 是如何在这个架构中体现的呢?其实,类似于 SALT 的机制体现在我们动态更新安全规则的过程中。换言之,方案中筛选条件的目标值是从一个特定的键-值映射中随机选取的,这就是为 WAF 加盐的过程。

基于这个优化思路,我们通过加盐的方式对该游戏客户的安全架构进行了优化,并在游戏上线后成功抵御了 DDoS 攻击。证明了这个方案的可靠性和有效性,为客户的游戏服务提供了可靠的保障,确保了游戏的正常运行和用户体验。

总结

本文探讨了游戏行业在面对 DDoS 攻击时的挑战,着重介绍了利用 WAF+SALT 动态规则进行七层 DDoS 攻击防御的解决方案。DDoS 攻击是利用互联网上大量资源向目标服务发送请求,造成服务压力,降低用户体验的行为。在应对 DDoS 攻击时,本文提出了基于 SALT 加盐的动态防护方案,通过动态更新安全规则,有效防范了攻击者对 WAF 静态规则的破解。并且,通过基于 Serverless 架构的 POC 示例,演示了如何通过 WAF+SALT 方案成功抵御 DDoS 攻击,确保了游戏服务的正常运行和用户体验。这一方案不仅适用于游戏行业,也可以为其他行业提供七层网络攻击防护的可行方案。

方案代码:https://github.com/esther1123/waf_salt

本篇作者

苏洁

亚马逊云科技资深解决方案架构师,负责互联网行业云端架构咨询和设计。

叶明

亚马逊云科技边缘产品架构师,负责 CloudFront 和 Global Accelerator 服务在中国和全球的市场拓展,专注于互联网用户访问云上服务的感受的优化以及数据洞察。在互联网基础设施领域有丰富的实践经验。