2021 年 8 月马里兰大学 Kevin Bock 等在 USENIX 大会上提出一种利用中间盒发起的新型 TCP 反射放大攻击手法：攻击者可以利用部分网络中间盒在 TCP 会话识别上的漏洞，实现一种全新的 DDoS 反射放大攻击。与 2018 年出现的利用协议栈发起的 TCP 反射无法放大攻击流量的情况不同，这种新型攻击实现了基于 TCP 协议的流量放大效果，这也使得该攻击手法诞生之后，在黑产中快速传播，全网泛滥。

在说明这种新型攻击手法之前，需要先科普一下反射放大攻击。所谓的反射放大攻击是非常常见并且深受攻击者欢迎的 DDoS 攻击手法，其基本原理非常简单：攻击者通过控制僵尸网络伪造靶机 IP 向特定的公网服务器发送请求，公网服务器收到请求后会向靶机发送更大的应答报文，从而实现攻击流量放大。

这里的公网服务器是指对外开放某些可被利用作反射放大的协议端口的服务器，比较常见的协议有 DNS、NTP、SNMP、Memcached 等，这些协议一般基于基于 UDP，并且协议本身存在缺陷，没有校验来源 IP 的真实性，且存在应答报文远大于请求报文等特点。这种反射放大手法简单、有效，一直深受黑客喜爱，所以很长一段时间内 UDP 反射就是反射放大攻击的别称。

那有没有利用 TCP 协议做反射攻击的?答案是有的。早在 2018 年就出现利用公网服务器开放的 TCP 端口进行反射攻击的手法，相比UDP反射放大攻击，此类利用TCP协议栈的反射攻击实际并无太明显的流量放大效果，因为请求的来源IP是伪造的，无法与TCP服务器完成TCP三次握手建立连接，所以无法得到应用层的应答报文。但是这种攻击利用了TCP的协议栈特性，使靶机看到攻击流量具备协议栈行为，而且成份复杂(synack、ack、rst等混合流量)，导致反向挑战、协议栈行为校验等传统的TCP防护算法无法防护，大大增加了防护难度，所以这种TCP反射诞生后很快成为DDoS攻击的主流攻击手法。

2021 年 8 月马里兰大学 Kevin Bock 等在《USENIX Security 2021》上发表并获得杰出论文奖的《Weaponizing Middleboxes for TCP Reflected Amplification》介绍了一种利用中间盒发起的新型 TCP 反射放大攻击手法。与 2018 年出现的 TCP 反射攻击受限于 TCP 三次握手机制导致难以实现流量放大的情况不同，这种新型的攻击手法利用了部分中间盒没有或者说无法严格遵循 TCP 协议栈的漏洞，精细构造特定请求，触发中间盒返回拦截页面，而由于拦截页面往往大于请求本身，最终实现了攻击流量的放大。

之所以说中间盒没有或者说无法严格遵循 TCP 协议栈是因为：现网很多中间盒例如防火墙、合规系统等考虑到网络架构、性能、稳定性等因素都会采用旁路部署、单边流量检测的架构，即这些系统本身只能看到机房入向的流量数据，最终这些中间盒只能根据单向流量判断是否存在 TCP 连接，甚至有中间盒不判断是否存在 TCP 连接，直接解析请求内容并下发拦截策略。所以攻击者发起这种新型 TCP 反射攻击的流程简单总结起来只需要以下几步：

备注：当然这个攻击手法对基于双向流量识别，并严格遵循 TCP 协议栈的中间盒是无效的。

根据攻击的思路可知，攻击者如果想把这种手法运用到实战，需要满足 3 个关键条件：

由于这种新型 TCP 反射攻击本质上是利用了部分中间盒的弱点，而全球互联中存在种类极其繁多的中间盒，不同类型的中间盒具体机制存在差异，所以需要找到有效、高效、通用的方法，欺骗中间盒，使其误以为 TCP 连接已经建立。通过测试和分析，最终发现主要有以下 TCP 报文类型或组合可以欺骗中间盒：

值得注意的是单报文就能触发拦截的场景一般都是对应的中间盒完全没有做任何的 TCP 握手检查，而是基于特定标志位的报文就直接提取域名并进行拦截，此类中间盒相对较少。而 SYN;PUSH+ACK 这种请求报文组合完全伪造单向 TCP 握手和 HTTP GET 请求场景，可以欺骗绝大部分只能看到单向流量的中间盒，所以触发反射放大的成功率更高。

找到欺骗中间盒，让其误判已经建立 TCP 连接的方法后，就需要找到更容易让中间盒下发拦截的域名。实际上中间盒对特定域名的拦截本质上就是互联网审查，所谓的互联网审查是由于政治、宗教、道德、经济等原因，世界很多国家都会对互联网流量进行不同程度的审查而且对不符合当地法律法规的域名进行屏蔽和请求拦截。而一般来说东亚、东南亚、中东等国家的互联网审计更为严格，所以某种程度上来说这些国家和地区的审计系统更容易被利用。

尽管审查的范围因国家地区而异，所以很难找到一个被所有审计中间盒拦截的域名，Kevin Bock 等人在 Quack 工具发布的公共数据进行测试分析，找到从大多数中间盒中引发响应的 5 个域，这些域巧合地跨越了五个不同的区域：

为了让靶机受到更大的攻击流量，就需要找到放大效果更好的中间盒作为反射放大器，而放大系数就是主要的衡量标准。

放大系数可以理解为流量的放大倍数，计算方法非常简单，就是 response 总长度/query 总长度。传统的 UDP 反射攻击的放大系数与具体的协议实现相关，所以放大系数是一个相对固定的值：除了 Memcached 反射攻击以外，其他 UDP 反射放大系数不超过 600，而且以 200 以内为主。

而当前这种新型 TCP 反射攻击的放大倍数却并不是一个固定的值，因为不同地区、不同厂商、不同类型的中间盒的拦截方式并不一致，甚至可以说是差别巨大。所以为了量化和评估这种手法的放大系数情况，我们对全网网段进行扫描，并对放大系数超过 5 的反射放大器进行统计分析：大部分反射放大器的放大系数在 5~100 之间，同时发现超过 1 万个放大系数在 100~10000 的强力放大器，不过更让人吃惊的是还发现了几个放大系数超过 1 万，甚至超过 5 万超级放大器。

那问题来了，按理来说中间盒应答的阻断包虽然可能会大于请求包，但阻断页面大小毕竟是有限的，所以出现成百上千的放大倍数还能理解，为何会出现数以万倍，甚至是超过 5 万倍的放大效果呢?而这个就是我们接下里讨论的超级放大器。

为了理解超级放大器，我们需要系统了解主要的反射场景：

这种场景下服务器收到请求后直接应答，一般会返回 synack 或者 rst，这种反射场景实际就是 2018 年出现的利用服务器协议栈的 TCP 反射，并无明显放大效果。

攻击请求触发了中间盒拦截，中间盒代替服务器给靶机应答一个较大的阻断页面，从而实现攻击流量放大，而且阻断页面越大，放大系数越大。当然部分中间盒并不会应答阻断页面，而是直接代替服务器返回 rst，这种情况下并不会有放大效果。

攻击请求触发既触发了中间盒拦截，又触发了后端服务器的应答，所以靶机会同时收到中间盒的拦截页面以及服务器的 synack 或者 rst，放大系数会略大于场景二。

这个场景最为特殊，攻击请求到达服务器所在 IDC 机房后，由于路由环路使请求在两个路由器之间循环，最终导致中间盒收到大量请求，最终给靶机多次应答阻断页面。我们知道数据报文中有 TTL 字段，每经过一个路由设备就会减一，直到减到 0 报文才会被丢弃。而攻击请求报文的初始 TTL 设置为 255，这就意味着经过路由环路，放大系数会比原来的增大 200+倍。(如下图: 攻击请求环路导致中间盒收到大量重复请求)

然后这情况还不是最糟糕，在某些特定的网络环境，会存在 TTL 重置的情况(例如网络中跑 MPLS 协议，并设置了 MPLS QOS，某些厂商设备的 MPLS QOS 默认会重置 TTL)，环路后请求包将无限循环，最终中间盒被迫以最大能力应答阻断页面，直到所在的出口带宽满载。上述因素就是出现超大放大系数中间盒的原因，这些反射器也被称为超级放大器。当然这种环路或者无限环路的情况会引起 IDC 运维和安全人员的警惕，所以超级反射器的存活并不稳定。例如笔者找到印度的一个超级反射器后，第二天就“失活”，变成普通反射器。

此外，Kevin Bock 等在《USENIX Security 2021》(https://www.usenix.org/conference/usenixsecurity21/presentation/bock)提到的还有第五种反射场景：靶机与中间盒的持续反射也能实现无限放大的能力，但由于笔者扫描没有发现此场景，故本文不作详细阐述。

被利用做反射放大器的中间盒如防火墙、合规系统一般都由 IP 网段所属企业/运营商统一部署及运营，所以同一个 IP 网段的放大效果接近，这就意味着如果攻击者要对外发起这种攻击，往往会向反射放大器所在 IP 网段发起扫描式的请求，这对反射放大器所在 IP 网段的来说就是扫段式的 DDoS 攻击。所以这种攻击的受害者其实有两个：

我们需要的是：既能有效防御这种攻击，又能避免成为攻击者的反射放大器。

如果我们被攻击者盯上，成为了靶机，那么防护这种攻击的关键就有两个:

在防护策略方面：由于中间盒的应答报文从四层流量上实际上与正常的 HTTP 应答报文并无明显差异，所以防护这种攻击实际比较困难，一般来说可以通过以下方法防护：

在防护带宽方面：由于该攻击手法具备流量放大效果，攻击流量往往很大，充足的防护带宽是不可或缺的。所以如果业务被攻击者盯上，面临这种大流量 DDoS 攻击时，非常推进接入云端，通过云厂商海量的防护带宽进行防御。

如果企业的中间盒(特别是合规系统)如果存在 TCP 会话识别的漏洞，且合规的阻断页面过大，那么久很有可能会被外部攻击者当做“优质的”反射放大器，从而不可避免地频繁遭受扫段式 DDoS 攻击，极大的浪费了系统性能、出口带宽等宝贵资源，而且面临被靶机投诉甚至报复的风险。为此优化合规系统等中间盒的机制，避免被利用将成为重要的安全话题，为此我们建议：

1.中间盒可以新增 TCP 报文的合法性检查和丢弃，例如 syn 置位但又携带载荷的属于明显非法报文，可以将其丢弃;
2.中间盒需要完善 TCP 会话识别能力，避免直接从 TCP 单包里直接提取域名直接下发拦截。在条件具备的情况下，尽量基于出入流量的双向会话检查，这样可以彻底规避风险。