上下文是基于网络的负载均衡器。如果有人能解释 TCP ACK 风暴在现实生活中是如何产生的,以及针对它们的实用缓解策略,那就太好了。
编辑:澄清“缓解策略”。该平台由在 Linux 上运行的 nginx Web 服务器/负载平衡器组成。因此,希望相关的开关切换(如果有)来阻止它。
上下文是基于网络的负载均衡器。如果有人能解释 TCP ACK 风暴在现实生活中是如何产生的,以及针对它们的实用缓解策略,那就太好了。
编辑:澄清“缓解策略”。该平台由在 Linux 上运行的 nginx Web 服务器/负载平衡器组成。因此,希望相关的开关切换(如果有)来阻止它。
当客户端和服务器相互连接时,它们通过源和地址 IP 地址以及端口号(在客户端和服务器上)知道连接。连接流的两个方向都有两个序号;它们的初始值是随机选择的。每当一方发送数据包时,该数据包可能会涉及两个序列号:来自客户端的数据包可能包含有关客户端到服务器流的序列号的信息(例如“PUSH”),但也可能包含有关服务器到客户端流的序列号(“ACK”)。
如果攻击者可以使客户端和服务器在两个序列号上存在很大分歧,则可能会发生 ACK 风暴。基本上,客户端向服务器发送一个带有服务器到客户端值的数据包,服务器发现该值非常荒谬。服务器响应一个数据包,上面写着“亲爱的客户,您对当前的服务器到客户端的序列号非常错误,请善意地修改您的方式”。但是(这是很妙的一点),该数据包还将包含来自服务器的 ACK,该 ACK 记录了服务器对当前客户端到服务器序列号的概念......客户端会发现它非常无效。这将提示客户端响应一个数据包,上面写着“亲爱的服务器,您对当前的客户端到服务器的序列号非常错误,
风暴肆虐,直到其中一个 ACK 数据包丢失,乒乓比赛结束。但是,下次客户端或服务器有话要说时,它会再次启动,因为它们仍然是不同步的。
因此,ACK 风暴依赖于使客户端和服务器对两个序列号进行去同步的能力。这可以通过半中间人的能力来完成:例如,攻击者可以观察客户端和服务器之间的数据包,也可以注入一些假数据包,但不能阻止现有的数据包。这是“攻击者在同一个 LAN 上,交换机实际上是一个集线器(或者在被攻击者的随机垃圾包发送垃圾邮件致死后被降级为类似集线器的行为)”的模型。当攻击者看到从客户端到服务器的连接时,他立即发送一个虚假的 RST 数据包(好像客户端已经关闭了连接),然后是一个据称来自客户端的新的虚假 SYN,具有相同的端口号,但序列号大不相同.
有关详细信息,请参阅此演示文稿。
防御相对容易:任何一个参与 ACK 风暴的系统都可以检测到它接收和发送给定连接的大量错误数据包,然后简单地丢弃它。只要两个系统都准备好为一个 ACK 响应一个 ACK,ACK 风暴就可以持续下去;在第一个丢包时,风暴就停止了。如果检测到风暴,则: 1. 检测到风暴的系统可以通过拒绝再参与来阻止它,以及 2. 连接不可挽救,可以毫不客气地断开连接。