DDoS 攻击，超低成本不止于网络传输层

网络世界里为人们所熟知的攻击 DDoS 攻击，多数是绝地通过对带宽或网络计算资源的持续、大量消耗
，防护最终导致目标网络与业务的超低成本瘫痪；这类 DDOS 攻击 ，工作在 OSI 模型的攻击网络层与传输层，利用协议特点构造恶意的绝地请求载荷来达成目标资源耗尽的目的
。

除了这类在网络传输层大做文章的防护 DDoS 攻击，模板下载还有一类 DDoS 攻击把目光聚焦到了应用层。超低成本随着互联网的攻击飞速发展
，接入流量逐年攀高，绝地承载这些流量的防护网络应用也被黑产 、黑客们盯上
，超低成本在 DDoS 攻击场景中也不例外。攻击

由于应用层流量更贴近业务逻辑，绝地在应用层发起 DDoS 攻击可以同时对目标网络与目标服务器的稳定性造成威胁 。除此之外，攻击者往往只需较小的带宽成本，实现更大的破坏效果 ，高防服务器这样的不对称性自然更受攻击者们的关注与青睐。

Cloudflare 在 《DDoS Attack Trends for 2022 Q1》报告指出，全球范围内应用层 DDoS 攻击(主要是 HTTP DDoS)呈现着持续增长的态势
。在俄乌的网络战争中，HTTP DDoS 攻击也扮演着重要的角色。

与此同时
，应用层 DDoS 攻击的攻击方式与手法在也在不断演进升级。从集中式高频请求逐步演进为分布式低频请求 ，从请求报文中携带显著恶意特征变化为重放合法请求流量，建站模板伪造搜索引擎爬虫流量等；而在攻击的频率与规模上
，应用层 DDoS 攻击也呈现出不断增长的趋势 。

针对攻击手法的升级变化，业务防护可以从两方面着手应对 ：一是在运营对抗上，在攻击发生的事前、事中和事后各阶段 ，通过梳理资产信息、分析攻击报文并进行特征提取、配置防护策略、复盘防护数据等手段不断提升防护对抗效果；二是在防护能力建设上 ，免费模板可以引入支持多维度特征组合的限速功能 、JS Challenge、验证码等功能模块来提升对高级复杂的应用层 DDoS 攻击的识别处置能力。与此同时，在流量接入链路中与 CDN 、LB 、AGW 等各接入层产品进行联动合作，通过在不同接入层级落地相关防护策略，实现攻击流量的分级收敛，在应对大规模应用层 DDoS 攻击时更能凸显防护效果。

0 门槛，高收益，源码下载一键发起攻击

上面提到的应用层 DDoS 攻击，是通过向应用程序发送大量恶意请求实现攻击效果
，以每秒请求数 (QPS) 来衡量攻击量级与规模；这类攻击也称为 7 层 DDoS 攻击  ，可针对和破坏特定的网络应用程序 ，而非整个网络。虽然这类 DDoS 攻击难以预防和抵御，但发动起来却相对比较容易，具体有多容易呢？

由于 7 层 DDoS 通常不需要过高的带宽成本，也无需构造复杂的协议利用报文  ，在黑灰产交易渠道，可以非常便捷地获取到发起 7 层 DDoS 的服务器租用工具与服务 。

即便是知名 、成熟的互联网应用 ，在这类攻击面前也存在被攻陷的可能与风险。

HTTP DDoS 攻击的类型与特点

攻击类型

7 层 DDoS 攻击中 ，瘫痪目标应用与服务是首要目标 ，根据 HTTP DDoS(CC)攻击发起的原理与方式 ，可以总结以下攻击类型
：

HTTP floods

这种攻击主要分为两种形式。第一种是 HTTP GET request floods ，攻击者通过构造 HTTP GET 请求报文，向目标服务器发送针对特定资源的大量请求
。在客户端执行一条 HTTP 请求的成本很低，但是目标服务器做出对应的响应成本却可能很高
。比如加载一个网页，服务端通常需要加载多个文件、查询数据库等才能做出响应；在 Web 业务的防护中，对于有 SSR(Server-side rendering)功能页面的 HTTP floods 攻击，其量级与频率更加突出明显，也更容易对业务造成影响与危害。

第二种是 HTTP POST request floods，与 GET request floods 的显著区别是，POST 请求往往需要携带表单参数或请求体信息，而这通常意味着服务端需要对请求内容进行相关解析处理，并将数据进行持久化(通常需要进行 DB 操作) 。发送 POST 请求一般仅需较小的计算与带宽成本 ，而服务端进行处理操作的过程往往消耗更高
。可以说这种攻击形式下，形成这种请求响应间资源消耗差异的空间或可能性更大，更容易实现让服务器过载从而拒绝服务的目标 。

Large Payload POST requests

这类攻击一般通过 POST 方法发送容量大、结构复杂的请求体到目标服务器，使得目标服务器在解析这些请求内容的过程发生过载(CPU 或内存)；一般而言，攻击者通过构造特定的序列化请求体，如 xml、json 等，在服务端执行反序列化操作时引起服务过载 。

Asymmetric requests

这种类型的攻击顾名思义，利用的就是请求与响应的非对称性，请求的目标路径会执行高消耗操作而发起攻击请求轻而易举。通常来说  ，这类攻击需要对目标服务有一定的熟悉与了解，明确攻击目标哪些地方存在这种非对称性利用的可能及利用方式 。比如通过从数据库服务器下载大型文件或大量执行数据库的查询等接口，就容易被这种类型攻击所利用。

Low&Slow attack(Slowloris/Slow Post/Read attack)

这种类型的攻击更多是面向连接层面 ，以基于线程的 Web 服务器为目标，通过慢速请求来捆绑每个服务器线程 ，从而消耗服务器的线程&连接资源，这类攻击中主要可分为 Slowloris 、Slow Post/Read 几种攻击方式。

攻击特点

根据上述总结的 HTTP DDoS 攻击类型、原理与实现方式，可以总结出 HTTP DDoS 攻击具备以下特点：

攻击门槛 、成本低

相较于 4 层 DDoS 攻击，发起 HTTP DDoS 攻击往往无需构造复杂的攻击报文，仅需较少的带宽就能实现强大的攻击效果 
。

攻击目标更精细

攻击的目标可以精细到服务接口粒度
，例如直播页面等
，而不需要瘫痪目标的网络也能让业务出现拒绝服务。

破坏范围广，危害程度高

虽然 HTTP DDoS 攻击的首要目标是瘫痪目标服务，但并不意味着对目标网络的可用性没有威胁。当 HTTP floods 量级到一定程度时，也存在瘫痪请求接入层网络的可能性 。

攻击源分布广，隐匿性强

实际的 HTTP DDoS 攻击中
，攻击者常常利用规模庞大的肉鸡/代理 IP，而 HTTP DDoS 攻击报文中往往不具备或具备难以察觉的恶意特征
。对这些攻击源进行封禁处置效果有限甚至有误报风险，攻击者却可以随时更换新一批攻击源
。

请求特征容易伪装 ，防护难度大

不同于 Web 注入攻击场景 ，HTTP DDoS 的攻击请求的报文特征常常处在一个难以判定好坏的区间
，有时部分的异常特征不足以支撑执行拦截决策 。攻击者可通过模拟、重放正常请求来发起攻击，即便在请求报文中某些特征被防护方捕获并针对性处置 ，攻击者也能感知到并作出调整 。

总体而言 ，一起复杂的 HTTP DDoS 攻击，通常不会使用畸形报文 ，也无需使用伪装技巧。对比其他类型的 DDoS 攻击需要更少的带宽成本就能瘫痪目标站点或服务，甚至特定的目标集群与接口
。在影响目标业务可用性的同时，也可能对接入链路网络的稳定性构成威胁  。这类攻击往往通过使用大量的肉鸡+IP 代理池发起，所以简单的封禁策略往往难以起到预期效果。也正因为如此
，在进行 HTTP DDoS 攻击防护过程
，要求对业务有更深入的理解，对于攻击定制针对性策略来实现误报与漏报的平衡
，这也是 HTTP DDoS 难以检测防护的原因。

兵来将挡，WAF 如何实现有效防护

根据上述 HTTP DDoS 的类型与特点，对于来势汹汹的攻击流量 ，WAF 如何实现有效防护呢 ？

根据攻击的原理与类型，可以大致分为三个主要的防护场景 ：

连接型 HTTP DDoS

这类型的 HTTP DDoS 攻击，对应上面提到的 Low&Slow attack 
。由于攻击是通过建立 TCP 连接后在传输 HTTP 报文的过程实现攻击效果，因此对于业务前面有 7 层接入层设备的业务(CDN
、LB 等)，这类攻击会被前面的 7 层接入层设备所承载。所以对于许多业务而言 ，这类型的攻击感知可能并不明显，但并不表明这类攻击的危害程度低 。相反如果针对特定 7 层接入设备进行此类型攻击 ，可能造成的业务影响面会更加广泛 。

由于这类攻击的特点是“慢速”
，那么WAF 可以对 HTTP 的请求 header 读取、请求、响应 body 的传输设置好超时时间。当触发超时策略时可断开相应的 TCP 连接 ，释放连接资源。同时 ，可对于异常的 header、body 做检查与限制（如限制 HTTP 请求 header 的数量） 。还可以通过 HTTP 层面的精细化访问控制来避免误伤场景（如正常业务的大文件传输场景）。

当然，要实现这些能力需要 WAF 与 7 层接入设备做好联动配合才能实现有效防护。

特征型 HTTP DDoS

这类型的 HTTP DDoS 攻击，对应上面的 Large Payload POST requests 和 Asymmetric requests ，他们的共同点是需要实现这类 HTTP DDoS 攻击，在 HTTP 请求报文中往往能够提取出关键异常特征。

例如，对于 Large Payload POST requests，WAF 可通过限制 body 长度，检查 body 内容合法性等手段来实现防护；

复制{

"title": "Liverpool FC (1 million more whitespace)",

"contentFormat": "html",

"content": "

Liverpool FC

You’ll never walk alone.

"canonicalUrl": "http://jamietalbot.com/posts/liverpool-fc",

"tags": ["football", "sport", "Liverpool"],

"publishStatus": "public"

例如针对上述的超大异常 body ，可通过 WAF 配置自定义策略限制 body 长度。

对于 Asymmetric requests 攻击，例如 HTTP Range 头利用的例子中，WAF 可通过限制 HTTP Range 头的分片策略实现异常检测与防护；对于一些漏洞利用，特别是业务使用的服务框架、中间件产生的漏洞造成的 DDoS，利用 WAF 的 Web 漏洞检测防护能力便能实现有效防护 。

floods 类型的 HTTP DDoS 在现实网络流量中更为主流与常见，影响业务稳定性的风险更大 
，是需要重点关注的防护场景；WAF 在面对这类型攻击时，可根据 floods 类型 HTTP DDoS 攻击的特征  、特点 ，分析拆解防护策略 ，通过以下手段、步骤来实现有效防护
：

当业务面临 HTTP floods 攻击防护需求时 ，首先需要梳理清楚业务的流量接入链路
。因为 HTTP floods 通常具有持续 、量级规模大的特点，因此最佳的防护部署是首先通过在最外接入层实现(例如 CDN)，这样的优点很明显 ，能将恶意的攻击流量在最外层收敛，减少后续接入层的压力与成本
 。但这并不意味着后续接入层无需部署防护 ，由于防护的精准程度与防护成本往往是正相关关系，经过收敛的流量在贴近业务的接入层做更精细的检测、处置，往往收益更明显；

同时，明确业务服务的使用场景在应对 HTTP floods 攻击时也非常关键且必要 ，业务不同的 host、path 往往有不同的业务特征
。比如后端负载能力、是否有登录态 、WebApp 还是 Native App、是否有 API 调用场景等 ，只有在明确业务场景后才能更好地制定精准、贴合业务需求的防护策略 。

业务链路梳理&防护部署

在 HTTP floods 发生时，最基本的防护需求是要保证业务的可用性 ，不能出现因攻击而造成业务瘫痪的情况；在这个需求背景下  ，最快速有效的策略便是为业务制定负载兜底策略。与业务共同梳理清楚需要防护的目标资产(host 、server cluster、path 等) ，根据业务场景先配置全局/粗粒度的限速策略 ，实现对攻击流量的初步防护收敛；

同时
，在明确目标防护资产的负载能力后
，进行更细粒度的限流/过载保护策略配置，在流量过载的极端情况下优先保证服务的可用性，构建一层基线防护能力
。

采取上述策略手段实现初步防护后，需要对 HTTP floods 流量进一步分析过滤，才能在保障正常业务流量的同时将恶意流量拒之门外。这里就需要 WAF 提供基于 HTTP 请求、响应报文的多维组合、匹配能力
，识别出报文中的异常特征并提供针对性的处置手段。例如，在对抗业务遭受的 HTTP floods 恶意流量攻击过程中 ，除了提取常见的异常 IP，Params ，UA，Referer ，Cookie 等特征进行封禁或限速处置外，还会将相关特征进行组合关联，为策略统计与响应处置提供参考 。

通过对攻击流量特征的分析统计，在 WAF 上进行组合策略配置

除了通过 WAF 丰富的特征分析能力识别恶意流量，在面临 HTTP floods 攻击时，提供丰富
、梯度的处置动作对于在防护过程平衡误伤风险也非常关键。WAF 可提供封禁、限速、重定向、验证码 、JS Challenge 、自定义响应等多种处置动作与特征识别能力配合 ，为防护的精准性提供保障。

对于专业的 HTTP floods 攻击，攻击者会尽可能地模拟  、重放正常的用户请求流量
。因此从“HTTP 报文特征”去识别防护恶意流量 ，可能还远不足以应对高级复杂的 HTTP floods 攻击。对于 HTTP floods 攻击手法的持续升级演进，除了从 HTTP 报文层面抽丝剥茧识别异常，还需要联动其他维度的信息与能力来提升防护效果 ，具体而言体现在以下方面：

WAF 的 JS Challenge 功能
，就是通过能力联动来提升防护效果的一个例子 ：

不同于对请求报文检测来识别异常这种“被动”的防护方式，JS Challenge 功能通过在防护检测过程“主动”向客户端植入一段 JS 逻辑 。通过利用前端浏览器的 JS 渲染执行能力 ，实现对异常流量的识别；在具体的实现过程中 ，为了对抗重放攻击、减少绕过风险  ，可能会引入动态令牌机制；为了更全面地覆盖业务场景，减少误伤情况发生，可以利用 JS API 调用判断浏览器环境与兼容性；为了对防护情况的实时掌控，还可能引入埋点 、监控逻辑等。

在这些技术细节的实现过程中 ，WAF 既需要联动端侧浏览器的能力，也需要联动 CDN
、LB 等接入组件的能力 ，最终实现防护效果的进一步提升
。

复盘反思 ，如何快人一步

WAF 在对抗 HTTP DDoS 攻击的过程中
，不断建设 、强化自身能力的同时 ，也需要不断复盘 、反思防护情况 ，力求更完善、高效的应对思路与方案。具体可以总结成以下三点  ：

根据 HTTP DDoS 攻击的特点可以得知，防护难点之一在于攻击流量特征难以捕捉。其中一个原因是依据现有的特征维度 ，攻击流量能实现高度的模拟伪装 。从这个角度出发，从防护视角补充更多维度的特征 ，就更能识别检测恶意流量  。

就 WAF 产品而言，可以从两方面着手推进：一方面是丰富报文特征 ，除了 7 层 HTTP 报文的特征提取，可以尝试结合 4 层报文的字段因子来实现对恶意流量的识别标记；另一方面是丰富行为特征 ，由于 HTTP 是无状态协议，单次请求响应的交互所携带的信息往往是有限的。通过关联 、统计具有一定联系的请求 ，提取行为特征 ，也能为制定防护策略提供参考。

提升 BOT 识别&对抗能力

对于 BOT 流量的识别对抗能力 ，在 HTTP DDoS 攻击防护中 ，往往发挥着重要、关键的作用
。但现实业务流量中往往也会混杂正常的 BOT 流量 ，这就要求不仅能识别出 BOT 流量，还能区分正常与恶意的 BOT 流量
，具备与恶意 BOT 流量的对抗处置能力。

在落地相关方案时，也需要与业务场景紧密贴合 。对于 WebApp 而言，正常流量多数通过浏览器发起 ，可以通过 JS Challenge 的方式实现对端侧的校验与信息采集 。通过该方案实现 WebApp 场景防护的同时，在技术实现上也需要不断迭代优化来满足更多元的业务场景需求。例如对于 JS 相关逻辑用更高效的混淆方式来避免绕过风险，对引入的 JS 资源做好缓存/优化策略提升业务性能与用户体验等 
。

对于 NativeApp 而言，则可以通过 SDK 集成方式来验证、采集端侧信息。但无论是哪种方式 、场景  ，都需要有更完善的误伤评估、监控体系来保障防护的精准性。对于无法准确识别恶意 BOT 流量的情况，也需要更丰富的柔性处置策略  ，来实现对流量的进一步过滤校验。

预防为主  ，防治结合，这是人类应对疾病威胁的重要方针，在网络安全世界中也同样适用  。HTTP DDoS 攻击发生时往往来势汹汹，事先并没有任何征兆
。这就意味着事中、事后的处置策略对当前攻击通常只能起到应急补救的效果。因此 ，对于存在攻击风险的业务，提前梳理业务资产，预先进行策略布局就显得更为重要。

为了实现这个目标可从两方面着手 ：一个是与业务团队紧密配合，做好宣传引导，在 WAF 产品中对关键目标资产实现 HTTP DDoS 防护策略的事前配置；另一个是强化 WAF 的自动化分析能力，对承载业务的目标资产、负载能力 、报文特征等数据进行自动化统计分析 ，输出对应的防护策略 ，对生产的策略效果进行实时评估
、校准 ，在提升防护效果的同时也能大幅降低策略运营成本 。