Misbehaving TCP Receivers Can Cause Internet.docx
- 文档编号:25009218
- 上传时间:2023-06-03
- 格式:DOCX
- 页数:17
- 大小:35.10KB
Misbehaving TCP Receivers Can Cause Internet.docx
《Misbehaving TCP Receivers Can Cause Internet.docx》由会员分享,可在线阅读,更多相关《Misbehaving TCP Receivers Can Cause Internet.docx(17页珍藏版)》请在冰豆网上搜索。
MisbehavingTCPReceiversCanCauseInternet
MisbehavingTCPReceiversCanCauseInternet-WideCongestionCollapse
概要
opt-ack是由一个非正常操作的客户端对于一个没有被接收的数据段发送的ACK。
而以前的工作都集中在以opt-ack为手段贪婪地提高终端到终端的性能,我们专门研究opt-ack来拒绝服务攻击。
具体来说,一个攻击者向许多受害者并行发送opt-ack,从而放大其有效带宽到3000万倍(最坏情况)。
因此,即使是一个相对温和的攻击者可以完全充满从众多受害者到攻击者本身的路径。
更糟糕的是,一个分布式的网络攻击机器(“僵尸”)的并行攻击可以利用在互联网上的配置(预留空间)带来的广泛传播造成持续的拥塞崩溃。
我们在模拟中和在广域网中实现这一攻击,并在数据包的数量和产生的总流量上显示它的严重程度。
我们设计并实现了一种不需要客户端或网络更改,能够进行实际部署的新的解决方案。
此外,我们在一个真实的网络中证明了解决方案的效率。
安全
关键词
拥塞控制,分布式拒绝服务,传输控制协议
介绍
Savage等人展示了三种技术,通过它们一个行为不端的TCP接收器操纵发送者在公平的成本下给其他节点提供更好的服务。
Opt-ack有了一个这样的技术,接收者在数据段被实际接收之前发送确认(ACKs),欺骗发送者。
实际上,连接的往返时间减少了,总吞吐量增加了。
Savage等人观察一个行为不端的接收器可以使用opt-ack来隐藏数据的损失,从而以数据完整性为代价,提高终端到终端的性能。
他们进一步指出,Opt-ack可能可以被用于拒绝服务,但没有进一步进行调查。
在本文中,我们考虑一个接收器的唯一目标就是利用opt-ack发动分布式拒绝服务(DoS)攻击,不仅仅是对个别机器,而是对整个网络。
在本文中,我们:
1.通过分析(Section2.2)在模拟中和现实中的实验展示了opt-ack可能带来的原来没有被发现的重大的危险(一个攻击者,多个受害者)
2.调查预防技术,并基于跳段提出了一种新颖,高效,增量部署(可以逐步展开的)解决方案(第4.2节),而以前的解决方案忽略了实际部署的因素。
3.认为分布式opt-ack攻击(许多攻击者,很多受害者)有可能在大部分的网络中带来持续的拥塞崩溃,因此需要立即行动。
基于正反馈的攻击
传输协议的重要组成部分是流量和拥塞控制算法。
这些算法的不可避免的依靠远程反馈来确定数据包应该以什么速率发送。
这种反馈可以以positiveornegativeacknowledgments(正负ACK)直接来自网络或者更常见的是来自终端主机。
这些算法隐含地假设远程实体生成正确的反馈。
这通常是一个安全的假设,因为不正确的反馈会迅速恶化端到端的性能。
然而,一个不关心数据的完整性的攻击者,可能会违反这个假设来诱导发送者向网络注入大量的数据包。
虽然不是所有的这些数据包都能到达接收机,但是他们的确阻塞了发送者的网络使从发送者到接收者的路径达到饱和。
因为确认数据包是比较小的(40字节),这对以数百甚至数千的平行受害者为目标的攻击者来说是微不足道的。
事实上,不仅是每个受害者的接入链路饱和,由于过度供应,在上游ISP带宽更高的链路开始遭受拥塞崩溃。
在第2.4节中,我们认为,足够多的攻击者可以压倒骨干网络(链路)的核心,造成广域持续拥塞崩溃。
攻击分析
在本节中我们描述攻击的伪代码,攻击的变种和opt-ack攻击的分布式版本的细节。
在3节中,我们提出在实现攻击和减轻实际问题的技术中的观察。
算法1显示了一个单一的攻击者可以同时针对许多受害者。
通常情况下,攻击者会使用一个妥协的机器acompromisedmachine(一个“僵尸”),而不是直接发动攻击。
(注:
ThisattackcanalsobemountediftheattackerisabletospoofTCPconnections,eitherbybeingonthepathbetweenthevictimandthespoofedaddress,orfromguessingtheinitialsequencenumber,butwedonotfurtherconsiderit.)考虑一组受害者,V1...VN,服务于各种大小的文件。
攻击者连接到每一个受害者,然后发送应用层的请求,例如,HTTPGET。
攻击者开始确认(ACK)数据段,不管他们是否到达(图1)。
这导致受害者越来越快的对攻击者的opt-ack作出相应使得它的本地链路达到饱和。
为了持续攻击,攻击者反复要求同一文件或遍历一定数量的文件。
攻击的关键是,攻击者必须产生一个看似有效的ACKS序列。
一个ACK要被认为是有效的,它必须不能在受害者发送相应的数据包之前到达。
因此,攻击者必须只基于攻击者已经发送的ACKS流来估计哪个包在什么时候被发出。
起初,这似乎是一个艰巨的挑战,但受害人接受ACK的行为是完全由TCP拥塞控制算法规定的。
攻击需要三个参数:
一个n个受害者的表,最大段大小(MSS),和窗口缩放(wscale)因子。
在该算法中,攻击者可以跟踪每个受害者的估计窗口(WI)和序列号来确认收到(acki)。
WI,maxwindow的上限,默认是65535,但可以通过窗口缩放选项改变(见2.2节)。
值得注意的是,攻击者可以操纵每个受害者的重传超时(RTO),因为RTO是一个由ACK的到达率计算的往返时间函数。
因此,换句话说,攻击可以完全操纵受害者以何种速度发送,发送多少,并在何时超时timeout。
考虑到大文件在互联网上的普遍性,存在接近任意数量的潜在受害者。
任何能够流通TCP数据的机器都是潜在的受害者,包括HTTP服务器、FTP服务器、内容分发网络(CDN),P2P文件共享对P2Pfilesharingpeers(Kazaa[2],Gnutella[1])、NNTP服务器,甚至有过一次常见字符发生器('chargen”)服务的机器(machineswiththeoncecommoncharactergenerator(‘chargen’)service)。
攻击流很难区分合法流量。
对于一个足够接近受害者的外部观察员,例如网络入侵检测系统(IDS)。
这个流与一个完全有效的高速连接在理论上没有什么区别。
(注Presumably,amonitoringsystemdeployedclosertotheattackercoulddetecttheasynchronybetweenACKsanddatasegments,butitisnotpracticaltostoreper-flowstatedeepinthenetwork.)如果一个大的数据包流进入本地网络,IDSs发出警告是很常见的。
来自攻击者的ACKs流是相当小的(在2.2节中可以看到确切数字)。
离开网络的数据流才是问题。
(Itisthestreamofdataleavingthenetworkthatistheproblem.)
此外,攻击者可以通过向更多的受害者更低频率的发送接收信息acks,保持产生的流量总数恒定来进一步掩盖攻击。
换句话说,通过让每个主机生成更少的流量,保持在检测阈值下,但增加主机的总数,使得在本地受害者不能明显的发现他们处于一个DDoS攻击中。
因此,由于缺少全局协调,受害者们很难本地检测是否它们的数据流中存在任何一个恶意数据。
虽然算法1在理论上可行,对于对手来说,保持ACKs和受害者实际发送的段同步仍然很有挑战性。
我们在下一个章节解决这些问题。
放大
同时,受害者可以被诱导发送大量的数据到网络,这并不奇怪,实际的optact放大因子是真正令人震惊的。
从单个攻击者到所有受害者引发的流量上限是一个有四项内容的函数:
受害者数量n,对于每个单独的受害者i,ACKS到达每个受害者的速度(αi),最大段长度(MSSI),和受害者的拥塞窗口的大小(WI)。
值得注意的是,攻击者可以使用一个单一的ACK确认数据包的一个完整的拥塞窗口。
如果我们假设一个标准的TCP/IP的40字节的头(header)没有选择(withnooptions),那么数据包大小为40+MSSIbytes3。
在字节/秒的攻击流量率只是每个被害人的ACK到达率(αi),数据包的数量(⌊wi/MSSI⌋),每个数据包的大小(40+MSSI)的乘积之和。
鉴于最大窗口Wi是65535×2wscale,而且所有受害者总的ACK到达率不能超过攻击者的带宽(β)除以ACK的大小(40),我们得到的总攻击流量为Tmax字节/秒:
Tmax=β×65535×2wscale×mss+40
从上式中我们可以知道,对于典型的网络连接,例如mss=1460andwscale=0,攻击者有1683的放大系数。
在最坏的情况下,即如果MSS=88(theminimummssforLinuxandWindowsXP[19])andwscale=14,那么放大系数可高达32554441。
在没有窗口缩放的现实世界中,攻击者on56Kbps的调制解调器(β=7000B/S)可以产生9351145的B/S或约8.9mb/s的总的到达所有受害者的流(floodingsummedacrossallvictims)。
这个值大于一个T3线的容量,和接近100MB的以太网连接的理论极限。
运用窗口缩放和小间距,在调制解调器上的一个攻击者每秒能够产生比Slammer蠕虫病毒在高峰期产生的更多的流量。
显然,在放大上有实际的限制,包括受害者数量的最大值,他们的最小带宽和最大化拥塞窗口所需要的时间。
考虑到空间,这些限制的探索可以被发现(in[22])
懒惰Opt-Ack
懒惰Opt-Ack是标准optack攻击的变体。
和我们在第三节中讨论的一样,在我们实现中主要的困难时和发送者的序列号保持同步。
同步问题是完全可以避免的,如果攻击者ACKS它实际收到任何段,跳过丢失片段。
这种懒惰的变种是恶意的,攻击者有效隐瞒任何数据包丢失,从而创造一个面临拥塞时不降低其发送速率的流量(例如一个非响应流)。
因为攻击者使用受害者的实际RTT,它会产生比算法1中描述的攻击更少的流量。
然而,众所周知的是,在一个拥挤的网络中,一个非响应的流量可以导致兼容的流后退(compliantflowstobackoff),造成一个DoS拒绝。
注意到懒惰的变种是不同的标准攻击,因此攻击者是不可能超过受害者的。
这个观察结果正是许多存在的解决方案不足的原因。
在第4.2节中,我们提到的跳段解决方案可以同时防止懒惰和标准攻击。
分布式Opt-Ack攻击
在本节中,我们考虑分布式的情况下,多个攻击者进行Opt-Ack平行琐碎的,有毁灭性的影响的攻击。
唯一需要的是,每个攻击者选择一组不同的受害者。
因为一个单一的攻击者可以请求大量的数据包(如图2.2所示)一个相对较小的攻击者组可以导致互联网遭受广泛和持续的拥塞崩溃。
首先,因为Opt-Ack可以以任何TCP服务器为目标,因此在互联网上有数以万计的潜在的受害者。
只考虑P2P文件分发网络,Kazaa和Gnutella有超过200万1.4百万的用户,每个主机拥有大型的多媒体文件。
而P2P节点通常是低带宽的家庭用户,流行的内容分销商Akamai运行超过14000个高配置的,地理上分散的服务器。
我们不能立即清楚多少流量是必要的来对广域互联网造成不利影响。
一个数据点是从地狱/蓝宝石蠕虫Slammer/Sapphireworm产生的流量。
穆尔等。
用抽样技术来估计峰值的全球蠕虫流量约为每秒8000万包。
在404字节/包下,蠕虫产生约31gb/s的全球互联网流量。
随后的互联网运营商的电子邮件交换指出,许多访问链接是在满负荷,完全无法使用。
正如在2.2节中指出的,单个的调制解调器上的攻击者产生足够多的流量,使用大wscale值来超过这个阈值在理论上是可能的。
如果使用大wscale值是不可行的(例如,如果包含wscale选项分组的packets被用作防火墙),那么有更典型TCP选项的在T3连接上的五个攻击者i.e.,mss=1460andwscale=0,足以匹配的Slammer蠕虫的流量。
如果每个攻击者以足够多的受害者为目标,那么任何一个受害者的负载都不是特别高,这将很难在本地区分恶意和有效的数据流。
所以,不像Slammer,它没有明确的本地规则应用于阻止攻击。
来自Slammer蠕虫流量不足以导致互联网的核心的拥塞崩溃。
因为对大规模网络现象建模的固有困难,目前尚不清楚如何估计引起这样的崩溃需要多少数量的optack攻击者。
然而,一个单一的在调制解调器上的攻击者或少量其他攻击者可以诱导产生等效Slammer蠕虫的流量负荷。
最近的研究表明,存在损害(妥协)机器网络(“僵尸网络”)拥有超过200000个节点。
由于每个节点代表一个可能的攻击者,一个大型的分布式optack攻击可以是灾难性的。
IMPLEMENTINGOPT-ACK
实施攻击的最主要的挑战是如何准确地预测受害者在发送哪一段,确保相应的ACK在正确的时间到达。
在图1中,攻击者甚至在相应的段到达之前将ACKs注入网络。
因此与受害者保持同步可以是非平凡的。
保持这个序列号的同步对攻击来说是至关重要。
如果攻击者落在后面,即,它开始应答慢于他们被发送,那么受害者减慢,可能会超时,攻击的效果降低。
同样的,如果攻击者在序列空间中处于受害者之前,即受害人接受到尚未发送的ACK段,受害人忽略这些ACKS,流停止前进。
我们称这种情况为Overrun(超越)受害者。
Overrun在三种情况下会发生,ACKs到达的太快,丢失ACKs,服务器延迟。
下面,我们描述一个攻击者检测到这种状态并恢复的技术。
InaccordancewithRFC793[3],Section3.4,当发送方接收到不在窗口中的ACK,它不应该产生一个RST,而是使用有着正确的序列号空包。
一个互联网的设计哲学的原则是稳健性原则:
“你发送什么是保守的,你接受是自由的,”optack攻击正是运用的这条原则。
有很多方法,可能会导致溢出的情况overruncondition,最常见的情况就是发送应用程序延迟输出因为它被另一个进程抢占。
在一般情况下,有大量的因素可能影响发送者的实际输出率,包括:
受害者的负载,应用程序延迟,受害者的发送缓冲区大小,和受害者的硬件缓冲区。
然而,受害者的数量是大的时候这些因素被减轻。
通过发送ACKs给更多的受害者,每个受害者更少的收到ACKs。
这为受害者提供了更多的时间来刷新其缓冲区,将发送的应用程序返回到运行队列等等。
值得注意的是,我们开发的实现仅是一个optack潜在的严重程度的展示。
而不是一个最佳的攻击。
在许多点上一个更彻底全面的攻击者可能能够造成更有效的攻击。
然而,正如我们在第5节所指出的那样,实现是有充分破坏性的,激励立即采取行动。
我们进一步讨论来减缓和从超越受害者overrunningthevictim恢复的策略。
RecoveryfromOverruns
标准的TCP流应该在一收到一个超出窗口的ACK就产生一个空段。
攻击者可以利用这个空段检测超支?
超越?
(overrun),但这种技术是不可靠的因为传入的链接通常是饱和的,所以空段在到攻击者之前会被丢弃。
此外,Linux的TCP实现不发空段,而是忽略超出窗口的ACK(其他的操作系统,特别是MacOSX10.2和Windows2000,正确的生成空包)。
然而,值得注意的是,一个流在前进的过程中,也就是说i.e.notoverrun,信息包收到的序列号单调增加(不包括信息包乱序)。
在重传,或者当一个空的数据包接收的时候,序列号小于或等于前一包,打破单调。
因此,通过监测实际收到的数据包的序列号,攻击者可以声明一个overrun,当序列号不再增加。
当一个overrun被检测到,攻击者可以在最后一个接收的包上恢复缓慢启动,从而从overrun中恢复。
这是一个昂贵的过程,因为它可能需要为服务器超时等待至少一秒的时间。
图2显示了在广域网络,对GNU/Linux2.4.20受害者攻击的生命周期。
“攻击者”的数据点在受害者收到的时候显示ACKs,“受害者”的数据点显示被受害者发送的段。
请注意,对于大多数的时间,这两条线是没有区别的,即攻击者与受害者同步(图4)。
然而,有三次攻击者overrun了受害者的序列号,并被迫恢复,如上面描述的一样。
攻击者盲目地继续发送被忽视的ACK,当受害者停止发送流的进程(由图中的平线证明)。
在第一个overrun,受害人实际上在攻击者恢复之前转发了三次,因为传输的数据包也丢失了。
然而,在接下来的两个overrun,攻击者恢复更快,每一次大约用了一秒。
恢复代码必须跟踪受害者的慢启动门限slowstartthreshold(ssthreshi)和拥塞窗口估计值(WI)。
变量ssthreshi初始化为最大窗口大小,按规定设置为每次恢复wi的一半和拥塞窗口一起增长。
(Thevariablessthreshiisinitializedtothemaximumwindowsize,issettohalfwiwitheveryrecovery,andgrowswiththecongestionwindow,asprescribedby)
受害者处理时间。
保持攻击者同步的最困难的挑战之一是估计受害者发送数据包所花费的时间,我们称它为处理时间。
显然,攻击者不能以比受害者能生成它们更快的速度ACK段。
如果攻击者知道受害者的处理器速度,服务器负载,操作系统,和本地的带宽,它可以估计处理的延迟时间。
然而,这个信息是很难确定的,而低估了延迟时间会导致攻击者overrun服务器,导致攻击强度降低。
为了解决这个问题,我们引入了TargetBandwidth锁定带宽变量。
有了这个变量,我们可以得到处理的延迟:
⌊cwnd/mss⌋×(40+mss)processingdelay=TargetBandwidth
TargetBandwidth目标带宽变量代表攻击者试图诱导服务器生成的流量率(字节/秒),而锁定带宽值可以基于攻击者被迫恢复的频率,自适应地被确定。
为实现代码的目的,我们指定它作为一个运行参数。
此外,许多TCP的实现将本地调用拥塞控制措施,如果当地的硬件缓冲区已经满了,那么这是选择对受害者硬件可行的锁定带宽TargetBandwidth是很重要的。
空闲服务器的处理时间明显短于一个繁忙的服务器。
这意味着攻击者需要在攻击之前估计服务器的负载。
然而,我们注意到,当攻击者的流量增加,其他连接被强制关闭,这反过来又降低了服务器的处理时间。
因此,我们引入自适应延迟的概念。
通过高估初始处理时间和ACKs间的延迟,即缓慢发送ACKs,然后逐步加大ACKs速度到了一个理想值,有着最小的overrun,第三方流被推开。
如何有效地积极的做到这些,而不导致攻击者超限overrun和重新启动,是一个悬而未决的问题。
然而,在实施过程中,我们在10倍的估计处理时间下任意的开始,然后以每个窗口500微秒下降到目标处理时间在。
另一个影响处理时间的变量是在受害者调度中的粗粒度时间片。
定期的,受害人进程为多个时间片暂停,如果内核缓冲区在进程能被重新调度之前耗尽,那么他可能导致发送的延迟。
这方面的一个例子是第二伪影thesecondartifact(图2,放大如图6),其中服务器实际上停顿36毫秒。
这是在图6中不太明显,但是服务器在缓冲ACK到达之前一毫秒以内,开始发送。
我们没有一种技术来预测这些延迟,并依赖于恢复/重新启动机制。
MultipleACKsPerWindowandtheTransitionPhase(过渡阶段)
我们注意到,在拥塞避免的过程中,服务器很少发全64KB的窗口,甚至当拥塞窗口允许它。
这使得传输的段的数量变得不同,这让攻击者ACK正确数量的段变得困难。
我们推测这是由于操作系统缓冲效率低下,也或许是粗粒度的时间片。
不管什么原因,我们改变了攻击算法来ACK有适当延迟的窗口的一半而不是全窗口。
通过ACK一半的量,两倍的次数,我们能够保持高流量,减少攻击者overrun受害者序列号的可能性。
然而,通过发送两倍数量的攻击,攻击者的放大被限制为2.2节中所列出的一半。
每个窗口发送两个ACK的额外效果是抵抗丢失ACKs。
基本算法假定每个ACK成功到达受害者,这在一般互联网上显然是不真实的。
为了最大限度地提高鲁棒性,theimplementationsendstwoACKsoffsetbyonemssfromeachothertwiceperwindowforatotaloffourACKsperwindow.这里的效果是2倍。
首先,攻击者可以失去一行中三个顺序ACKs而不overrun服务器。
其次,更多的ACK让拥塞窗口在从overrun中回复后快速增长。
注意到每个窗口发送四个ACKs使我们以四倍减少预期放大。
在发展中,很难追踪受害者的拥塞窗口和慢启动阈值的精确状态,尤其是在恢复后。
这是常见的,攻击者通过缓慢的开始与受害者保持正确的同步,然后在到达拥塞避免算法时立即不同步。
虽然我们推测有很多因素导致这种行为,即不可预知的服务器负载,在拥塞避免阶段所涉及的时间可能需要比缓慢的开始阶段更精确。
因此,我们攻击者的慢启动阶段和拥塞避免之间引入了一个“过渡”(见图3)。
在这个过渡阶段,weACKeveryexpectedpacketinturnforthefullwindow.在过渡期,允许估计受害者的ssthresh慢启动阈值有较大的的误差。
在实践中,在过渡到攻击的完整拥塞避免部分之前,在过渡中ACK两个完整窗口。
攻击者本地带宽
算法1没有考虑到攻击者的本地带宽。
考虑一个β字节每秒的本地带宽,所有发送给所有的受害者的ACKs的和,可以以最大α=β/40字节数/秒发送。
在速度超过α,ACK得到缓冲或甚至被丢弃,干扰了攻击的时间。
当ACK被缓冲(buffered),(asshowninthefirstartifactofFigure2,andFigure5)他们都立即到达受害者。
受害者不能足够快的发送来跟上ACKs的突然泛滥,这导致了一个overrun。
为了解决这个问题,我们限制攻击者输出ACK率为可用的本地带宽的函数,它在运行时被指定。
限制ACKs率的主要效用是甚至在他们到达受害者时保持间距,忽略网络的抖动和缓冲。
此外,当受害者数量增加,来自bufferedACKs的难度降低,因为服务器接收ACKs之间的时间增加。
防御opt-ack
在本节中,我们提出了评价对opt-ack攻击不同的防御机制一个简单的框架,并评估了框架中潜在的解决方案。
最后,我们提出了一个具体的解决方案,随机跳段,有效地抵御opt-ack。
我们还详细描述了一个随机跳段实现的过程。
任何机制,防御opt-ack应该具备的要求
1.EasytoDeploy易部署Duetotheseverityoftheattack,anysolutionshouldbepracticallyandquicklydeployableintheglobalinfrastructure.Minimally,thesolutions
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- Misbehaving TCP Receivers Can Cause Internet
![提示](https://static.bdocx.com/images/bang_tan.gif)