用于抵御分布式拒绝服务(DDoS)攻击的基于行为的业务区分的制作方法

专利名称：：用于抵御分布式拒绝服务(DDoS)攻击的基于行为的业务区分的制作方法用于抵御分布式拒绝服务(DDoS)攻击的基于行为的业务区分
背景技术：
：电子商务应用和任务关键性军事通信的激增已引发了对因特网上的网络安全的严重关注。致命的拒绝服务(DenialofService,DoS)攻击及其高级变种分布式DoS(DDoS)攻击的出现，对于我们对因特网的使用和依赖;4^烦的入侵者。即使在诸如Yahoo、CNN、Ebay和Amazon之类的高M^站点上也反复地证明了DoS/DDoS攻击的不利影响。在DDoS攻击中，攻击者向受害者发送大量的恶意业务。例如，DDoS攻击者经由连接到因特网的计算机系统可以侵入不同数据中心的一个或多个计算机。通常，攻击者会通过因特网服务提供商(ISP)接入因特网。然后，攻击者可以通过使用恶意软件程序将数据中心的多个计算机置于其控制之下。当攻击者发出命令时，这些计算机可以在不同时刻将大量的数据同时发送到受害者，阻止受害者响应合法的因特网业务和消息。当前，DDoS攻击大fci对因特网社区的最为凶恶的威胁。DDoS攻击通^±^&面上正常、实际上毫无用处的包而霸占并消耗了系统的有限可用资源，以致使得受害者系统降^/败坏，这样一来就严重妨碍了受害者系统服务其正常客户。在DoS/DDoS攻击中^^的典型资源为网络带宽、目标主机的CPU循环以及特定TCP/IP协议堆栈结构如分段存储緩冲区和TCPSYN緩冲区。另外，因特网中盛行的易于访问的攻击脚本显著降低了发起DDoS攻击的技术障碍。因特网中帐目管理的缺乏进一步吸引了计算机窃贼利用机会攻击他人而不用担心任何随之而来的惩罚。众所周知的是，DDoS攻击相当容易，但却难以抵御DDoS攻击。根本的原因包括(1)IP欺骗(亦即，攻击包例行地携带伪造的源IP地址，这有效地隐藏了攻击源的身份并且阻止了检测、防御和追踪的努力);(2)DDoS攻击的分布式性质(亦即，巨大数量的源同时生成攻击业务，通过调用可量测性的问题来处理日益强大的攻击，对任何对策都施加了压倒性的负担)；(3)对于受害者而言没有简单的机制来区分正常的包和致命的攻击业务。作为上面的结果，通过抵御DDoS攻击来提高网络和主机(尤其^J艮务器)的可持续性就成为这个
技术领域：
中的重要目标。DDoS防御中的关键性问M如何将攻击业务与正常业务相隔离。这个问题被称为"业务区分"并且具有很大的重要性，因为DDoS攻击的目标就是要使目标主机和网络的性能严重降级，乃至完全剥夺受害者服务其正常客户的能力。随着掌握了谁是"攻击"业务、谁是"正常"业务的知识，受害者通过根据业务的类型(亦即攻击或正常)而不同地做出反应可随时击败DDoS攻击。另夕卜，考虑到不同的DDoS攻击模式，重要的另一个问_如何包含尽可能多的DDoS攻击模式。在以下中给出了示范性的DDoS攻击模式C.DouligerisandA.Mitrokotsa，"DDoSattacksanddefensemechanisms:classificationandstate-of-the-art",CVwn/wfei*7V^hvw^s，vol.44，pp.643-666,2004;以及J.MirkovicandP.Reiher，"AtaxonomyofDDoSattackandDDoSdefensemechanisms",JCMCV附戸tef0附附w/i/cflft》ws1及ev/eiv，vol.34，no.2，pp.39-53，Apr.2004。从协议利用的角度来看，DDoS攻击可以基于TCP、UDP、ICMP或其它协议。一些攻击使用不同协议的组合，如下面的表l所示。从攻击速率的观点来看，大多数的攻击是高速的基于洪流的，而新颖且更加狡猾的攻击则是低速率的DDoS攻击，如以下中给出的那样R.Chang,"Defendingagainstflooding誦based，DistributedDenialofServiceattacks:atutorial",/EEECVwf附nw/cflftVmsAfflgfl由e，vol.40，no.10，pp.42-51，2002;以及A.KuzmanovicandE.Knightly,"Low-RateTCP-TargetedDenialofServiceAttacks(TheShrewvs.theMiceandElephants)",JCM2003,Aug.2003,pp.75-86。表l.不同DDoS攻击工具<table>tableseeoriginaldocumentpage7</column></row><table>遗憾的是，与攻击方案形成对照，防御方案没有跟上DDoS攻击演变的步伐。大多数
背景技术：
DDoS防御方案旨在应对一种或两种类型的DDoS攻击，这对大范围的可能的DDoS攻击模式是不足和无效的。
发明内容实施例旨在克服
背景技术：
所遇到的前述和其它困难。特别地，基于行为的业务区分(BTD)的实施例《^供了新颖的框架，其能够抢先识别并阻止大多数的恶意攻击业务，并且还能够处理多种DDoS攻击模式。该框架的两个组成部分为业务分类和业务区分。业务分类旨在应对非TCP洪流攻击，而业务区分则用于识别恶意TCP流。BTD的实施例例如被实施，但不限于ns-2。试验结果表明，业务分类能够显著提高TCP业务的吞吐量(亦即超过70%)，而业务区分则能够i2^阻挡恶意攻击业务。我们的BTD实施例的其它益处包括但不限于(1)对设备/系统修改的需求极小；(2)实际可部署；(3)没有可量测性的问题，因为部署仅在接收器侧；(4)没有缺乏动机的问题，因为我们方案的部署是用来单独保护人们自己的网络和主机而不是其他。图1是示出如何使用接通-断开模型通it^星发送攻击包来设置低速率DoS攻击的定时的示范性图示。图2描绘了BTD框架的实施例的示范性流程图。图3是示出如何可以在防火墙或边缘路由器处的被保护网络或系统的入口点处实施业务分类的示范性图示。图4是用于BTD的实施例中的业务区分的方法的示范性流程图。图5图示了包括一个FTP源和汇(使用TCP)以及一个CBR源和汇(使用UDP)的示范性仿真想定。图6(a)是不使用业务分类策略的用于TCP流的TCP有效吞吐量和TCP吞吐量以及UDP吞吐量的示范性图示。图6(b)是使用业务分类策略的用于TCP流的TCP有效吞吐量和TCP吞吐量以及UDP吞吐量的示范性图示。图7图示了示范性试验结果，该试验结果示出了包括一个FTP源和攻击源的仿真想定中的业务区分的有效性。图8(a)是示出在BTD的实施例中使用FTP汇的攻击业务的吞吐量的示范性试验结果。图8(b)是示出在BTD的实施例中使用TCP智能汇的攻击业务的吞吐量的示范性试验结果。具体实施例方式BTD的实施例试图隔离攻击业务并且包^^尽可能多的DDoS攻击方案。DDoS攻击是资源管理问题，这样一来实施例就采用了QoS手段来与它们作战。BTD的实施例使用综合方案来有效且有力地包含多种DDoS攻击方案，而不是如
背景技术：
中那样只包含一种或两种攻击方案。BTD的实施例能够在恶意攻击业务和正常业务之间进行区分，并且能够惩罚恶意攻击业务。BTD的实施例包括至少两个组成部分。第一个组成部分基于使用的协议来分类不同类型的业务，并且用带宽分配iM目应地限制它们的速率。这种方法用来将UDP、ICMP和其它业务与TCP相隔离，并且有助于经由限制对非TCP业务的带宽分配来减轻基于UDP和ICMP的一些洪流攻击。TCP是因特网上的主导业务，并且大多数DDoS攻击都基于TCP。这样一来，下一个步骤就是要区分不同的TCP业务。根据连接建立的状态将全部TCP业务分成两组。在全部的连接建立的TCP业务当中，BTD的实施例试图根据其行为来识别流的性质，是良性的还是恶意的。如果流适当响应同一连接的其它端点的控制信号，则它被定义为"良性的"或"正常的"。相反地，"恶意的"或"攻击"流是那些不遵循TCP拥挤控制原理和侵略性地行动的流。可能的是，TCP不友好流被归类为致命流，并且被BTD方案的实施例惩罚。亦即，BTD的实施例的附带副作用是它目前没有在TCP不友好流和攻击流之间进行区别。基于该区别，一定的惩罚可能被施加给不友好流中的侵略性的流。另外，BTD的实施例是"以受害者为中心的"，不需要对源的端点或中间的路由器进行任何修改。BTD的这种特性i^免了可量测性、不同域之间的协作以及缺乏动机的问题。已实施了广泛的仿真并且提出了试验结果以使BTD的实施例的设计有效。理想的防御方案应当能够在攻击流和正常流之间进行区别，并且相应地隔离有害的业务。然而，进行这样的区别决不是轻而易举。BTD的实施例从它们的行为来识别恶意攻击业务。除了IP欺骗之外，侵略性是DDoS业务的突出特征/行为。侵略行为的一个例子是攻击源可能并不关心它是否可以从受害者接收到响应。如果是这种情况，则攻击者仍然能够通过用庞大数量的无用的包攻击其目标来实施攻击，无论是否接收到响应。甚至连使用接通-断开模型来零星设置攻击包的低速率DoS攻击也在"接通"阶段期间展示出这样的侵略特征，如图1所示。注意"侵略性，，不等效于"高速率"。高速率流可以是正常的TCP流。通过有意测试源对来自接收器的某些控制信号的响应，接收器可以识别侵略行为。这样的测试失败的任何源都被认为是致命攻击源，并且能够被相应地惩罚。然而，通过上述测试的源也不一定就是良性的。建议接收器(通常为服务器)在接收到任何连接请求/要求时都实施测试。亦即，狡猾的攻击者可能最初表现良好而通过了初始的测试，而稍后则进行有害的攻击操作。为了应对这种情形，接收器可以增加用于检测攻击流的这种测试的频率。可替选的解决方案是将某种动态特性引入到测试中，为每个流尤其是为高速率的流随机确定测试的频率和间隔。为了更好地适应高速率的合法业务，设置这样的阈值，该阈值限定了用于流的成功测试的最大数目。一旦流成功地通过了规定数目的测试，就不再对来自该流的包实施测试。通过积极地对源进行测试，接收器能够以高置信度确定来自该源的流的性质(亦即正常或攻击)并勤目应地做出反应。基于行为的过滤使攻击源陷入进退两难之境(1)冒着被识别和被惩罚的危险侵略性地发送包；或者(2)减少攻击速率以满足接收器的要求，使得攻击的效果减弱。在为攻击源制造这种困境的同时，BTD的实施例允许接收器扼杀潜在攻击的范围和影响。上述i殳计只对TCP可行，因为TCP具有内置的拥^jF控制和可靠的传输机制。注意TCP是因特网上的主导业务，并且多达90。/。的DDoS攻击使用TCP。TCP在流的数量方面占80%，相对于包的数量占卯％。这样一来，对于DDoS防御方案重要的就是要有^L1有力地适应TCP业务。然而，其它的业务如UDP和ICMP缺乏通过我们的框架可开发的替选机制。BTD的实施例使用业务分类来处理非TCP业务。业务分类是用于处理基于UDP和ICMP的洪流攻击的简单且有效的解决方案。通过限制向UDP和ICMP业务分配的资源，接收器可以显著减轻UDP和ICMP洪流攻击。业务分类的另一个好处是UDP业务比TCP业务富有侵略性得多。可以很好确立的是，当UDP业务跟TCP业务竟争带宽时，UDP能够由于其缺乏任何拥挤控制机制而抓住大多数的可用带宽并且本质上更具侵略性。因此，发送UDP业务可以有力地从TCP业务剥夺带宽的公平份额，并且使TCP流的性能降级。这样一来就证明了UDP对于DDoS攻击而言是良好的载具。这表明了在一个方案中包含不同种类的DDoS攻击模式的困难性，并且证明了还执行业务分类的必要性。需要计较的其它问题包括但不限于(1)用于应对IP欺骗的方法；以及(2)确定实施例的框架应当以什么级别(例如包级别或流级别)执行。首先识别具有伪造的源IP地址的攻击业务，然后通过观察它们的行为来辨认具有真正IP地址的正常业务。借助于验汪可以应对欺骗，而通过操纵用于TCP业务的接收方一侧的返回ACK的速率，则可以识别侵B^t为。这种方法还能够识别更加巧妙和狡猾的低速率DDoS攻击。图2描绘了BTD框架的实施例的示范性流程图。在图2的步骤2.1中，进入的包被BTD框架接收。在步骤2.2执行用于业务分类的方法。步骤2.3执行带宽分割/分配的方法。在步骤2.4中，确定TCP连接是否已被建立。如果TCP连接尚未被建立，则在步骤2.5中执行以下中的至少一种速率限制；半开连接的等待时间减少；以及增加后备队列长度。可替选地，如果TCP连接已被建立，则在步骤2.6中执行用于业务区分的方法。作为用于业务区分的方法的结果，分别在步骤2.7(a)和步骤2.7(b)中确定包是正常业务还是攻击业务。如果在步骤2.7(a)中确定接收到正常业务，则接收到的包在步骤2.8(a)中被BTD框架接纳。可替选地，如果在步骤2.7(b)中确定接收到攻击业务，则接收到的包在步骤2.8(b)中被BTD框架丢弃并拒绝接纳。对于为来自不同源的巨大数量的包服务的负载沉重的接收器(例如服务器)，BTD的实施例将^t出快速且明智的决定以接纳或丟弃1的包。不断增加的MiUL^我们以流级别设计对策。在以下段落中进一步讨论用于业务分类和带宽分配的方法。特别地在下面讨论BTD的实施例中的用于业务分类的方法。如上面讨论的那样，由于UDP缺乏内置的拥挤控制机制并且本质上具有侵略性，所以BTD的实施例首先基于协议来对业务进行分类以隔离TCP和非TCP业务。具体地，BTD的实施例将业务分成4组TCP、UDP、ICMP以及其它。BTD的实施例至少通过在IP层检查协议字段来实施这种分类。关于带宽分割/分配，作为非限制性的例子，系统管理员可以用以下方式配置其网络和分配带宽TCP:85%、UDP:13%、ICMP:1%以及其它1%。这种特定配置由站点的简档确定，并且可以动态改变。BTD的实施例的业务分类方法的目标^l:要才艮据正常业务简档来确定是否有必要实施防御以减轻可能的UDP和ICMP洪流攻击的影响。与可以根据其行为识别其性质的TCP业务不同，UDP本质上具有侵略性。作为较不"可靠"的协议，证明了不可以采取容易的方法来在正常UDP业务和攻击UDP业务之间进行区别。然而，通过施加带宽限制，BTD的实施例提供了简单但却有效的策略来在这两者之间进行区别，并且在大多数情况下并不影响网络性能。另外，限制允许1网络中的ICMP业务的数量是良好的做法，因为它仅用于诊断的目的，并且基于ICMP的DDoS攻击是常见的。图3示出了如何可以在防火墙3.1或边^i洛由器3.2处的^L保护网络或系统的入口点处实施业务分类。专门设计用于分类的网络处理器和其它ASIC的可用性使得BTD的实施例可以以线路速率运行。在考虑BTD的实施例的带宽分配/分割功能时，用于每种协议的份额是可配置的，并且通常由一个站点的例行业务简档确定。如上面讨论的那样并且根据最近的测量结果，当前因特网中的主导业务仍然是TCP。这样一来，对于普通的站点而言将大多数的带宽分配给TCP业务就是合理的，因为大多数的杀手应用程序如网络(web)、电子邮件、远程登录(telnet)以及FTP全都使用TCP,例如，不同协议之间的可能带宽分配/分割为TCP:88%、UDP:10%、ICMP:1%以及其它:1%。在业务模式将来发生变化的情况下，BTD的实施例所4C供的乃是可变的带宽分配，其能够根据新的业务模型调整带宽分配百分比，并且这样一来，BTD的实施例就能够被容易地剪裁用于将来的业务变化。在以下段落中讨论BTD的实施例中的TCP流区分的方法。连接建立确定连接是否已被建立，并且对于接收器意味良多。成功建立的连接表明端已完成了三路握手过程。DDoS防御中更加重要的是确定源是否使用了IP欺骗。另一方面，对于不完全的连接，接收器会被告警，并且在其资源消耗方面保持谨慎。用于减轻潜在攻击的可能措施包括但不限于(1)收紧向全部不完全连接的总体带宽分配；(2)显著减少超时值以避免緩冲区被半开连接长时间占用，或者根本不为半开连接提供緩沖区分配；以及(3)增加緩冲区大小用于后备。这些选项示出在图2中的步骤2.5处并在上面进行了讨论。下面讨论分析正常或良性流和致命或攻击流。在为每种协议分配份额之后，下一个任务就是要将致命或攻击TCP流与良性或正常TCP^^目隔离。简单地这样进行是因为TCP消耗了被保护网络的大多数带宽。如较早提到的那样，当业务中的很大一部分是攻击业务时，在基于洪流的DDoS攻击的情况下，直接采用公平包排队是不切实际的。TCP是端到端的方案，需要发送器和接收器之间的密切配合。为了识别TCP流的性质(亦即在成功连接之后)，接收器能够通过有意延迟ACK包来积极地测试发送器的响应。如果发送器正常，则它会相应地采取行动并减少其发送速率。相反地，对于DDoS攻击可能发生两种情况。一种情况是发送器使用伪造的源IP地址，并且这样一来就不能从接收器接收到速率减少的消息。它完全不知道适当的发送速率。另一种想定^JL送器确实接收到通知，但是它将其忽略而只是保持发送包，这样一来就违反了协议，并且它可能被接收方惩罚以减少其份额乃至阻塞其业务。这个过程是动态的。被保护的站点能够决定速率减少的频率和程度，使得没有作恶者能够轻易地愚弄系统以相信来自作恶者的业务是正常的。图4描绘了用于BTD的实施例中的业务区分的方法的示范性流程图。当在步骤4.1处新进入的包到达时，接收器同样在图4的步骤4.1中首先通过检查元组(源IP地址，源端口号，目的IP地址，目的端口号)来确定当前包的流属于哪里。在步骤4.2中，如果该方法确定包是新的流的第一个包，则接收器相对于接收器所设置的阈值在步骤4.3中检查所接纳的流的数目是否达到了最大流计数，以确g供适当的服务质量。如果最大流计数确实发生，则在步骤4.5中丢弃包。否则，在步骤4.7中更新接收器所维护的流表、将流计数递增1以及初始化几个计数器如成功测试的数目和失败测试的数目之后，在步骤4.9中接纳该新的包。对于现有流的包，接收器检查该流的行为历史。在图4的步骤4.3中，如果失败测试的数目不小于阈值/,则会在步骤4.5中丢弃该包。选择大于1的整数来防止BTD的实施例错误地识别流的行为。低的/值可能加剧包的丢弃。在4m识别的情况下，来自无害的流的随后的包会被阻塞。选择过高的值也不明智。高的/延迟了包丟弃决定，并且这样一来恶意流的随后的包就仍然可能消耗系统资源。试验结果表明/=3提供了适当的识别速率和可接受的性能影响之间的良好平衡。另夕卜，值得一提的是接收器具有两个选项来选择在这一点对源进行惩罚。一个选项是故意地发送DUPACK，迫使源iiA緩'lt^动的阶段。另一个选项是义送RST以停止连接，使得其资源不被行为不端的源浪费。在图4中，我们仅示出了包丟弃的操作而没有任何进一步的惩罚。对于行为过去不是那么有害的流，BTD的实施例进一步检查该流是否已通过了一定数目的测试A,如图4的步骤4.6所示。接收器将会直接接纳已成功通过了A次测试的流的任何包(例如，不得不进行某种折衷以确定适当的A值。选择高的A值可能伤害良好但高速率的流的性能，而使用低的值则狡猾的攻击者可能容易地避开测试。在步骤4.6中，在广泛的仿真之后我们将A设置为6)。对于其它的流,BTD的实施例在图4的步骤4.8中进一步检查流的当前状态。如果流处在测试之下，则其当前速率将不会超过其以前速率的一半(亦即，接收器通过操纵逆向ACK速率来实施这种约束)。如果流遵守该约束，则在步骤4.13中流通过当前的测试；在步骤4.14中pass—num递增l;并且在步骤4.16中接纳包。否则，在步骤4.13中流一次效i试失败；在步骤4.15中fail—num递增l;并且在步骤4.17中丟弃包。在步骤4.8确定流没有处于测试状态下的情况下，将其发iMil率与每个流的公平份额的速率相比较。比较的结果用于在步骤4.10中确定用于该流的测试概率。步骤4.12确定是否需要测试。明显地，具有较小带宽消耗的流经受较少数目的测试。步骤4.1确定测试之间的等待时间。用于高速率流(公平份额之上)的测试概率/i为l/(pass_num+l)。在最开始，pass_num对于全部流都为0。因此，只要高速率^尚未通过测试，其被测试的机会为100%。随着流的成功测试的数目增加，其测试概率下降。用于较少资源消耗的流的测试概率/;为1/max(附，2吆)，其中/w是流的总数。对于正常的情况，附》2/1;这杯一来就有/=1/附。我们使用max(.)函数来应对只有几个流存在于系统中的情况，并且确保用于低速率的流的测试概率至多为用于高速率的流的测试概率的1/2。根据以下公式计算流的速率(num_pkt*sz_pkt)/t(1)其中，t为时间间隔(窗口)，num_pkt为这个时期期间接收到的包的数目，szjkt为包的大小。值得一提的是这里计算的流的速率不是如其他人通常所使用的那样的流的平均速率，因为一旦它通过测试我们就更新流的起动时间。这样做时，我们能够有力地挫败低速率的DoS攻击，该低速率的DoS攻击发送突发的攻击包以引发拥挤，并且在长得多的时期内保持寂静以显著降低其平均速率，以便逃脱检测和过滤。四种想定可能发生(l)攻击源总是行为良好，并且这样一来攻击的效果就大大减弱；(2)攻击源开始行为良好稍后行为不端。在这种情况下，测试状态下当前速率至多为以前速率的1/2的约束将不会被满足，并且源测试失败；(3)攻击源总是行为不端，这可以通过失败计数容易地挫败；以及(4)攻击源开始行为不端稍后行为良好。对于想定(4)，攻击源容易招致更多被测试的机会，因为一旦测试失败其pass一num就为fail一num所抵消。要注意的是低速率的流也经受测试，尽管在A们的设计中i以较低的概率进行。随着时间推移，低速率的流从未被接收器测试的机会非常低。BTD的实施例实施这种策略来包含这样的情况某些低速率的流是恶意的。下面讨论对不良TCP流的惩罚。接收器具有两个选项供选择iMt源进行惩罚。一个选项是故意地发送DUPACK，这样一来就迫4吏源1緩慢起动的阶段。另一个选项是发送RST以停止连接，使得其资源不被行为不端的源浪费。一旦流测试失败3次，BTD的实施例亂&送RST。在图4中示出了包丢弃的操作而没有任何进一步的惩罚。下面讨论关于业务分类的试验结果。为了测试业务分类的有效性，我们设立了简单的仿真想定，其包括1个FTP源和汇(使用TCP)以及l个CBR源和汇(使用UDP),如图5所示。这些流穿it^目同的瓶颈M。FTP源和检查点之间、CBR源和检查点之间、目的地和CBR汇之间以及目的地和FTP汇之间的fe^錄全都为带宽10Mb和延迟2ms。检查点和目的地之间的瓶颈^4lt没置为1Mb和10ms。CBR速率为10Mb。在检查点处，业务分类对于TCP为卯％,对于UDP为10%。在进行仿真比较时，除了入口点是否实施业务分类之外，一切都相同。在图6(a)和图6(b)中展示了FTP业务的吞吐量。图6(a)描绘了不^f吏用业务分类策略的用于TCP流的TCP有效吞吐量和TCP吞吐量以及UDP吞吐量。在图6(a)和图6(b)中，TCP业务在时间0s处起动而UDP业务则稍后在Is处开始。在0-ls期间，TCP是链路中的仅有业务，并且其有效吞吐量和吞吐量达到了最大值每O.ls12包(瓶颈銜洛的带宽为lmb/s,每个包为1000*8=8000位，lmb*0.1/8000=12)。从1.2s开始，UDP业务开始并入，并且它如此快速地捕捉可用带宽，以至于TCP吞吐量在1.3-1.8s期间减少到1包，从1.9s开始供应不足。与此形成对照，在业务分类的情况下，TCP吞吐量甚至在1.9s之后也保持每0.1s3包，同时UDP业务不多于每0.1s9包。发送的包的总数在图6U)中为127个，在图6(b)中为234个(我们在图6(b)中仅描绘了到1.9s为止的吞吐量以便比较)。因此，TCP业务的吞吐量在业务分类的情况下增加了70.8%。尽管UDP业务仍然抓住了比TCP更多的份额，如上面解释的那样，但这是由于TCP的内置拥挤控制机制。下面讨论TCP流区分。为了测试业务流区分的有效性，设立了包括FTP源和攻击源的仿真想定，如图7所示。这些流穿it^目同的瓶颈銜洛。不同之处在于一个仿真使用了常规FTP汇来接受来自两个流的包，而另一个仿真则使用了我们开发的TCP汇，其被称作TCP智能汇。仿真结果如图8(a)和图8(b)所示。图8(a)示出了使用FTP汇的攻击业务的吞吐量，而图8(b)则展示了使用BTD的实施例中的TCP智能汇的攻击业务的吞吐量。在3.2s处，攻击业务的吞吐量急剧下降。在42.3s之后，攻击业务被完全阻塞。与此形成对照，使用
背景技术：
FTP汇作为接收器时，发送器可能在其生命周期期间保持最高的吞吐量。结果表明了BTD的实施例的业务区分方法的有效性。如上面讨论的那样，BTD的实施例包括两个组成部分业务分类和业务区分。前者用于减少非TCP业务的容量，而后者则能够经由抢先测试来识别恶意的TCP流。BTD的实施例的突出益处列举如下BTD能够经由抢先测试来有力地且有效地识别和阻塞攻击流；BTD能够包舍i午多DDoS攻击模式；BTD需要极小的修改；以及BTD没有诸如可量测性和缺乏动积i之类的问题。仿真和上述讨论的试验结果已证实了我们的设计。另夕卜，下面是BTD的实施例的额外方面(1)自动识别网络状况；(2)自适应地选择用于抢先测试的各种^;以及(3)在诸如但不限于Linux内核之类的操作系统环境中实施该框架。总之，BTD的实施例首先试图经由业务分类来减少非TCP业务的容量，这样一来就减轻了流行的UDP和ICMP洪流攻击。对于TCP流，BTD的实施例试图通过观察行为来区别它们的性质。表2列举了BTD的实施例的框架中采用的用来适应正常业务和约束攻击业务的策略。表2.BTD的实施例采取用来应对不同业务模型的措施<table>tableseeoriginaldocumentpage17</column></row><table>当然要理解的是，尽管刚刚已描述了具体实施例，但是请求保护的主题范围不限于具体实施例或实施方式。例如，一个实施例可以用硬件实现，如被实现以例如在设备或设备的组合上运行，而另一个实施例则可以用软件实现。同样地，实施例可以用固件实现，或者例如作为硬件、软件和/或固件的任何组合而被实现。同样地，虽然请求保护的主题范围不限于这个方面，但是一个实施例可以包括一个或多个物品，如一个或多个存储介质。诸如像一个或多个CD-ROM和/或盘之类的这种存储介质可以在其上存储指令，该指令当由诸如像计算机系统、计算平台或其它系统之类的系统执行时，可以导致诸如像前述实施例中之一之类的根据请求保护的主题的方法的实施例被执行。作为一个潜在的例子，计算平台可以包括用于实现一个或多个处理单元或处理器的设备或装置、一个或多个输入/输出设备如显示器、勉和/或鼠标和/或一个或多个存储器如静态随MM储器、动态随M取存储器、快闪存储器和/或硬盘驱动器以及防火墙类型设备的一个或多个路由器。例如，显示器可以用于显示诸如可能相互关联的一个或多个查询和/或一个或多个树表示，尽管请求保护的主题仍然在范围上不限于这个例子。同样地，实施例可以作为系统而被实现，或者作为诸如计算机系统和用于计算机系统的接口(例如但不限于路由器和防火墙)、移动和/或其它类型的通信系统和其它>^的电子系统之类的部件的任何组合而被实现。在前面的说明中描述了请求保护的主题的不同方面。为了说明起见，阐述了特定的数字、系统和/或配置以提供对请求保护的主题的全面理解。然而，对受益于本公开的本领域技术人员而言应该明显的是，在不使用详细细节的情况下也可以实施请求保护的主题。在其它实例中，公知的特征被省略和/或简化，以便不使请求保护的主题模糊。尽管在此已经说明和/或描述了特定特征，但是本领域技术人员也将会想出许多修改、替换、改变和/或等效。因此，应该理解的是，所附权利要求打算覆盖落入请求保护的主题的真实精神内的所有的这种修改和/或改变。权利要求1.一种用于基于行为的业务区分(BTD)的方法，包括接收进入的包；执行用于业务分类的方法，该用于业务分类的方法配置成确定所述进入的包的协议；执行带宽分割/分配的方法；确定TCP连接是否已被建立，其中当所述TCP连接尚未被建立时执行速率限制、用于半开连接的等待时间减少和增加后备队列长度中的至少一种，并且其中当所述TCP连接已被建立时执行用于业务区分的方法，其中当对正常业务进行了确定时，接纳所述包；以及其中当对攻击业务进行了确定时，丢弃所述包。2.根据权利要求1所述的方法，其中，所述用于业务分类的方法进一步包括对于所述1的包至少在因特网协议(IP)层检查协议字段以确定包分类。3.根据权利要求2所述的方法，其中，被检查的协议字段确定所述包是否被分类为TCP、UDP、ICMP和其它包中的一种。4.根据权利要求3所述的方法，其中，当被检查的协议字段是UDP、ICMP和其它包中的至少一种时，带宽分割/分配的方法进一步包括确定为所述l的包分配的带宽；以及基于被确定的带宽将所述l的包分类为UDP、ICMP和其它中的一种。5.根据权利要求4所述的方法，其中，在防火墙或边^i洛由器执行所述业务分类的方法。6.根据权利要求5所述的方法，其中，所述业务区分的方法进一步包括检查ii^的包的源IP地址、源端口号、目的IP地址和目的端口号；确定所述进入的包是新的流的第一包还是多个被接纳的流中的一个流的包；确定何时被接纳的流的数目相对于预定的第一阈值达到最大流计数，所述第一阈值被设置以确g供适当的服务质量(QoS);通过使流计数增加1来更新最大计数流表；当最大流计数为在所述预定的第一阈值以下和等于所述预定的第一阈值中的至少一种情况时，使用于成功测试和失败测试的计数器增加，并且接纳所述新的流的l的包；当所述最大流计lt^过所述预定的阈值时，丢弃所述1的包；当成功测试超过第二预定阈值时，接纳来自现有流的进入的包；当失败测试大于第三预定阈值时，丢弃来自现有流的1的包；检查包的流以确定当前速率是否满a过以前速率一半的约束；当所述当前速率超过所述约束时，使faiLnum计数器增加；以及当所述当前速率为小于和等于所述约束中的至少一种情况时，使pass一num计数器增加；当所述fail一num计数器小于第四预定阈值时，接纳所述1的包；以及当所述fail一num计数器大于第五预定阈值时，丟弃所述1的包。7.—种用于BTD的系统，包括用于接收进入的包的装置；用于执行用于业务分类的方法的装置，该用于业务分类的方法配置成确定所述l的包的协i义；用于执行带宽分割/分配的方法的装置；用于确定TCP连接是否已被建立的装置，其中当所述TCP连接尚未被建立时用于执行速率限制、用于半开连接的等待时间减少和增加后备队列长度中的至少一种的装置，并且其中当所述TCP连接已被建立时用于执行用于业务区分的方法的装置，其中当对正常业务进行了确定时，用于接纳所述包的装置；以及其中当对攻击业务进行了确定时，用于丟弃所述包的装置。8.—种包含软件代码的处理器可读^h质，所述软件代码当由处理器执行时，使所述处理器执行用于基于行为的业务区分(BTD)的方法，所述方法包括接收l的包；执行用于业务分类的方法，该用于业务分类的方法配置成确定所述进入的包的协i义；执行带宽分割/分配的方法；确定TCP连接是否已被建立，其中当所述TCP连接尚未被建立时执行速率限制、用于半开连接的等待时间减少和增加后备队列长度中的至少一种，并且其中当所述TCP连接已被建立时执行用于业务区分的方法，其中当对正常业务进行了确定时，接纳所述包；以及其中当对攻击业务进行了确定时，丢弃所述包。9.根据权利要求8所述的处理器可读介质，其中，所述用于业务分类的方法进一步包括对于所述i^的包至少在因特网协议(IP)层处检查协议字段以确定包分类。10.根据权利要求9所述的处理器可读介质，其中，被检查的协议字段确定所述包是否被分类为TCP、UDP、ICMP和其它包中的一种。11.根据权利要求10所述的处理器可读介质，其中，当被检查的协议字段是UDP、ICMP和其它包中的至少一种时，带宽分割/分配的方法进一步包括确定为所述1的包分配的带宽；以瓦基于被确定的带宽将所述进入的包分类为UDP、ICMP和其它中的一种。12.根据权利要求11所述的处理器可读介质，其中，在防火墙或边^洛由器执行所述业务分类的方法。13.根据权利要求12所述的处理器可读介质，其中，所述业务区分的方法进一步包括检查i^的包的源IP地址、源端口号、目的IP地址和目的端口号；确定所述进入的包是新的流的第一包还是多个被接纳的流中的一个流的包；确定何时被接纳的流的数目相对于预定的第一阈值达到最大流计数，所述第一阈值被设置以确M供适当的服务质量(QoS);通过使流计数增加1来更新最大计数流表；当最大流计数为在所述预定的第一阈值以下和等于所述预定的第一阈值中的至少一种情况时，使用于成功测试和失败测试的计数器增加，并且接纳所述新的流的l的包；当所述最大流计lb适过所述预定的阈值时，丢弃所述进入的包；当成功测试超过第二预定阈值时，接纳来自现有流的i^的包；当失败测试大于第三预定阈值时，丢弃来自现有流的ii^的包；检查包的流以确定当前速率是否满a过以前速率一半的约束；当所述当前速率超过所述约束时，使fail一num计数器增加；以及当所述当前速率为小于和等于所述约束中的至少一种情况时，使pass—num计数器增加；当所述fail—num计数器小于第四预定阈值时，接纳所述i^的包；以及当所述faiLnum计数器大于第五预定阈值时，丢弃所述进入的包。全文摘要实施例涉及用于基于行为的业务区分(BTD)的方法，该方法最初接收进入的包并且执行业务分类以确定进入的包的协议。另外，BTD执行带宽分割/分配以进一步支持在诸如UDP和ICMP之类的非TCP业务类型当中进行业务分类。对于TCP业务，用于BTD的方法确定TCP连接是否已被建立，并且当TCP连接尚未被建立时，执行以下中的至少一种速率限制、用于半开连接的等待时间减少以及增加后备队列长度。如果TCP连接已被成功建立，则用于BTD的方法进一步包括用于业务区分的抢先测试，所述业务区分识别被接纳的正常业务和被丢弃的攻击业务。文档编号G06F11/00GK101529386SQ200780007403公开日2009年9月9日申请日期2007年3月5日优先权日2006年3月3日发明者尼尔万·安萨里,高志强申请人:新泽西理工学院