SYN洪泛攻击的处理方法及装置与流程

文档序号:11878818阅读:1053来源:国知局
SYN洪泛攻击的处理方法及装置与流程

本申请涉及网络通信技术领域,尤其涉及SYN洪泛攻击的处理方法及装置。



背景技术:

通常,一台客户端与服务器在进行网络通讯时,需要基于传输控制协议(TCP,Transmission Control Protocol)建立连接。TCP协议提供可靠的连接服务,该协议采用三次握手建立一个连接:

第一次握手:建立连接时,客户端发送连接请求数据包SYN给服务器,等待服务器确认。

第二次握手:服务器收到连接请求数据包SYN后,必须确认客户的SYN,因此回复一请求响应数据包SYN/ACK。

第三次握手:客户端收到服务器的SYN/ACK包,向服务器发送确认数据包ACK(Acknowledgment field significant)。该数据包发送至服务器完毕,客户端和服务器,完成三次握手。之后,客户端与服务器才真正建立起连接,并开始传送数据。

SYN洪泛攻击(SYN Flood,Synchronize sequence numbers Flood)是目前常见针对服务器的攻击手段,其原理是:攻击者发送大量伪造源IP地址和源端口的SYN包给服务器,而当服务器返回SYN/ACK后,该攻击者就不对其进行再确认,则该TCP连接在服务器侧处于挂起状态,以等待攻击者的ACK。另一方面,服务器通常收不到ACK后,还会重复发送SYN/ACK给攻击者。这样更加会浪费服务器的资源。SYN洪泛攻击出现时,攻击者通常会发送非常大量的TCP连接,由于每一个TCP连接都没法完成三次握手,因此大量挂起状态的TCP连接会严重消耗服务器的CPU和内存,导致服务器无法及时响应其他正常客户端的连接请求,还有可能造成服务器死机等严重后果。

相关技术中的SYN洪泛攻击的防御方式有首包丢弃或TCP代理等。首包丢弃方式会造成业务卡顿,而TCP代理方式需要清洗设备一直保持在线,在没有发生攻击的时候会导致业务卡顿,并且防御效果较差,有可能造成过滤错误。



技术实现要素:

为克服相关技术中存在的问题,本申请提供了SYN洪泛攻击的处理方法及装置。

根据本申请实施例的第一方面,提供一种SYN洪泛攻击的处理方法,所述方法包括:

接收第一连接请求,所述第一连接请求携带有客户端的源地址信息;

根据所述源地址信息向所述客户端发起第二连接请求;

根据所述客户端对所述第二连接请求的响应结果,确定对所述第一连接请求的处理操作。

根据本申请实施例的第二方面,提供一种SYN洪泛攻击的处理装置,包括:

请求接收模块,用于接收第一连接请求,所述第一连接请求携带有客户端的源地址信息;

连接发起模块,用于根据所述源地址信息向所述客户端发起第二连接请求;

处理模块,用于根据所述客户端对所述第二连接请求的响应结果,确定对所述第一连接请求的处理操作。

本申请的实施例提供的技术方案可以包括以下有益效果:

本申请在接收到第一连接请求时,清洗设备根据连接请求中携带的源地址信息,向该源地址信息对应的客户端发起第二连接请求,若是攻击端发起的连接请求,则源地址可能为虚假IP地址,或者是非真实发起连接请求的地址,因此对于清洗设备发起的连接请求,则无法进行真实的响应;若是真实发起连接的客户端,对于清洗设备的连接请求,则可以进行相应的响应。清洗设备可以根据客户端对所述第二连接请求的响应结果,确定客户端是否为攻击端,从而确定对所述第一连接请求的处理操作。本申请能保持TCP连接的首包不丢弃,并且能同时完成回源操作,不需要进行TCP代理,还可以有效地穿透NAT,对于SYN Flood的防御效果较好。

应当理解的是,以上的一般描述和后文的细节描述仅是示例性和解释性的,并不能限制本申请。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分,示出了符合本申请的实施例,并与说明书一起用于解释本申请的原理。

图1是相关技术中TCP协议中采用三次握手建立连接的示意图。

图2A是本申请根据一示例性实施例示出的一种SYN洪泛攻击的处理方法的应用场景示意图。

图2B是本申请根据一示例性实施例示出的一种SYN洪泛攻击的处理方法的流程示意图。

图3是本申请根据一示例性实施例示出的另一种SYN洪泛攻击的处理方法的流程示意图。

图4是本申请SYN洪泛攻击的处理装置所在设备的一种硬件结构图。

图5是本申请根据一示例性实施例示出的一种SYN洪泛攻击的处理装置的框图。

具体实施方式

这里将详细地对示例性实施例进行说明,其示例表示在附图中。下面的描述涉及附图时,除非另有表示,不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本申请相一致的所有实施方式。相反,它们仅是与如所附权利要求书中所详述的、本申请的一些方面相一致的装置和方法的例子。

在本申请使用的术语是仅仅出于描述特定实施例的目的,而非旨在限制本申请。在本申请和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式,除非上下文清楚地表示其他含义。还应当理解,本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。

应当理解,尽管在本申请可能采用术语第一、第二、第三等来描述各种信息,但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如,在不脱离本申请范围的情况下,第一信息也可以被称为第二信息,类似地,第二信息也可以被称为第一信息。取决于语境,如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。

参考图1,图1是相关技术中TCP协议中采用三次握手建立连接的示意图,其建立连接的过程包括:

第一次握手:建立连接时,客户端发送SYN包(SYN=j)到服务器,并进入SYN-SEND状态,等待服务器确认。

第二次握手:服务器收到SYN包,必须确认客户的SYN(ACK=j+1),同时自己也发送一个SYN包(SYN=k),即SYN/ACK包,此时服务器进入SYN-RECV状态。

第三次握手:客户端收到服务器的SYN/ACK包,向服务器发送确认包ACK(ACK=k+1),此包发送完毕,客户端和服务器进入ESTABLISHED(连接成功)状态,完成三次握手。

经过这三步,TCP连接就建立完成。TCP协议为了实现可靠传输,在三次握手的过程中设置了一些异常处理机制。第三次握手中,如果服务器没有收到客户端的最终确认数据包ACK,会一直处于SYN_RECV状态,也即是将客户端的IP地址加入等待列表,并重发第二步的SYN/ACK。重发一般进行3-5次,大约间隔30秒左右轮询一次等待列表重试所有客户端。另一方面,服务器在发出了SYN/ACK报文后,会预分配资源为即将建立的TCP连接储存信息做准备,这个资源在等待重试期间一直保留。更为重要的是,服务器资源有限,可以维护的SYN_RECV状态超过极限后就不再接受新的SYN报文,也就是拒绝新的TCP连接请求。

SYN Flood正是利用了TCP协议的设定,达到攻击的目的。攻击者伪装大量的IP地址给服务器发送SYN,由于伪造的IP地址通常为不真实的IP地址或者其他没有发起连接请求的设备,因此服务器无法接收到响应数据包。并且,服务器会维持一个庞大的等待列表,不停的重试发送SYN/ACK报文,同时占用着大量的资源无法释放。更关键的是,被攻击服务器的SYN_RECV队列被恶意的数据包占满,不再接受新的SYN请求,合法用户无法完成三次握手建立起TCP连接,因此造成服务器发生拒绝服务的严重后果。

相关技术中防御SYN Flood的方式包括有首包丢弃,其处理方式是将任一设备发送第一个连接请求数据包进行丢弃。该方式虽然可以达到较好的防御效果,但由于需要客户端重新发起连接请求,因此会造成业务延迟和卡顿,牺牲了业务体验。

相关技术中防御SYN Flood的方式还包括有TCP代理,该方式通过设置于客户端与服务器之间的清洗设备,对来自客户端的连接请求通过预先设定的清洗策略判断发起请求客户端是否为真实客户端,若为真实客户端再将连接交互给服务器。该方式需要清洗设备一直在线,由于连接请求都需经过清洗设备,因此在没有发生攻击的情况下,该方式会导致连接请求没有及时到达服务器,增加请求处理时间。并且,相关技术中的清洗策略通常是根据预设的攻击特征,通过判断连接请求是否符合特征而确定连接请求是否为攻击端所发起,因此很容易造成误判,导致真实的连接请求被过滤。

而本申请实施例中所提供的方案,能保持TCP连接的首包不丢弃,并且能同时完成回源操作,不需要进行TCP代理,还可以有效地穿透NAT,对于SYN Flood的防御效果较好。接下来对本申请实施例进行详细说明。

如图2A所示,是根据一示例性实施例示出的一种SYN洪泛攻击的处理方法的应用场景图,图2A中包括客户端220、装设有客户端220的终端、服务器240以及在终端和服务器240之间进行信号转发的交换机260,所述终端与服务器240通过无线网络或有线网络连接,并基于网络连接在两者之间进行信息传输和交互。所述终端可以包括智能手机、个人计算机、笔记本电脑、个人数字助理、平板电脑等终端设备中的至少一种。可以理解的是,本实施例的服务器仅以一台服务器设备为例进行说明,在实际应用中,服务器还可以是服务器集群或云服务器等。

其中,服务器240,运行有向客户端220提供各种服务的服务端,该服务端可通过网络向客户端120提供各种服务,如FTP(File Transfer Protocol,文件传输协议)、游戏端口、聊天房间、网页论坛或购物平台等。服务端向客户端220提供服务前,需要客户端220通过其所在终端与服务器240建立连接,该连接通常是基于TCP协议建立的TCP连接。

本实施例中还包括有检测设备,检测设备为独立设备,其可以与交换机连接,并拷贝交换机的流量数据,以进行是否发生SYN Flood的判断,当检测设备判断发生SYN Flood时,检测设备可以通知交换机将流量(也即是客户端发起的连接请求)引入至清洗设备。具体的,检测设备如何判断是否发生SYN Flood的过程,可以参考相关技术中的描述,本实施例对此不进行赘述。

本实施例提供的是服务器处于被SYN Flood攻击状态时进行的处理方法,本实施例的处理方法可以应用于图2A所示的清洗设备中,如图2B所示,是本实施例中SYN洪泛攻击的处理方法的流程图,包括以下步骤201至203:

在步骤201中,接收第一连接请求,所述第一连接请求携带有客户端的源地址信息。

本实施例中,清洗设备无需实时在线,可以在确定服务器处于被SYN Flood攻击状态时上线,并接收交换机所引入的流量,也即接收多台客户端发起的连接请求。在实际应用中,连接请求可以具体是连接请求数据包SYN,该SYN中携带有源IP(Internet Protocol,网络之间互连的协议)地址、源端口地址等源地址信息。

在步骤202中,根据所述源地址信息向所述客户端发起第二连接请求。

有别于相关技术中复杂的处理方式,本申请实施例的方案,在接收到第一连接请求时,清洗设备根据连接请求中携带的源地址信息,向该源地址信息对应的客户端发起第二连接请求。该第二连接请求可以是清洗设备根据源地址信息和本设备的地址信息所生成的连接请求数据包SYN。

在步骤203中,根据所述客户端对所述第二连接请求的响应结果,确定对所述第一连接请求的处理操作。

根据TCP协议,设备在接收到连接请求数据包SYN,通常需反馈一响应连接数据包SYN/ACK。当SYN Flood发生时,若是攻击端发起的连接请求,则源地址可能为虚假IP地址,或者是非真实发起连接请求的地址,因此对于清洗设备发起的连接请求,则无法进行真实的响应;若是真实的客户端,对于清洗设备的连接请求,则可以进行相应的响应。清洗设备可以根据客户端对所述第二连接请求的响应结果,确定客户端是否为攻击端,从而确定对所述第一连接请求的处理操作。

本申请实施例的方案能实现相关技术中无法实现的回源处理:

当SYN Flood攻击的时候,清洗设备根据第一连接请求中的源地址信息,向该源地址信息对应的设备发起第二连接请求。清洗设备通过发起第二SYN,可以对发来的第一SYN进行回源,并通过观察客户端是否能够正确响应这个回源来判断发起连接的客户端是否是真实的。上述整个过程由清洗设备自动完成,不需要人工介入,其处理效率高,对虚假SYN的过滤处理效果好。

本申请实施例的方案能有效的穿透NAT(Network Address Translation,网络地址转换):

NAT穿透(NAT Traversal)是回源中首先要解决的问题,以证明客户端是否真实存在,如果不能穿透客户端的NAT,则无法实现回源。常见的客户端的NAT都是普通的家用路由器,以家用路由器为例,家用路由器的NAT策略是Port Restricted Cone NAT,也即路由器打开的端口只接受两边(客户端和服务器)IP地址和端口地址都吻合的数据包穿透。常见的NAT穿透方式都需要两端的配合,是一个性能耗损非常高的过程,并且一次穿透需要多次数据包往来,由于需要双端配合,相关技术中的效率和功能都无法满足。

本申请中,由于第一SYN携带有源地址信息,而清洗设备基于第一SYN向客户端发送了第二SYN。若发起第一SYN的设备为真实的客户端,则清洗设备发送的第二SYN可以简单便捷地实现NAT穿透,从而根据客户端的响应结果精准地判断出客户端是否为真实客户端,因此本申请实施例对客户端的误判率基本为零,准确率非常高。

由前述分析可知,若是攻击端发起的连接请求,对于清洗设备发起的连接请求,则无法进行真实的响应;若是真实的客户端,则对于清洗设备的连接请求,则可以进行相应的响应。清洗设备则可以根据客户端对所述第二连接请求的响应结果,确定客户端是否为攻击端,从而确定对所述第一连接请求的处理操作,对于具体的处理操作,可以根据实际需求而灵活配置,接下来阐述几种可选的实施方式。

第一种方式:

所述根据所述客户端对所述第二连接请求的响应结果,确定对所述第一连接请求的处理操作,可以包括:

若没有接收到所述客户端针对所述第二连接请求所反馈的连接响应,则过滤所述第一连接请求。

其中,所述过滤可以是丢弃第一连接请求数据包SYN。若是攻击端发起的连接请求,则源地址可能为虚假IP地址,或者是非真实发起连接请求的地址,因此对于清洗设备发起的第二连接请求SYN,源地址信息对应的客户端则无法进行真实的响应,因此,当没有接收到第二SYN对应的SYN/ACK,清洗设备可以确定第一SYN为攻击端所发起,因此可直接丢弃第一SYN,达到防御SYN Flood的目的。

第二种方式:

所述根据所述客户端对所述第二连接请求的响应结果,确定对所述第一连接请求的处理操作,可以包括:

若接收到所述客户端针对所述第二连接请求所反馈的连接响应,则基于所述第一连接请求和第二连接请求与所述客户端建立同步打开连接,并将所建立的连接交付给服务器。

相关技术中的TCP协议定义了同步打开(simultaneous open)策略。同时打开是指:TCP双端中,一端打开端口向另一端发送SYN之后,另一端也同时发送SYN至同样的端口。因此,连接可以由任一方或双方发起,一旦连接建立,数据就可以双向对等地流动,而没有所谓的主从关系。这种情况在现实中几乎不可能发生,因为连接双方必须需要知道对方的端口值。

本实施例利用TCP协议支持同时打开的机制,清洗设备模拟了一个对等的SYN连接,从而实现了回源目的,客户端与清洗设备可以认为双方是完全对称的。因为在回源的时候,清洗设备所回复的SYN/ACK与客户端发送的SYN/ACK报文属于同一个TCP连接,并且这个连接是客户端发起的,所以这种回源可以穿过任何一种严格的NAT。

本申请实施例中,对于真实发起第一SYN的客户端,若清洗设备向其发起第二SYN,则该客户端会反馈针对第二SYN的SYN/ACK。通过客户端的反馈,清洗设备可确定第一SYN为真实客户端所发起,因此清洗设备可以与客户端建立同步打开连接。

在一个可选的实现方式中,所述基于所述第一连接请求和第二连接请求与所述客户端建立同步打开连接,并将所建立的连接交付给服务器,包括:

接收客户端针对第二连接请求反馈的第二请求响应数据包,并向客户端反馈针对所述第一连接请求的第一请求响应数据包。

接收客户端针对所述第一请求响应数据包反馈的确认数据包。

将所建立的连接交互给服务器后,向客户端发送基于所述第一请求响应数据包的确认数据包。

具体的,上述过程可以参考图3,图3是本申请根据一示例性实施例示出的另一种SYN洪泛攻击的处理方法的示意图,图3中包括客户端、清洗设备和服务器,包括如下步骤301至307:

在步骤301中,客户端发送第一SYN。其中该第一SYN引入至清洗设备。

在步骤302中,清洗设备向客户端发送第二SYN。

在步骤303中,客户端向清洗设备反馈针对第二SYN的第二SYN/ACK。

在步骤304中,清洗设备向客户端反馈针对第一SYN的第一SYN/ACK。

在步骤305中,客户端向清洗设备反馈针对第一SYN/ACK的ACK。

在步骤306中,清洗设备将所建立的连接交付给服务器。

在步骤307中,清洗设备在连接交付完成后,向客户端反馈针对第二SYN/ACK的ACK。

本实施例还可以控制连接交付(即将所建立的TCP连接转移给服务器的过程)的时机。相关技术中的TCP代理和TCP缓存的方式,由于与客户端建立了连接,则客户端就会发来数据。此时,清洗设备可能正在进行连接交付,但由于数据已经发送过来,清洗设备还必须进行数据转换及缓存。或者,也有采用零窗口建立连接的方式,但使用零窗口可能导致客户端建立很长时间仍不能发送数据。

而本申请可以灵活地控制客户端发送数据的时机,清洗设备可以在连接交付完成后,再执行向客户端回复针对第二SYN/ACK的ACK的步骤,因此可以使客户端的数据直接发送给服务器,清洗设备并不需要进行数据处理。

第三种方式:

所述根据所述客户端对所述第二连接请求的响应结果,确定对所述第一连接请求的处理操作,可以包括:

若接收到所述客户端在针对第二连接请求所发送的第三连接请求,则将所述第一连接请求和/或第三连接请求转发给服务器。

对于部分不支持同步打开策略的设备,若是真实发起连接的客户端,由于清洗设备在接收到第一连接请求时,没有回复SYN/ACK,而是回复第二连接请求,客户端则会重新发起连接请求,因此清洗设备可以将连接请求转发给服务器,使服务器与客户端建立连接。若是真实的客户端,则客户端两次发起的第一连接请求和第三连接请求可以认为是相同的,因此,清洗设备所转发的连接请求可以是第一连接请求或第三连接请求,或者还可以是同时将上述两个连接请求同时转发。

与前述SYN洪泛攻击的处理方法的实施例相对应,本申请还提供了SYN洪泛攻击的处理装置及其所应用的设备的实施例。

本申请SYN洪泛攻击的处理装置的实施例可以应用在清洗设备上。装置实施例可以通过软件实现,也可以通过硬件或者软硬件结合的方式实现。以软件实现为例,作为一个逻辑意义上的装置,是通过其所在设备的处理器将非易失性存储器中对应的计算机程序指令读取到内存中运行形成的。从硬件层面而言,如图4所示,为本申请SYN洪泛攻击的处理装置所在设备的一种硬件结构图,除了图4所示的处理器410、内存430、网络接口420、以及非易失性存储器440之外,实施例中装置431所在的设备通常根据该设备的实际功能,还可以包括其他硬件,对此不再赘述。

如图5所示,图5是本申请根据一示例性实施例示出的一种SYN洪泛攻击的处理装置的框图,所述装置包括:

请求接收模块51,用于接收第一连接请求,所述第一连接请求携带有客户端的源地址信息。

连接发起模块52,用于根据所述源地址信息向所述客户端发起第二连接请求。

处理模块53,用于根据所述客户端对所述第二连接请求的响应结果,确定对所述第一连接请求的处理操作。

在一个可选的实现方式中,所述处理模块53,可以包括(图5未示出):

第一处理子模块,用于若接收到所述客户端针对所述第二连接请求所反馈的连接响应,则基于所述第一连接请求和第二连接请求与所述客户端建立同步打开连接,并将所建立的连接交付给服务器。

在一个可选的实现方式中,所述第一处理子模块,包括(图5未示出):

接收客户端针对第二连接请求反馈的第二请求响应数据包,并向客户端反馈针对所述第一连接请求的第一请求响应数据包;接收客户端针对所述第一请求响应数据包反馈的确认数据包;将所建立的连接交互给服务器,向客户端发送针对所述第一请求响应数据包的确认数据包。

在一个可选的实现方式中,所述处理模块53,包括(图5未示出):

第二处理子模块,用于若没有接收到所述客户端针对所述第二连接请求所反馈的连接响应,则过滤所述第一连接请求。

在一个可选的实现方式中,所述处理模块53,包括(图5未示出):

第三处理子模块,用于若接收到所述客户端在针对第二连接请求所发送的第三连接请求,则将所述第一连接请求转发给服务器。

上述装置中各个模块的功能和作用的实现过程具体详见上述SYN洪泛攻击的处理方法中对应步骤的实现过程,在此不再赘述。

对于装置实施例而言,由于其基本对应于方法实施例,所以相关之处参见方法实施例的部分说明即可。以上所描述的装置实施例仅仅是示意性的,其中所述作为分离部件说明的模块可以是或者也可以不是物理上分开的,作为模块显示的部件可以是或者也可以不是物理模块,即可以位于一个地方,或者也可以分布到多个网络模块上。可以根据实际的需要选择其中的部分或者全部模块来实现本申请方案的目的。本领域普通技术人员在不付出创造性劳动的情况下,即可以理解并实施。

本领域技术人员在考虑说明书及实践这里申请的发明后,将容易想到本申请的其它实施方案。本申请旨在涵盖本申请的任何变型、用途或者适应性变化,这些变型、用途或者适应性变化遵循本申请的一般性原理并包括本申请未申请的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的,本申请的真正范围和精神由下面的权利要求指出。

应当理解的是,本申请并不局限于上面已经描述并在附图中示出的精确结构,并且可以在不脱离其范围进行各种修改和改变。本申请的范围仅由所附的权利要求来限制。

以上所述仅为本申请的较佳实施例而已,并不用以限制本申请,凡在本申请的精神和原则之内,所做的任何修改、等同替换、改进等,均应包含在本申请保护的范围之内。

当前第1页1 2 3 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1