我们常听说 UDP 反射攻击, 那你听说过 TCP 反射攻击吗?
我们对 TCP 三次握手谙熟于心, 但你确定服务器收到 SYN 包之后一定返回 SYN/ACK 吗?
现网的 DDoS 对抗中, 基于 TCP 协议的反射攻击手法已经悄然兴起, 而且出现了多次手法变种, 对 DDoS 防护方带来严峻的挑战. 新场景下的技术对抗如约而至.
笔者之前曾撰写过一篇关于利用 TCP 协议发起的反射攻击的文章 《小隐隐于野: 基于 TCP 反射 DDoS 攻击分析》 https://www.cnblogs.com/qcloud1001/p/9039227.html . 分享的是一种新型的攻击手法 --TCP 反射攻击: 黑客伪造目的服务器 IP 向公网的 TCP 服务器发起连接请求(SYN), 以使得被攻击服务器收到大量 SYN/ACK 报文, 最终造成拒绝服务的手法. 而由于这种反射攻击存在协议栈行为, 传统的 TCP 防护算法难以凑效, 这也使得这种攻击手法有愈演愈烈之势.
经过我们团队研究人员长期的跟踪分析, 发现这种攻击手法出现了两个新的特征:
黑客逐渐趋向利用 CDN 厂商的服务器资源发起 TCP 发射攻击, 因为通过扫描 CDN 厂商网段, 可以快速, 高效地获得丰富的 TCP 服务器资源;
TCP 反射攻击流量从 SYN/ACK 转变成 ACK, 防护难度进一步增大.
0*01 TCP 反射的新特征研究
特征一: 黑客逐渐趋向于利用 CDN 厂商的服务器资源发起 TCP 发射攻击
我们在整理分析现网的 TCP 反射攻击时, 发现会经常出现攻击源几乎全部来源海外 CDN 厂商的情况. 如图 2, 图 3 所示, 某次 TCP 反射攻击事件中有 99.88% 的 IP 来源美国, 而且 88.39% 属于某个著名 CDN 厂商.
显而易见这是黑客开始倾向于扫描 CDN 厂商的 IP 网段, 以获取大批量反射源的思路. 由于 CDN 厂商的 IP 资源主要用于为用户提供加速服务, 不可避免地会开放 TCP 端口, 黑客便可以通过这种方式快速地获取到有效的 TCP 反射源. 例如笔者随机探测一个 CDN 厂商的 C 段 IP, 结果为: 整个 C 段所有 IP 全部均有开放 TCP 端口 .
这种方法为黑客提供大量可用的 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.
而我们都知道五元组决定了一个会话, 所以当黑客短时时间构造大量相同五元组的 SYN 包发送到同一台 TCP 服务器时, 就会造成大量的 "会话冲突". 也就是说从 TCP 服务器的角度来看, 接收到第一个 SYN 包后, 服务器返回 SYN/ACK 等待 ACK 以建立 TCP 连接, 而此时又再接收到同一个会话的 SYN. 那 TCP 服务器会怎么处理呢? 再次返回 SYN/ACK?RST? 还是其他?
其实在这个情况下, TCP 服务器具体怎么处理决定因素在于 SYN 包的 seq 号和服务器的 Windows size! 假设第一个 SYN 包的 seq 号为 SEQ1,TCP 服务器的 Windows size 为 WND, 而第二个 SYN 的 seq 号为 SEQ2, 那么:
一, 如果 SEQ2==SEQ1, 此时 TCP 服务器会认为这个是 SYN 包重传, 则再次返回 SYN/ACK(其实是在重传 SYN/ACK), 如图 6 所示. 这个攻击场景从被攻击服务器的视角来看, 就是在短时间内接收到大量的 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 的混合流量, 而且后者的流量成份更为复杂, 防护难度更大.
0*02 新型的 TCP 反射防护算法
笔者整理总结了 TCP 反射防护的主要难点:
1,TCP 反射流量具有协议栈行为, 传统的防护算法难以识别和防护;
2, 专业的抗 D 设备通常旁路部署, 所以无法获得服务器出流量, 这也意味着无法通过双向会话检查的方式进行防护;
3,TCP 反射通常为 SYN/ACK 和 ACK 的混合流量, 而且在成份占比和行为上跟正常业务流量几乎没有太大区别, 所以传统的成份分析, 限速等方式也难以凑效.
来源: http://www.tuicool.com/articles/z2Yniym