CN103973584B - 动态切换数据包的转发方式的方法和设备 - Google Patents

Abstract

本申请涉及一种动态切换数据包的转发方式的方法和设备。该方法包括：在虚拟服务器上按照单向转发方式转发接收到的针对虚拟服务的地址的数据包；判断该虚拟服务的地址是否受到同步泛洪攻击；当判定该虚拟服务的地址受到同步泛洪攻击时，在虚拟服务器上执行用于防御同步泛洪攻击的防御操作，并按照双向转发方式转发接收到的针对该虚拟服务的地址的数据包；判断同步泛洪攻击是否停止；以及当判定同步泛洪攻击停止时，在虚拟服务器上停止执行防御操作并且恢复成按照单向转发方式转发接收到的针对该虚拟服务的地址的数据包。由此可以实现在智能监测和防御同步泛洪攻击的前提下最大限度地利用虚拟服务器的资源。

Description

动态切换数据包的转发方式的方法和设备

技术领域

本申请涉及计算机通信领域，尤其涉及基于虚拟服务器的负载均衡技术，更具体地涉及动态切换数据包的转发方式的方法和设备。

背景技术

这里的内容尽管是在背景技术标题下阐述的，但是其中也包含了本发明人的发现和构思，所以不应被完全视为现有技术。

随着互联网的迅猛发展，用户访问量和数据流量快速增长，计算机网络的处理能力和计算强度也相应地增大，使得单一的服务器设备根本无法承担。在这样的情况下，如果扔掉现有设备去做大量的硬件升级，这样将造成现有资源的浪费，而且如果再面临下一次业务量的提升时，这又将导致再一次硬件升级的高额成本投入，甚至性能再卓越的设备也不能满足当前业务量增长的需求。

于是出现了负载均衡技术，将负载（用户访问量和数据流量）分摊到多个后端服务器上进行执行，从而共同完成工作任务，这样可以大大提高系统容量和灵活地调整系统容量。目前常用的负载均衡技术之一是基于虚拟服务器实现的，诸如LVS（Linux虚拟服务器），其中将多个后端服务器集成为一个虚拟服务器，实现对多个后端服务器的数据包流量转发和负载均衡。

然而，在上述负载均衡过程中同样受到同步泛洪攻击的威胁。同步泛洪攻击（SYNFlood）是一种常见的针对TCP（Transmission Control Protocol，传输控制协议）连接的黑客攻击手段，其利用IPv4（Internet Protocol version4，网际协议版本4）中TCP协议的三次握手过程发起攻击。TCP协议规定，一端向另一端发起TCP连接时，需要首先发送同步（SYN）数据包到对方，对方收到后发送一个同步/确认（SYN/ACK）数据包回来，发起方再发送确认（ACK）数据包回去。这样三次握手结束。其中在服务器端收到同步数据包时，在发送同步/确认数据包回客户端前，服务器端会先分配好一个数据区专门服务于这个即将形成的TCP连接。一般把收到同步数据包而未收到确认数据包时的连接状态称为半连接状态。

在最常见的同步泛洪攻击中，攻击者在短时间内发送大量的同步数据包给服务器端。只要这些同步数据包具有不同的源地址（这一点对于攻击者来说是很容易伪造的），根据上面的描述可知，服务器就会为每个同步数据包分配一个特定的数据区。这将给服务器系统造成很大的系统负担，最终导致系统不能正常工作。

目前在基于LVS的负载均衡中，作为防御同步泛洪攻击的一种方案，通常执行同步代理（SYN Proxy）操作，同时配合使用全网络地址转换（Full NAT）的转发方式进行数据包转发。

SYN Proxy是基于同步cookie（SYN cookie）机制，在服务器收到同步数据包并返回同步/确认数据包时，不分配专门的数据区供建立连接使用，而是根据同步数据包计算出一个cookie值。在收到确认数据包时，服务器再根据这个cookie值验证数据包的合法性。如果合法，才会建立数据区来处理未来的TCP连接。

在Full NAT转发方式中，发往LVS的数据包的源地址和目的地地址都将被替换，源地址被替换成LVS网卡接口上配置的本地地址，目的地地址被替换成后端服务器的地址，然后转发给后端服务器。后端服务器应答的数据包也会发回给LVS，这时LVS再将应答数据包的源地址替换成虚拟服务的地址，并将目的地地址替换成客户端的地址，再回传给客户端。

然而，在现有Full NAT和SYN Proxy的防御方式下，一旦配置，就会对所有的访问数据流都生效，并且需要访问的入流量和出流量都经过LVS。如此，在没有发生同步泛洪攻击时，LVS的一部分计算资源就浪费在对正常访问请求的多余处理上。另外，由于双向流量都经过LVS，LVS的诸如CPU、带宽等的物理资源都要被双向流量所共享，因而降低了LVS的吞吐量。

因此，期望一种能够在防御同步泛洪攻击的同时最大化地利用LVS的资源的技术。

发明内容

如上所述，在目前基于LVS的负载均衡方案中，可以执行SYN Proxy操作，同时配合采用Full NAT转发方式进行数据包转发，从而成功防御同步泛洪攻击。但是，由于LVS会对所有新建连接都进行SYN cookie的校验，因此，每个新建连接都会有一次多余的数据包来回（即防御操作）；同时由于SYN Proxy机制的原理导致，在进行转发之前，需要在LVS上对所有入流量和出流量的数据包做序列号的映射，也就是，需要访问的入流量和出流量都经过LVS才能成功防御。

显然，当没有发生同步泛洪攻击时，上述操作都是没有必要的。这样不仅浪费了LVS的资源，而且一定程度上也影响了数据包的转发效率。

本申请发明人注意到，目的地网络地址转换（DNAT）作为LVS能够采用的另一种数据包转发方式，其中只将发往LVS的数据包的目的地地址转换成后端服务器的地址，就转发给后端服务器，然后后端服务器应答的数据包直接返回给客户端，而无需经过LVS。因而，与Full NAT转发方式相比，在DNAT转发方式下可以提高数据包的转发效率，并且由于在DNAT转发方式下可以只有访问的入流量经过LVS，因而也可以充分利用LVS的资源。但是，在DNAT转发方式下无法使用SYN Proxy机制防御同步泛洪攻击。

于是，本申请发明人想到，可以只在检测到同步泛洪攻击时执行SYNProxy防御操作，同时配合采用使得访问的入流量和出流量都经过LVS的双向转发方式（诸如Full NAT或NAT）进行数据包转发，而在正常情况下或者攻击结束后不执行或者停止执行上述防御操作，并且切换成采用转发效率相对较高的单向转发方式（诸如DNAT）进行数据包转发。这样，可以实现在保证防御攻击的前提下最大限度地利用LVS的资源。

因此，本申请的主要目的在于提供一种可以在保证防御攻击的前提下最大限度地利用虚拟服务器的资源的技术。

根据本申请的一个方面，提供一种用于动态切换数据包的转发方式的方法，其特征在于，包括：在虚拟服务器上按照单向转发方式转发接收到的针对虚拟服务的地址的数据包，该单向转发方式用于只将来自客户端的数据包转发给后端服务器；判断该虚拟服务的地址是否受到同步泛洪攻击；当判定该虚拟服务的地址受到同步泛洪攻击时，在虚拟服务器上执行用于防御同步泛洪攻击的防御操作，并按照双向转发方式转发接收到的针对该虚拟服务的地址的数据包，该双向转发方式用于将来自客户端的数据包转发给后端服务器并将来自后端服务器的数据包转发给客户端；判断同步泛洪攻击是否停止；以及当判定同步泛洪攻击停止时，在虚拟服务器上停止执行防御操作并且恢复成按照单向转发方式转发接收到的针对该虚拟服务的地址的数据包。

根据本申请的另一方面，提供一种动态切换数据包的转发方式的设备，其特征在于，包括：单向转发装置，用于在虚拟服务器上按照单向转发方式转发接收到的针对虚拟服务的地址的数据包，该单向转发方式用于只将来自客户端的数据包转发给后端服务器；攻击判断装置，用于判断该虚拟服务的地址是否受到同步泛洪攻击；防御和双向转发装置，用于当判定该虚拟服务的地址受到同步泛洪攻击时，在虚拟服务器上执行用于防御同步泛洪攻击的防御操作，并按照双向转发方式转发接收到的针对该虚拟服务的地址的数据包，该双向转发方式用于将来自客户端的数据包转发给后端服务器并将来自后端服务器的数据包转发给客户端；攻击停止判断装置，用于判断同步泛洪攻击是否停止；以及停止防御和恢复装置，用于当判定同步泛洪攻击停止时，在虚拟服务器上停止执行防御操作并且恢复成按照单向转发方式转发接收到的针对该虚拟服务的地址的数据包。

与现有技术相比，根据本申请的技术方案，在虚拟服务器上引入攻击监测机制，在判定受到同步泛洪攻击时执行防御操作并配合采用双向转发方式转发数据包，而在正常情况下或在判定攻击停止后不执行或者停止执行防御操作并切换成采用转发效率更高的单向转发方式转发数据包，从而可以实现动态地切换数据包的转发方式，进而在保证防御攻击的前提下最大限度地利用虚拟服务器的资源。另外，这种监测和防御的粒度可以精确到某个虚拟服务，即只对受到攻击的虚拟服务启动防御操作模式，而对没有受到攻击的虚拟服务仍然维持正常操作模式，从而能够达到智能监测和防御攻击。

附图说明

此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1示出根据本申请一个方面的动态切换数据包的转发方式的方法的流程图；

图2示出了根据本申请一个实施例的判断虚拟服务地址是否受到同步泛洪攻击的步骤的流程图；

图3示出了根据本申请一个实施例的防御操作的流程图；

图4示出了根据本申请一个实施例的判断同步泛洪攻击是否停止的步骤的流程图；

图5示出了根据本申请另一方面的动态切换数据包的转发方式的设备的示意框图；

图6示出了根据本申请一个实施例的攻击判断装置的具体示意框图；以及

图7示出了根据本申请一个实施例的攻击停止判断装置的具体示意框图。

具体实施方式

本申请的主要思想在于，默认不进行对攻击的防御，而是采用转发效率较高的单向转发方式进行流量转发，同时采用一定的机制去监测攻击的出现，一旦监测到攻击出现就执行防御操作并且配合切换成双向转发方式进行数据包转发。而在攻击防御状态下，监测到攻击已经停止时，则恢复成单向转发方式进行数据包转发。也就是，在虚拟服务器中引入攻击监测机制，使得在有攻击时执行防御操作并采用双向转发方式进行数据包转发，而在没有攻击时或者攻击停止后采用单向转发方式进行数据包转发，从而实现动态切换数据包转发方式，以在保证防御攻击的前提下最大限度地利用虚拟服务器的资源。

为使本申请的目的、技术方案和优点更加清楚，以下结合附图及具体实施例，对本申请作进一步地详细说明。

根据本申请一个方面的实施例，提供了一种动态切换数据包的转发方式的方法。

图1示出根据本申请一个方面的动态切换数据包的转发方式的方法的流程图。

如图1所示，在步骤S110处，在虚拟服务器上按照单向转发方式转发接收到的数据包，所述单向转发方式用于只将来自客户端的数据包转发给后端服务器。

例如，在诸如手机、台式电脑、膝上型电脑之类的客户端上通过虚拟服务的地址（例如IP地址或MAC地址）访问一个网站时，客户端需要与该网站对应的该虚拟服务的地址建立TCP连接。而该网站由一个服务器集群维护，例如包括一个虚拟服务器和多个后端服务器（真实服务器）。在建立连接时以及建立连接后，该网站的虚拟服务器都起到在客户端和后端服务器之间进行数据包转发的作用。

在本申请的一个实施例中，例如虚拟服务器为LVS，单向转发方式为DNAT。在默认状态下或者在非防御状态下，当LVS接收到来自客户端的数据包时，可以采用DNAT方式转发该数据包，即，只将该数据包的目的地地址（例如IP地址或MAC地址）转换成后端服务器的地址，然后转发到相应的后端服务器。并且后端服务器返回的数据包例如经由服务器网关直接返回给客户端，而不再经过LVS。

这里，虚拟服务器可以有多个，并且不限于LVS，还可以为任意其它现有的或者未来开发的用于在客户端和后端服务器之间转发数据包的服务器设备。单向转发方式并不限于DNAT，还可以为任意其它现有的或者未来开发的用于只将来自客户端的数据包转发给后端服务器的转发方式。

在步骤S120处，判断上述虚拟服务的地址是否受到同步泛洪攻击。

具体而言，在非防御状态下，虚拟服务器可以通过本领域已知的或者未来开发的任意合适方式来判断某个虚拟服务的地址是否受到同步泛洪攻击。这可以视为是虚拟服务器本身在正常状态（诸如DNAT的单向转发方式）下对攻击的一种动态监测。

图2示出了根据本申请一个实施例的判断虚拟服务地址是否受到同步泛洪攻击的步骤的流程图。

这里，虚拟服务器在接收到针对某个虚拟服务的地址的同步数据包之后已经回复同步/确认包、在等待确认包的状态，称为半连接状态。虚拟服务器在接收到针对某个虚拟服务的地址的同步数据包之后已经回复同步/确认包并且也已经收到确认包的状态（即完成了三次握手过程），称为连接状态。

本发明人注意到，在非防御状态的正常流量下，某个虚拟服务当前处于半连接状态的半连接数目N_synrcv_conns非常小，但在非防御状态的攻击流量下，半连接数目N_synrcv_conns剧增，而某个虚拟服务当前处于连接状态的连接数目N_active_conns相对较小。因而，可以根据非防御状态下的该半连接数目和连接数目的变化，判断这个虚拟服务是否受到同步泛洪攻击。下面结合图2具体说明这个过程。

如图2所示，在步骤S210处，获取与所述虚拟服务的地址处于半连接状态的半连接数目N_synrcv_conns。

这里，虚拟服务器可以通过任意合适方式例如计数器来对与虚拟服务的地址处于半连接状态的连接进行计数。

在步骤S220处，获取与虚拟服务的地址已建立连接的连接数目N_active_conns。

这里，与上述虚拟服务的地址已建立连接是指与该虚拟服务的地址对应的TCP三次握手过程已经完成。可以通过任意合适方式例如计数器来对当前与该虚拟服务的地址已建立的连接（即上述的活跃连接）进行计数。

在步骤S230处，根据半连接数目N_synrcv_conns和连接数目N_active_conns来判断虚拟服务的地址是否受到同步泛洪攻击。

正如前面提到的，可以根据非防御状态下的上述半连接数目N_synrcv_conns和连接数目N_active_conns的变化，判断这个虚拟服务是否受到同步泛洪攻击。

在一个具体实施例中，在非防御状态下，可以通过判断半连接数目N_synrcv_conns与连接数目N_active_conns的比值N_synrcv_conns/N_active_conns是否超过阈值T1（第一阈值），来判断虚拟服务的地址是否受到同步泛洪攻击。

在非防御状态下受到攻击时，半连接数目N_synrcv_conns会剧增，连接数目N_active_conns变化较小。例如，N_synrcv_conns/N_active_conns可以在10³量级，甚至达10⁴量级。上述阈值T1可以是根据经验预先设定的任意合适值，并且例如可以在10³-10⁴量级。

例如，当N_synrcv_conns/N_active_conns大于该预设阈值T1时，可以判定虚拟服务的地址受到同步泛洪攻击。当N_synrcv_conns/N_active_conns小于或等于该预设阈值T1时，可以判定虚拟服务的地址没有受到同步泛洪攻击。

这里需要指出的是，本申请并不限于N_synrcv_conns/N_active_conns这一比值的判断方式。例如，还可以通过连接数目与半连接数目的比值N_active_conns/N_synrcv_conns来判断，当N_active_conns/N_synrcv_conns小于某一阈值时，判定虚拟服务的地址受到同步泛洪攻击。另外，也可以通过其它本领域已知的或未来开发的任意合适方式进行上述判断，例如可以通过单位时间内半连接数目和连接数目的变化进行判断，也可以只通过半连接数目的变化进行判断，本领域技术人员基于这里公开的内容能够想到如何实施这些判断方式，所以这里不再赘述。

由于同步泛洪攻击的攻击频率很难预测，如果对于攻击出现的监测过于灵敏，可能导致由于攻击频率的瞬间变换而引起转发方式的频繁切换，比如攻击的短暂发生可能引起不必要的转发方式切换。

例如，在另一具体实施例中，在非防御状态下，可以通过判断半连接数目与连接数目的比值N_synrcv_conns/N_active_conns连续大于阈值T1（第一阈值）的次数m1是否超过预定数目M1（第一预定数目），来判定虚拟服务的地址是否受到同步泛洪攻击。其中M1可以是根据经验预先设定的值。

当m1高于M1时，判定虚拟服务的地址受到同步泛洪攻击。当m1低于或等于M1时，判定虚拟服务的地址没有受到同步泛洪攻击。

根据这个实施例，虚拟服务器可以在非防御状态下更准确地判断虚拟服务的地址是否受到同步泛洪攻击，从而减少转发方式的抖动。

相应地，在这样的实施例中，例如也可以通过判断连接数目与半连接数目的比值N_active_conns/N_synrcv_conns连续小于某一阈值的次数是否超过某一预定数目来判断虚拟服务的地址是否受到同步泛洪攻击。另外，也可以通过其它本领域已知的或未来开发的任意合适方式进行上述判断，例如可以通过单位时间内半连接数目和连接数目的连续变化进行判断，也可以只通过半连接数目的连续变化进行判断，本领域技术人员基于这里公开的内容能够想到如何实施这些判断方式，所以这里不再赘述。

至此，通过上述步骤虚拟服务器判定出在非防御状态下虚拟服务的地址是否受到同步泛洪攻击。当判定虚拟服务的地址没有受到同步泛洪攻击时，虚拟服务器仍然按照上述步骤S110中的正常操作模式工作。当判定虚拟服务的地址受到同步泛洪攻击时，虚拟服务器可以切换到防御操作模式工作，以执行防御操作并配合切换数据包的转发方式以便成功防御攻击。

具体而言，返回参照图1，在步骤S130处，当判定虚拟服务的地址受到同步泛洪攻击时，在虚拟服务器上执行用于防御同步泛洪攻击的防御操作，并按照双向转发方式转发接收到的针对虚拟服务的地址的数据包，双向转发方式用于将来自客户端的数据包转发给后端服务器并将来自后端服务器的数据包转发给客户端。

如上所述，在非防御状态下，虚拟服务器按照诸如DNAT的单向转发方式转发接收到的数据包。当虚拟服务器监测到同步泛洪攻击出现时，执行诸如SYN Proxy的防御操作并配合切换成诸如Full NAT或NAT的双向转发方式转发接收到的数据包。

上述防御操作可以基于本领域已知的SYN cookie机制，诸如SYN Proxy。图3示出了根据本申请一个实施例的防御操作的流程图。

如图3所示，在步骤310处，当从客户端接收到同步数据包时，虚拟服务器根据同步数据包的参数计算验证码，并向客户端返回包含验证码作为序列号的同步/确认数据包。

如本领域已知的，可以根据接收到的同步数据包的各项信息依据特定算法来计算得到一个验证码（cookie值），将该验证码作为同步/确认数据包的序列号随同步/确认数据包返回给客户端。该特定算法可以是本领域已知的或未来开发的任意合适算法。

接下来，在步骤320处，当从客户端接收到确认数据包时，根据确认数据包的序列号，确定是否针对该同步数据包建立客户端与虚拟服务之间的连接。

具体来说，根据接收到的确认数据包的序列号（其应与同步/确认数据包的序列号相同，即应为上述验证码）依据作为上述特定算法的逆运算的算法判定该确认数据包是否合法，当合法时虚拟服务器才为该同步数据包分配数据区以建立客户端与虚拟服务之间的连接从而处理这个连接的后续请求，否则不为其分配数据区。由此可以对攻击进行防御和清洗。

上述防御操作不限于SYN cookie机制，而是可以为本领域已知的或未来开发的用于防御同步泛洪攻击的任意合适防御操作。这里切换成双向转发方式也是用于配合诸如SYN cookie机制的防御操作进行的，因为如前面所提到的，这样的防御机制导致数据包的序列号改变，因而在所有数据包转发给后端服务器之前都需要对它们进行序列号的映射，这就要求不管是入流量还是出流量的数据包都要经过诸如LVS的虚拟服务器以便进行序列号的映射。也就是，当监测到同步泛洪攻击时，可以执行任意同步泛洪攻击防御操作并配合切换到任意适合的转发方式。

如上在监测到同步泛洪攻击时，虚拟服务器执行防御操作并配合切换数据包转发方式之后，就一直处于防御状态。此时由于采用经由虚拟服务器的双向转发方式，所以与单向转发方式相比，导致虚拟服务器的带宽和CPU被两个方向的流量瓜分，因而吞吐量和性能受到影响，在硬件成本上也有所增加。从而期望能够在防御状态下继续监测同步泛洪攻击，并且当同步泛洪攻击停止时可以停止防御操作并切换到单向转发方式。

再次参照图1，在步骤S140处，判断同步泛洪攻击是否停止。

具体而言，在防御状态下，虚拟服务器可以通过本领域已知的或者未来开发的任意合适方式来判断同步泛洪攻击是否停止。

图4示出了根据本申请一个实施例的判断同步泛洪攻击是否停止的步骤的流程图。

本发明人注意到，在防御状态的攻击流量下，某个虚拟服务在预定时间内接收到的数据包中的同步数据包的数目N_syn_rate很高，而由于很少能够完成TCP三次握手过程，该虚拟服务在预定时间内的新建连接数目N_cps相对较低。而在防御状态的正常流量下，N_syn_rate与N_cps大致相同。因此，在防御状态下，可以根据预定时间内接收到的数据包中的同步数据包的数目和在预定时间内的新建连接数目的变化来判断同步泛洪攻击是否停止。下面结合图4具体说明这个过程。

如图4所示，在步骤S410处，获取在预定时间内接收到的针对虚拟服务的地址的数据包中的同步数据包的数目N_syn_rate。

这里，预定时间可以为任意合适的时间段，优选地可以为1秒钟。

具体而言，在防御状态下，可以通过任意合适装置例如定时器和计数器来获取在预定时间内（例如每秒钟）接收到的针对某个虚拟服务地址的同步数据包的数目N_syn_rate。

在步骤S420处，获取针对所述虚拟服务的地址在预定时间内的新建连接数目N_cps。

这里的预定时间与步骤S410中的预定时间相同，并且可以为任意合适的时间段，优选地可以为1秒钟。

具体而言，在防御状态下，可以通过任意合适装置例如定时器和计数器来获取针对某个虚拟服务的地址在预定时间内（例如每秒钟）的新建连接数目N_cps。

接下来，在步骤S430处，根据在预定时间内接收到的数据包中的同步数据包的数目N_syn_rate和在预定时间内的新建连接数目N_cps来判断所述同步泛洪攻击是否停止。

正如前面提到的，在防御状态的攻击流量下，N_syn_rate很高，而N_cps相对较低。而在防御状态的正常流量下，N_syn_rate与N_cps大致相同。因此，在防御状态下，可以根据N_syn_rate和N_cps的变化来判断同步泛洪攻击是否停止。

在一个具体实施例中，在防御状态下，可以通过判断N_syn_rate与N_cps的比值N_syn_rate/N_cps是否小于阈值T2（第二阈值），来判断同步泛洪攻击是否停止。

在防御状态下攻击停止时，在预定时间内接收到的同步数据包的数目N_syn_rate会减少，而在预定时间内的新建连接数目N_cps会迅速增加。例如，N_syn_rate/N_cps可能在10³-10⁴量级。上述阈值T2可以是根据经验预先设定的任意合适值，并且例如可以在10³-10⁴量级。

例如，当N_syn_rate/N_cps变得小于该预设阈值T2时，可以判定同步泛洪攻击停止。当N_rate_rate/N_cps仍然大于或等于该预设阈值T2时，可以判定同步泛洪攻击没有停止。

这里需要指出的是，本申请并不限于N_syn_rate/N_cps的判断方式。例如，还可以通过N_cps/N_syn_rate来判断，当N_cps/N_syn_rate变得大于某一阈值时，判定同步泛洪攻击停止。另外，也可以通过其它本领域已知的或未来开发的任意合适方式进行上述判断。

同样，由于同步泛洪攻击的攻击频率很难预测，如果对于攻击消失的监测过于灵敏，可能导致由于攻击频率的瞬间变换而引起转发方式的频繁切换，比如攻击的短暂停止可能引起不必要的转发方式切换。

例如，在另一具体实施例中，在防御状态下，可以通过判断N_syn_rate/N_cps连续小于阈值T2（第二阈值）的次数m2是否超过预定数目M2（第二预定数目），来判定同步泛洪攻击是否停止。其中M2可以是根据经验预先设定的值。

当m2高于M2时，判定同步泛洪攻击停止。当m2低于或等于M2时，判定同步泛洪攻击没有停止。

根据这个实施例，可以在防御状态下更准确地判断同步泛洪攻击是否停止，从而减少转发方式的抖动。

相应地，在这样的实施例中，例如也可以通过N_cps/N_syn_rate连续大于某一阈值的次数是否超过某一预定数目来判断同步泛洪攻击是否停止。另外，也可以通过其它本领域已知的或未来开发的任意合适方式进行上述判断。

至此，通过上述步骤虚拟服务器判定出在防御状态下同步泛洪攻击是否停止。当判定同步泛洪攻击没有停止时，虚拟服务器仍然按照上述步骤S130中的防御操作模式工作。当判定同步泛洪攻击停止时，虚拟服务器可以切换到步骤S110中的正常操作模式工作。

具体而言，再次回到图1，在步骤S150处，当判定同步泛洪攻击停止时，在虚拟服务器上停止执行防御操作并且恢复成按照单向转发方式转发接收到的针对该虚拟服务的地址的数据包。

具体而言，在防御状态下，虚拟服务器判定针对某虚拟服务的地址的同步泛洪攻击停止后，停止防御操作并且恢复成按照单向转发方式来将针对该虚拟服务的地址的数据包转发到后端服务器。

如上所述，通过在非防御状态下监测攻击的出现以及在防御状态下监测攻击的消失，动态地切换数据包的转发方式，从而实现了在保证防御攻击的前提下最大限度地利用虚拟服务器（诸如LVS）的资源。另外，这种监测和防御的粒度可以精确到某个虚拟服务，即只对受到攻击的虚拟服务启动防御操作模式，而对没有受到攻击的虚拟服务仍然维持正常操作模式，从而能够达到智能监测和防御攻击。

与上述动态切换数据包的转发方式的方法类似，本申请实施例还提供了相应的设备。

图5示出了根据本申请另一方面的动态切换数据包的转发方式的设备500的示意框图。

如图5所述，根据本申请一个实施例的动态切换数据包的转发方式的设备500可以包括：单向转发装置510、攻击判断装置520、防御和双向转发装置530、攻击停止判断装置540以及停止防御和恢复装置550。

具体来说，单向转发装置510可以用于在虚拟服务器上按照单向转发方式转发接收到的针对虚拟服务的地址的数据包，该单向转发方式用于只将来自客户端的数据包转发给后端服务器。攻击判断装置520可以用于判断该虚拟服务的地址是否受到同步泛洪攻击。防御和双向转发装置530可以用于当判定该虚拟服务的地址受到同步泛洪攻击时，在虚拟服务器上执行用于防御同步泛洪攻击的防御操作，并按照双向转发方式转发接收到的针对该虚拟服务的地址的数据包，该双向转发方式用于将来自客户端的数据包转发给后端服务器并将来自后端服务器的数据包转发给客户端。攻击停止判断装置540可以用于判断同步泛洪攻击是否停止。停止防御和恢复装置550可以用于当判定同步泛洪攻击停止时，在虚拟服务器上停止执行防御操作并且恢复成按照单向转发方式转发接收到的针对该虚拟服务的地址的数据包。

图6示出了根据本申请一个实施例的攻击判断装置600的具体示意框图。如图6所示，攻击判断装置600可以包括：第一数目获取单元610、第二数目获取单元620和攻击判断单元630。

更具体而言，第一数目获取单元610可以用于获取与该虚拟服务的地址处于半连接状态的半连接数目。第二数目获取单元620可以用于获取与该虚拟服务的地址已建立连接的连接数目。攻击判断单元630可以用于根据半连接数目和连接数目来判断虚拟服务的地址是否受到同步泛洪攻击。

图7示出了根据本申请一个实施例的攻击停止判断装置700的具体示意框图。如图7所示，攻击停止判断装置700可以包括：第三数目获取单元710、第四数目获取单元720和攻击停止判断单元730。

更具体而言，第三数目获取单元710可以用于获取在预定时间内接收到的针对某虚拟服务的地址的数据包中的同步数据包的数目。第四数目获取单元720可以用于获取针对该虚拟服务的地址在预定时间内的新建连接数目。攻击停止判断单元730可以用于根据在预定时间内接收到的数据包中的同步数据包的数目和在预定时间内的新建连接数目来判断同步泛洪攻击是否停止。

同样，通过上述的动态切换数据包的转发方式的设备，可以实现在智能监测和防御同步泛洪攻击的前提下最大限度地利用虚拟服务器（诸如LVS）的资源。

以上描述的动态切换数据包的转发方式的设备与之前描述的动态切换数据包的转发方式的方法的处理是对应的，因此，关于更详细的技术细节，可以参见之前描述的动态切换数据包的转发方式的方法，这里不再赘述。

本领域技术人员应明白，本申请的实施例可提供为方法、系统或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质（包括但不限于磁盘存储器、CD-ROM、光学存储器等）上实施的计算机程序产品的形式。

以上所述仅为本申请的实施例而已，并不用于限制本申请。对于本领域技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本申请的权利要求范围之内。

Claims (16)

1.一种动态切换数据包的转发方式的方法，其特征在于，包括：

在虚拟服务器上按照单向转发方式转发接收到的针对虚拟服务的地址的数据包，所述单向转发方式用于只将来自客户端的数据包转发给后端服务器；

判断所述虚拟服务的地址是否受到同步泛洪攻击；

当判定所述虚拟服务的地址受到同步泛洪攻击时，在虚拟服务器上执行用于防御同步泛洪攻击的防御操作，并按照双向转发方式转发接收到的针对所述虚拟服务的地址的数据包，所述双向转发方式用于将来自客户端的数据包转发给后端服务器并将来自后端服务器的数据包转发给客户端；

判断同步泛洪攻击是否停止；以及

当判定同步泛洪攻击停止时，在虚拟服务器上停止执行防御操作并且恢复成按照所述单向转发方式转发接收到的针对所述虚拟服务的地址的数据包。

2.根据权利要求1所述的方法，其特征在于，所述判断虚拟服务的地址是否受到同步泛洪攻击的步骤包括：

获取与所述虚拟服务的地址处于半连接状态的半连接数目；

获取与所述虚拟服务的地址已建立连接的连接数目；以及

根据所述半连接数目和所述连接数目来判断所述虚拟服务的地址是否受到同步泛洪攻击。

3.根据权利要求2所述的方法，其特征在于，所述根据所述半连接数目和所述连接数目来判断所述虚拟服务的地址是否受到同步泛洪攻击的步骤包括：

当所述半连接数目与所述连接数目的比值大于第一阈值时，判定所述虚拟服务的地址受到同步泛洪攻击。

4.根据权利要求2所述的方法，其特征在于，当所述半连接数目与连接数目的比值连续大于第一阈值的次数超过第一预定数目时，判定所述虚拟服务的地址受到同步泛洪攻击。

5.根据权利要求1所述的方法，其特征在于，所述判断同步泛洪攻击是否停止的步骤包括：

获取在预定时间内接收到的针对所述虚拟服务的地址的数据包中的同步数据包的数目；

获取针对所述虚拟服务的地址在预定时间内的新建连接数目；以及

根据在预定时间内接收到的数据包中的同步数据包的数目和在预定时间内的新建连接数目来判断所述同步泛洪攻击是否停止。

6.根据权利要求5所述的方法，其特征在于，所述根据在预定时间内接收到的数据包中的同步数据包的数目和在预定时间内的新建连接数目来判断所述同步泛洪攻击是否停止的步骤包括：

当在预定时间内接收到的数据包中的同步数据包的数目与在预定时间内的新建连接数目的比值小于第二阈值时，判定所述同步泛洪攻击停止。

7.根据权利要求5所述的方法，其特征在于，当在预定时间内接收到的数据包中的同步数据包的数目与在预定时间内的新建连接数目的比值连续小于第二阈值的次数超过第二预定数目时，判定所述同步泛洪攻击停止。

8.根据权利要求1所述的方法，其特征在于，所述防御操作包括：

当从客户端接收到同步数据包时，虚拟服务器根据所述同步数据包的参数计算验证码，并向客户端返回包含所述验证码作为序列号的同步/确认数据包；以及

当从客户端接收到确认数据包时，根据所述确认数据包的序列号，确定是否针对所述同步数据包建立客户端与虚拟服务之间的连接。

9.一种动态切换数据包的转发方式的设备，其特征在于，包括：

单向转发装置，用于在虚拟服务器上按照单向转发方式转发接收到的针对虚拟服务的地址的数据包，所述单向转发方式用于只将来自客户端的数据包转发给后端服务器；

攻击判断装置，用于判断所述虚拟服务的地址是否受到同步泛洪攻击；

防御和双向转发装置，用于当判定所述虚拟服务的地址受到同步泛洪攻击时，在虚拟服务器上执行用于防御同步泛洪攻击的防御操作，并按照双向转发方式转发接收到的针对所述虚拟服务的地址的数据包，所述双向转发方式用于将来自客户端的数据包转发给后端服务器并将来自后端服务器的数据包转发给客户端；

攻击停止判断装置，用于判断所述同步泛洪攻击是否停止；以及

停止防御和恢复装置，用于当判定所述同步泛洪攻击停止时，在虚拟服务器上停止执行防御操作并且恢复成按照所述单向转发方式转发接收到的针对所述虚拟服务的地址的数据包。

10.根据权利要求9所述的设备，其特征在于，所述攻击判断装置包括：

第一数目获取单元，用于获取与所述虚拟服务的地址处于半连接状态的半连接数目；

第二数目获取单元，用于获取与所述虚拟服务的地址已建立连接的连接数目；以及

攻击判断单元，用于根据所述半连接数目和所述连接数目来判断虚拟服务的地址是否受到同步泛洪攻击。

11.根据权利要求10所述的设备，其特征在于，当所述半连接数目与所述连接数目的比值大于第一阈值时，所述攻击判断单元判定所述虚拟服务的地址受到同步泛洪攻击。

12.根据权利要求10所述的设备，其特征在于，当所述半连接数目与连接数目的比值连续大于第一阈值的次数超过第一预定数目时，所述攻击判断单元判定所述虚拟服务的地址受到同步泛洪攻击。

13.根据权利要求9所述的设备，其特征在于，所述攻击停止判断装置包括：

第三数目获取单元，用于获取在预定时间内接收到的针对所述虚拟服务的地址的数据包中的同步数据包的数目；

第四数目获取单元，用于获取针对所述虚拟服务的地址在预定时间内的新建连接数目；以及

攻击停止判断单元，用于根据在预定时间内接收到的数据包中的同步数据包的数目和在预定时间内的新建连接数目来判断所述同步泛洪攻击是否停止。

14.根据权利要求13所述的设备，其特征在于，当在预定时间内接收到的数据包中的同步数据包的数目与在预定时间内的新建连接数目的比值小于第二阈值时，所述攻击停止判断单元判定所述同步泛洪攻击停止。

15.根据权利要求13所述的设备，其特征在于，当在预定时间内接收到的数据包中的同步数据包的数目与在预定时间内的新建连接数目的比值连续小于第二阈值的次数超过第二预定数目时，所述攻击停止判断单元判定所述同步泛洪攻击停止。

16.根据权利要求9所述的设备，其特征在于，所述防御操作包括：

当从客户端接收到同步数据包时，虚拟服务器根据所述同步数据包的参数计算验证码，并向客户端返回包含所述验证码作为序列号的同步/确认数据包；以及

当从客户端接收到确认数据包时，根据所述确认数据包的序列号，确定是否针对所述同步数据包建立客户端与虚拟服务之间的连接。