我们常听说 UDP 反射攻击，那你听说过 TCP 反射攻击吗？

我们常听说 UDP 反射攻击，那你听说过 TCP 反射攻击吗？

我们对 TCP 三次握手谙熟于心，但你确定服务器收到 SYN 包之后一定返回 SYN/ACK 吗？

现网的 DDoS 对抗中，基于 TCP 协议的反射攻击手法已经悄然兴起，而且出现了多次手法变种，对 DDoS 防护方带来严峻的挑战。新场景下的技术对抗如约而至…

01 引言

笔者之前曾撰写过一篇关于利用 TCP 协议发起的反射攻击的文章《值得收藏好文，基于 TCP 反射 DDoS 攻击分析》。分享的是一种新型的攻击手法 —— TCP 反射攻击：黑客伪造目的服务器 IP 向公网的 TCP 服务器发起连接请求(SYN)，以使得被攻击服务器收到大量 SYN/ACK 报文，最终造成拒绝服务的手法。而由于这种反射攻击存在协议栈行为，传统的 TCP 防护算法难以奏效，这也使得这种攻击手法有愈演愈烈之势。

图 1 TCP 反射攻击示意图

经过我们团队研究人员长期的跟踪分析，发现这种攻击手法出现了两个新的特征：

Ø黑客逐渐趋向利用 CDN 厂商的服务器资源发起 TCP 反射攻击，因为通过扫描 CDN 厂商网段，可以快速、高效地获得丰富的 TCP 服务器资源；

ØTCP 反射攻击流量从 SYN/ACK 转变成 ACK，防护难度进一步增大。

0x01 TCP 反射的新特征研究

特征一：黑客逐渐趋向于利用 CDN 厂商的服务器资源发起 TCP 反射攻击

我们在整理分析现网的 TCP 反射攻击时，发现会经常出现攻击源几乎全部来源海外 CDN 厂商的情况。如图 2、图 3 所示，某次 TCP 反射攻击事件中有 99.88%的 IP 来源美国，而且 88.39%属于某个著名 CDN 厂商。

图 2 来源 IP 归属地分布

图 3 来源 IP 归属地分布

显而易见这是黑客开始倾向于扫描 CDN 厂商的 IP 网段，以获取大批量反射源的思路。由于 CDN 厂商的 IP 资源主要用于为用户提供加速服务，不可避免地会开放 TCP 端口，黑客便可以通过这种方式快速地获取到有效的 TCP 反射源。

图 4 某 CDN 厂商的 C 段 IP 扫描

这种方法为黑客提供大量可用的 TCP 反射源，能够让攻击者的资源实现最大化，而且 TCP 反射攻击由于具备协议栈行为，传统策略难以防护，所以不难推测后面这种攻击手法将越来越盛行，为 DDoS 防护方带来不小的挑战。

特征二：反射流量从 SYN/ACK 报文转变为 ACK 报文，防护难度进一步增大

这里给人的第一反应可能就是颠覆了我们 TCP 三次握手的印象，一个服务器(反射源)收到一个 SYN 请求，不应该是返回 SYN/ACK 吗？怎么会返回 ACK 包？为了解答这个问题，容笔者从黑客伪造 SYN 请求的过程说起…

首先如上文描述 TCP 反射的原理，黑客会控制肉鸡伪造成被攻击服务器的 IP 对公网的 TCP 服务器发起 SYN 请求，而公网 TCP 服务器的端口都是固定的，所以为了实现反射，SYN 请求中的目的端口也同样固定。与此同时，为了达到更好的攻击效果，黑客需要使反射出来的报文的目的端口为被攻击服务器的业务端口(绕过安全设备将非业务端口的流量直接拦截的策略)，也就是说 SYN 请求报文中的源端口也是固定的。就是基于这些原因，攻击者伪造 SYN 请求报文的五元组通常都会出现集聚，这个结论其实很重要，因为它就是引发服务器反弹 ACK 的前提条件。

举例如图 5 所示：黑客需要攻击的服务器 IP 为 183...45，其业务端口为 80，而黑客掌握的 TCP 反射服务器的 IP 是 104...35，开放的端口是 8080，那么攻击时构造 SYN 包的五元组就会集聚在 Protocol: TCP、DST_IP: 104...35、SRC_IP: 183...45、DST_PORT: 8080、SRC_PORT: 80。

图 5 SYN 请求包构造思路

而我们都知道五元组决定了一个会话，所以当黑客短时时间构造大量相同五元组的 SYN 包发送到同一台 TCP 服务器时，就会造成大量的“会话冲突”。也就是说从 TCP 服务器的角度来看，接收到第一个 SYN 包后，服务器返回 SYN/ACK 等待 ACK 以建立 TCP 连接，而此时又再接收到同一个会话的 SYN。那 TCP 服务器会怎么处理呢？再次返回 SYN/ACK？RST？还是其他？

其实在这个情况下，TCP 服务器具体怎么处理决定因素在于 SYN 包的 seq 号和服务器的 window size！假设第一个 SYN 包的 seq 号为 SEQ1，TCP 服务器的 windows size 为 WND，而第二个 SYN 的 seq 号为 SEQ2，那么：

一、如果 SEQ2==SEQ1，此时 TCP 服务器会认为这个是 SYN 包重传，则再次返回 SYN/ACK(其实是在重传 SYN/ACK)，如图 6 所示。这个攻击场景从被攻击服务器的视角来看，就是在短时间内接收到大量的 SYN/ACK 报文，造成拒绝服务，这也是现网最为常见的场景之一。

图 6 TCP 反射，反弹 SYN/ACK 场景

二、如果 SEQ2>SEQ1+WND 或者 SEQ2< SEQ1，那么这种情况属于 out-of-windows：对于不在接收窗口内的报文，需要回复一个 ACK，让对方发送正确 SEQ 号的包过来，协议描述可以参考 RFC: 793 page69（见图 7）。

图 7 RFC: 793 page69

所以当黑客伪造 SYN 报文的 SEQ 随机变化时，就很容易命中上述情况，TCP 服务器就会返回 ACK 报文，如图 8、图 9 所示。

图 8 TCP 反射，反弹 ACK 场景(SEQ2>SEQ1+WND)

图 9 TCP 反射，反弹 ACK 场景(SEQ2< SEQ1)

这个场景中，被攻击服务器会接收到少量 SYN/ACK 以及大量的 ACK 报文，这是现网最越来越常见的场景。如图 10 为现网中一次真实 TCP 反射攻击的抓包采样，表面上看跟普通的 ACKFLOOD 攻击没有太大区别，而实际上这些流量是具有协议栈行为，所以传统策略难以有效防护。

图 10 现网 TCP 反射攻击采样

三、如果 SEQ1< SEQ2 < = SEQ1+WND，这种场景下 TCP 服务器会认为会话出现异常，并返回 RST 断开会话，如图 11 所示。此时被攻击服务器会收到大量 SYN/ACK+RST 的混合流量(当前现网中这种情况很少，而 RST 的防护难度较小，这里不做详细阐述)。

图 11 TCP 反射，反弹 RST 场景

综上所述，黑客为了实现 TCP 反射攻击，而且尽可能绕过防护策略，所以伪造的 SYN 报文的五元组会出现集聚，造成严重的会话冲突。而不同的 SEQ 号会触发 TCP 服务器不同的应答场景(情况汇总见图 12)，所以现网中的 TCP 反射除了会出现大量的 SYN/ACK 流量以外，还有可能出现少量 SYN/ACK+大量 ACK 的混合流量，而且后者的流量成份更为复杂，防护难度更大。

图 12 TCP 反射场景汇总

02 新型的 TCP 反射防护算法

笔者整理总结了 TCP 反射防护的主要难点：

1、TCP 反射流量具有协议栈行为，传统的防护算法难以识别和防护；

2、专业的抗 D 设备通常旁路部署，所以无法获得服务器出流量，这也意味着无法通过双向会话检查的方式进行防护；

3、TCP 反射通常为 SYN/ACK 和 ACK 的混合流量，而且在成份占比和行为上跟正常业务流量几乎没有太大区别，所以传统的成份分析、限速等方式也难以凑效。

那既然 TCP 反射攻击防护难度这么大，当前有成熟有效的方案了吗？答案是有的，防护算法的核心思路是：对被攻击 IP 的入方向流量做会话跟踪，并分析每个会话的行为动作，以准确地区分出 TCP 反射攻击的会话和正常流量会话，最终对反射攻击源做拦截，实现有效防护。

防护算法具有以下特点：

1、秒级检测和精准防护：对 TCP 反射流量包括 SYN/ACK、RST、ACK 均能有效识别和清洗，保证业务稳定；

2、对正常业务流量无影响：防护算法对用户透明，用户完全不会有感知，确保用户的最佳体验；

3、可以自动适配：防护算法可以默认适配绝大部分业务场景，用户不需要额外配置定制策略，大大减轻防护门槛以及运维人力投入。

当前新算法已经完成研发和验证，并通过大禹 DDoS 防护系统为部分重点客户提前试用体验，后续将向腾讯云客户全面开放，持续护航业务稳定运营。

03 团队介绍

腾讯安全大禹 DDoS 防护产品是腾讯基于自主研发的宙斯盾系统技术构建的一套集对 DDoS 攻击的检测和防御于一身的网络层 DDoS 攻击防御解决方案。该方案结合了腾讯十多年在游戏、网站、支付、社交、广告等海量业务的 DDoS 防护经验，具有全面、高效、专业的 DDoS 防护能力，能为企业组织提供 BGP 高防包、BGP 高防 IP、棋牌盾等多种 DDoS 解决方案，应对 DDoS 攻击问题。通过充足、优质的 BGP 防护资源，结合持续进化的“自研+AI 智能识别”清洗算法，保障用户业务的稳定、安全运行。

本文转载自公众号云加社区（ID：QcloudCommunity）。

原文链接：

https://mp.weixin.qq.com/s/rm5C3Kx2bx46LkEyyc3gFw