CN106131036B - Cc攻击的处理方法、装置及终端 - Google Patents

Abstract

本申请公开了一种CC攻击的处理方法、装置及终端，所述方法包括：接收到CC攻击端向目标主机发送的第一SYN数据包后，向所述CC攻击端发送第二SYN数据包；接收所述CC攻击端回应所述第二SYN数据包发送的SYN/ACK数据包；丢弃并终止响应所述CC攻击端发送的任何数据包，以使所述CC攻击端向所述目标主机发送的CC攻击反弹到所述CC攻击端。实施本申请，能在有效防御CC攻击端对目标主机的危害的同时，消耗CC攻击端的socket资源，进而能有效抑制CC攻击端发起的CC攻击。

Description

CC攻击的处理方法、装置及终端

技术领域

本申请涉及网络通信技术领域，尤其涉及CC攻击的处理方法、装置及终端。

背景技术

随着网络技术的不断发展，接入网络的用户端和各种应用服务器越来越多，同时随着网络攻击的扩散，越来越多的网络应用受到日益严重的安全威胁，而基于页面的DDoS攻击(CC攻击)逐渐成为网络攻击的主要手段，危害也逐渐加大。

CC攻击，一般通过攻击程序比如代理服务器或者其他控制***向目标主机发起大量HTTP连接。为了防御CC攻击，可对发送请求的客户端进行确认码验证，如果发送请求的客户端被自然人使用，则向所述客户端推送确认页面，自然人很显然可以正确识别确认页面中的确认码，也可以输入正确的确认码。如此，即可允许访问被保护的目标主机。而如果客户端为攻击程序，比如为代理或者木马，由于目前的技术无法使攻击程序快速正确识别确认码，因此，攻击程序难以实现对确认码的验证，进而也就无法真正访问目标主机。

上述CC攻击防御方法，虽然能在一定程度上防御CC攻击对目标主机的危害，但是不会对发起CC攻击的客户端造成任何影响，难以有效抑制客户端发起CC攻击。

发明内容

本申请提供CC攻击的处理方法、装置及终端，以解决现有CC攻击防御方法难以有效抑制客户端发起CC攻击的问题。

根据本申请实施例的第一方面，提供一种CC攻击的处理方法，包括以下步骤：

接收到CC攻击端向目标主机发送的第一SYN数据包后，向所述CC攻击端发送第二SYN数据包；

接收所述CC攻击端回应所述第二SYN数据包发送的SYN/ACK数据包；

丢弃并终止响应所述CC攻击端发送的任何数据包，以使所述CC攻击端向所述目标主机发送的CC攻击反弹到所述CC攻击端。

在一个实施例中，所述方法还包括：

在接收到所述第一SYN数据包时，启动预设定时器，所述预设定时器的定时时长小于或等于所述CC攻击端重发第一SYN数据包的超时时长；

将所述向所述CC攻击端发送第二SYN数据包的步骤在所述预设定时器超时后执行。

在一个实施例中，所述方法还包括：

接收到客户端向所述目标主机发送的第一SYN数据包后，请求CC攻击验证侧对所述客户端进行CC攻击验证；

接收所述CC攻击端返回的验证结果；

若所述验证结果表示所述客户端未通过所述CC攻击验证，则确定所述客户端为CC攻击端；

将所述向所述CC攻击端发送第二SYN数据包的步骤在确定所述客户端为CC攻击端后执行。

在一个实施例中，所述方法还包括：

请求钩子截获所述CC攻击端向所述目标主机发送的第一SYN数据包，所述钩子安装在所述目标主机的代理端；

接收所述钩子发送的所述第一SYN数据包；

所述向所述CC攻击端发送第二SYN数据包的步骤在接收所述钩子发送的所述第一SYN数据包后执行。

在一个实施例中，所述向所述CC攻击端发送第二SYN数据包后，所述方法还包括：

接收所述CC攻击端发送的回应数据包；

若所述回应数据包是SYN/ACK数据包，则终止响应所述CC攻击端发送的任何数据包，以使所述CC攻击端向所述目标主机发送的CC攻击反弹到所述CC攻击端；

若所述回应数据包是所述CC攻击端伪造的ACK数据包，则请求流量清洗侧对所述CC攻击端发送的数据包进行清洗处理。

在一个实施例中，若所述回应数据包是所述CC攻击端伪造的ACK数据包，所述方法还包括：

向所述CC攻击端发送用于回应所述第一SYN数据包的伪造数据包。

根据本申请实施例的第二方面，提供一种CC攻击的处理装置，包括：

数据包发送模块，用于在接收到CC攻击端向目标主机发送的第一SYN数据包后，向所述CC攻击端发送第二SYN数据包；

数据包接收模块，用于接收所述CC攻击端回应所述第二SYN数据包发送的SYN/ACK数据包；

攻击处理模块，用于丢弃并终止响应所述CC攻击端发送的任何数据包，以使所述CC攻击端向所述目标主机发送的CC攻击反弹到所述CC攻击端。

在一个实施例中，所述装置还包括：

定时模块，用于在接收到所述第一SYN数据包时，启动预设定时器，所述预设定时器的定时时长小于或等于所述CC攻击端重发第一SYN数据包的超时时长；

所述数据包发送模块还用于在所述定时模块的预设定时器超时后将所述向所述CC攻击端发送第二SYN数据包。

在一个实施例中，所述装置还包括：

攻击验证请求模块，用于在接收到客户端向所述目标主机发送的第一SYN数据包后，请求CC攻击验证侧对所述客户端进行CC攻击验证；

验证结果接收模块，用于接收所述CC攻击端返回的验证结果；

攻击侧确定模块，用于在所述验证结果表示所述客户端未通过所述CC攻击验证时，确定所述客户端为CC攻击端；

所述数据包发送模块还用于在所述攻击侧确定模块确定所述客户端为CC攻击端后将所述向所述CC攻击端发送第二SYN数据包。

在一个实施例中，所述装置还包括：

截获请求模块，用于请求钩子截获所述CC攻击端向所述目标主机发送的第一SYN数据包，所述钩子安装在所述目标主机的代理端；

截获结果接收模块，用于接收所述钩子发送的所述第一SYN数据包；

所述数据包发送模块还用于在所述截获结果接收模块接收所述钩子发送的所述第一SYN数据包后向所述CC攻击端发送第二SYN数据包。

在一个实施例中，所述装置还包括：

回应数据包接收模块，用于接收所述CC攻击端发送的回应数据包；

攻击处理子模块，用于在所述回应数据包是SYN/ACK数据包时，终止响应所述CC攻击端发送的任何数据包，以使所述CC攻击端向所述目标主机发送的CC攻击反弹到所述CC攻击端；

清洗处理请求模块，用于在所述回应数据包是所述CC攻击端伪造的ACK数据包时，请求流量清洗侧对所述CC攻击端发送的数据包进行清洗处理。

在一个实施例中，所述装置还包括：

伪造回应模块，用于在所述回应数据包是所述CC攻击端伪造的ACK数据包时，向所述CC攻击端发送用于回应所述第一SYN数据包的伪造数据包。

根据本申请实施例的第三方面，提供一种终端，其特征在于，包括：

处理器；

用于存储所述处理器可执行指令的存储器；

其中，所述处理器被配置为：

接收到CC攻击端向目标主机发送的第一SYN数据包后，向所述CC攻击端发送第二SYN数据包；

接收所述CC攻击端回应所述第二SYN数据包发送的SYN/ACK数据包；

丢弃并终止响应所述CC攻击端发送的任何数据包，以使所述CC攻击端向所述目标主机发送的CC攻击反弹到所述CC攻击端。

应用本申请实施例，接收到CC攻击端向目标主机发送的第一SYN数据包后，向所述CC攻击端发送第二SYN数据包；接收所述CC攻击端回应所述第二SYN数据包发送的SYN/ACK数据包后，丢弃并终止响应所述CC攻击端发送的任何数据包，可使CC攻击端响应所述第二SYN数据包发送SYN/ACK数据包括后进入SYN_RCVD状态，其关闭socket后，陆续进入FIN_WAIT_1状态、FIN_WAIT_2状态和TIME_WAIT状态，这些状态下CC攻击端的socket资源持续被占用，而且能将CC攻击端向目标主机发送的数据包都反弹到其自身，消耗CC攻击端自身的socket资源，最终使得CC攻击端没有足够资源发送CC攻击。因此，能在有效防御CC攻击端对目标主机的危害的同时，消耗CC攻击端的socket资源，进而能有效抑制CC攻击端发起的CC攻击。

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

附图说明

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

图1是本申请实施例实现CC攻击的处理的一个应用场景示意图；

图2是本申请CC攻击的处理方法的实施例中的TCP连接的状态转换图；

图3是本申请CC攻击的处理方法的一个实施例流程图；

图4是本申请CC攻击的处理方法的另一个实施例流程图；

图5是本申请CC攻击的处理装置所在终端的一种硬件结构图；

图6是本申请CC攻击的处理装置的一个实施例框图；

图7是本申请CC攻击的处理装置的另一个实施例框图。

具体实施方式

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

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

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

请参阅图1，图1是本申请实施例实现CC攻击的处理的一个应用场景示意图。

图1所示应用场景示意图，包括客户端120、装设有客户端120的终端以及作为目标主机的服务器140，所述终端与服务器140通过无线网络或有线网络连接，并基于网络连接在两者之间进行信息传输和交互。所述终端可以包括智能手机、台式机、笔记本、个人数字助理、平板电脑等终端设备中的至少一种。可以理解的是，本实施例的目标主机仅以服务器为例进行说明，还可以是PC(Personal Computer，个人计算机)或平板电脑等智能终端。

服务器140，运行有向客户端120提供各种服务的服务端，该服务端可通过网络向客户端120提供各种服务，如FTP(File Transfer Protocol，文件传输协议)、游戏端口、聊天房间、网页论坛等。服务端向客户端120提供服务前，需要客户端120通过其所在终端与服务器140建立一条链接，该条链接通常是基于TCP协议建立的TCP链接，而TCP链接的状态转换如图2所示，TCP链接的建立可以简单的称为三次握手，TCP链接的中止则可以叫做四次握手。

下面简要说明图2所示的TCP链接的状态转移过程：

首先说明下图2中的粗线，即客户端120的状态转移过程：在CLOSED状态下，客户端120向目的服务器140发起链接，即向服务器140发送SYN k数据包，也就是客户端120调用了connect函数，然后进入SYN_SENT状态，此时若等待服务器140返回对SYN k数据包的ACK数据包超时，则客户端120重新进入CLOSED状态，若客户端120准时收到了服务器140返回来的ACK数据包以及自己的SYN j数据包(即返回SYN/ACK数据包)，客户端120先向服务器140发送回应SYN j数据包的ACK数据包，然后进入ESTABLISHED状态，也就是说客户端120与服务器140连接成功。在此状态下，客户端120与服务器140进行正常的通信。

若通信结束，客户端120向服务器140发送FIN数据包，也就是客户端120调用了close函数，然后客户端120进入FIN_WAIT_1状态等待着服务器140返回来回应FIN数据包的ACK数据包，当接收到服务器140返回来的ACK数据包后，客户端120进入FIN_WAIT_2状态，因为通信是双端的，所以服务器140也会向客户端120发送FIN数据包(也就是服务器140也调用了close函数)，这时客户端120向服务器140发送回应FIN数据包的ACK数据包，同时进行入TIME_WAIT状态。TIME_WAIT状态持续2MSL(MSL最长分节生命期)后，进入CLOSED状态，也就socket(网络上的两个程序通过一个双向的通信连接实现数据的交换，这个连接的一端称为一个socket)正式关闭。之所以在WAIT_2和CLOSED之间加入一个TIME_WAIT状态且维持2MSL，是出于两个目的，1)确保TCP全双工的终止，例如：在FIN_WAIT_2状态时，客户端120发完ACK数据包的后就关闭了，而此时这个ACK数据包又发丢失了，这将导致服务器140收不到其回应FIN数据包的ACK数据包而无法关闭。2)确保上一次链接产生的数据包，在下一次再次链接之前就全部消失，不对下一次链接产生影响。

其次说明下图2中的虚线，即服务器140的状态转移过程：服务器140处在LISTEN状态时，也就是服务器140调用了listen和accept函数，此时服务器140收到了客户端120发送来的连接请求，也就是SYN k数据包，然后返回给客户端120自己的同步数据包SYN j数据包和对客户端120的SYN k数据包进行回应的ACK k+1数据包(即，回复SYN/ACK数据包)。此时服务器140进入SYS_RCVD状态，等待着客户端120返回对ACK j+1数据包进行回应确认的ACK数据包，若收到了此ACK数据包，服务器140进入ESTABLISHED状态，若没有收到还会重复发送(上图没有标出若服务器140发送完SYN J ACK k+1数据包后客户端120宕机了后的状态，一般会有一个重发机制)。服务器140的socket关闭过程与客户端120的关闭过程有些不一样，因为服务器140是被迫关闭，此时服务器140收到客户端120发来的FIN数据包，然后向客户端120返回对FIN数据包回应确认的ACK数据包，并进入CLOSE_WAIT状态，在此状态下，服务器140将自己socket内的数据处理完毕之后，同样向客户端120发送FIN数据包也就是调用close函数，此时服务器140进入LAST_ACK状态，在收到来自客户端120的ACK数据包后进入最终的CLOSED状态。

最后说明下图2中的细线，细线代表客户端120和服务器140同时打开和同时关闭时，TCP链接的状态转变，同时打开即客户端120发送了SYN数据包之后，服务器140也恰好发送了SYN数据包到客户端120的同样的端口；同时关闭即客户端120发送了FIN数据包之后，服务器140也恰好发送了FIN数据包到客户端120的同样的端口。这两种状态在现实中几乎不发生，即使发生也一般发生在两个服务器之间，因为他们必须需要知道对方的端口值。

图2中的RST是另一种关闭链接的方式，应用程序应该可以判断RST包的真实性，即是否为异常中止。

本申请实施例的CC攻击的处理方法，可在客户端120要对服务器140发起CC攻击时，基于以上所述的TCP链接的状态转移过程，利用客户端120与服务器140之间的同步打开状态，在接收到客户端120向服务器140发送第一SYN数据包后，向客户端120发送第二SYN数据包，接收到客户端120回复的SYN/ACK数据包后，不再回复客户端120的任何数据包，可使客户端120响应所述第二SYN数据包发送SYN/ACK数据包括后陆续进入SYN_RCVD状态，其关闭socket后，陆续进入FIN_WAIT_1状态、FIN_WAIT_2和TIME_WAIT状态。从而使客户端120的后续表现就好像自身是服务器140一样，所有针对服务器140的链接请求(SYN数据包)都被反弹给了自己，从而消耗其自身的socket资源。因此，能在有效防御客户端120对服务器140的CC攻击，同时消耗客户端120的socket资源，进而能有效抑制客户端120发起的CC攻击。

本申请实施例的CC攻击的处理方法可直接运行于服务器140，也可运行于服务器140前端的代理端，代理端如nginx(高性能的HTTP和反向代理服务器)等。下面将结合附图1和图2对本申请实施例进行详细描述。

参见图3，图3是本申请CC攻击的处理方法的一个实施例流程图，包括以下步骤301-303：

步骤301：接收到CC攻击端向目标主机发送的第一SYN数据包后，向所述CC攻击端发送第二SYN数据包。

参阅图2可知，SYN(synchronous)是TCP/IP建立连接时使用的握手信号，在客户端和服务器之间建立正常的TCP网络连接时，客户端首先发出一个SYN数据包，服务器使用SYN与ACK数据包(SYN/ACK数据包)应答，表示接收到了这个SYN数据包，最后客户端再以ACK数据包响应。这样在客户端和服务器之间才能建立起可靠的TCP连接，数据信息才可以在客户端和服务器之间传递。但是，在客户端作为CC攻击端，对服务器发起CC攻击时，SYN攻击是最常见又最容易被利用的一种攻击手法，利用TCP协议缺陷，客户端在短时间内伪造大量不存在的IP地址，向服务器不断地发送大量的第一SYN数据包，第一SYN数据包为伪造的数据包，若服务器回复确认数据包，并等待客户端的确认，由于源地址是不存在的，服务器需要不断的重发确认包直至超时，这些伪造的第一SYN数据包将长时间占用未连接队列，正常的SYN数据包被丢弃，服务器对应的目标***运行缓慢，严重者引起网络堵塞甚至***瘫痪。

为了避免服务器接收到发起CC攻击的客户端发送的第一SYN数据包后，回复确认数据包并等待发起CC攻击的客户端的确认，导致服务器对应的目标***运行缓慢，甚至引起网络堵塞甚至***瘫痪，可在接收到发起CC攻击的客户端发送的第一SYN数据包后，不回复确认数据包，而是向发起CC攻击的客户端(即CC攻击端)发送所述第二SYN数据包，等同于发起CC攻击的客户端与服务器处于同时打开状态，诱导发起CC攻击的客户端回复对第二SYN数据包的确认数据包，并等待确认。

本申请实施例的所述第二SYN数据包是向发起CC攻击的客户端发送，不影响发起正常链接请求的客户端，在接收到客户端向所述目标主机发送的第一SYN数据包后，可先验证发送第一SYN数据包的客户端是否对目标主机进行CC攻击，若是，再向客户端发送所述第一SYN数据包。

在某些应用场景中，本申请实施例的CC攻击的处理方法应用于目标主机的代理端，验证发送第一SYN数据包的客户端是否对目标主机进行CC攻击时，可请求CC攻击验证侧对所述客户端进行CC攻击验证，然后接收所述CC攻击端返回的验证结果，若所述验证结果表示所述客户端未通过所述CC攻击验证，则确定所述客户端为CC攻击端，将所述向所述CC攻击端发送第二SYN数据包的步骤在确定所述客户端为CC攻击端后执行。若所述验证结果表示所述客户端通过了所述CC攻击验证，则确定所述客户端不是CC攻击端，继续发送所述第一SYN数据包至所述目标主机。

实际应用时，上述攻击验证侧，可以是与目标主机关联的CC攻击验证设备、可以是目标主机内的CC攻击验证模块、还可以是流量清洗设备内的CC攻击验证模块，因此在本申请实施例需要对所述客户端进行CC攻击验证时，目标主机的代理端可直接调用目标主机内的CC攻击验证模块对所述客户端进行CC攻击验证，或者，请求所述CC攻击验证设备或所述流量清洗设备对所述客户端进行CC攻击验证。

针对上述应用于目标主机的代理端的CC攻击的处理方法，若CC攻击端向目标主机发送的第一SYN数据包，不需要代理端转发，那么本申请实施例可请求代理端安装的钩子截获所述CC攻击端向所述目标主机发送的第一SYN数据包，接收所述钩子发送的所述第一SYN数据包，然后向所述CC攻击端发送第二SYN数据包。

在某些例子中，CC攻击端向目标主机发送第一SYN数据包后，若预设时段内接收不到回应数据包，会延时重发所述第一SYN数据包，CC攻击端的操作***，重发时间和重发次数不同，例如，windows***会重发3次，第一次重发时间是3s，若在发送第一SYN数据包后3s内接收不到回应数据包，则第一次重发所述第一SYN数据包，第二次重发时间是6s，第三次重发时间是12s，三次重发之后超时返回，超时时间是21s；Linux***一般重发5次，第一次重发时间是2s，第二次重发时间是4s，第三次重发时间是8s，第四次重发时间是16s，第五次重发时间是32s，五次重发之后超时返回，超时时间是62s。

为了耗尽CC攻击端的socket资源，可使CC攻击端尽可能多的进行延时重发，因此，本申请实施例的CC攻击的处理方法，在接收到所述第一SYN数据包时，启动预设定时器，所述预设定时器的定时时长小于或等于所述CC攻击端重发第一SYN数据包的超时时长，将所述向所述CC攻击端发送第二SYN数据包的步骤在所述预设定时器超时后执行。所述CC攻击端重发第一SYN数据包的超时时长由CC攻击端的操作***决定，可以为上述的21s或62s。

通过上述定时器的启动，本申请实施例延迟第二SYN数据包的发送，使CC攻击端在SYN_SENT状态进行多次延时重发第一SYN数据包，消耗自身的sokcet资源。例如，对于多线程的CC攻击，本申请实施例通过定时器的启动延迟第二SYN数据包的发送，可最大化每个连接的延时，将所有的线程都堵住，就可以快速降低客户端发送cc攻击的频率；对于使用异步连接的CC攻击，本申请实施例通过定时器的启动延迟第二SYN数据包的发送，可以延缓每一个链接的建立数目，如此，客户端的TCP资源将大量的处于SYN_SENT、SYN_RCVD和FIN_WAIT_1状态，直至耗尽资源。

步骤302：接收所述CC攻击端回应所述第二SYN数据包发送的SYN/ACK数据包。

本申请实施例中，接收到CC攻击端发送SYN/ACK数据包后，即成功诱导CC攻击端进入SYN_RCVD状态，CC攻击端的socket关闭后，会依次进入FIN_WAIT_1状态、FIN_WAIT_2和TIME_WAIT状态。可使CC攻击端的后续表现就好像自身是目标主机一样，所有针对目标主机的链接请求(数据包)都被反弹给了自己，从而消耗其自身的socket资源。

步骤303：丢弃并终止响应所述CC攻击端发送的任何数据包，以使所述CC攻击端向所述目标主机发送的CC攻击反弹到所述CC攻击端。

本申请实施例，在首次接收到CC攻击端发送SYN/ACK数据包后，即成功诱导CC攻击端进入SYN_RCVD状态，为了尽可能延长CC攻击端处于各个TCP状态的时间，丢弃并不再响应所述CC攻击端发送的任何数据包，即不响应CC攻击端的任何请求，不回复任何数据。例如：重复接收到CC攻击端发送的第一SYN数据包，不回复SYN/ACK数据包；重复接收到CC攻击端发送的SYN/ACK数据包，也不回复ACK数据包。

诱导CC攻击端响应所述第二SYN数据包发送SYN/ACK数据包进入SYN_RCVD状态后，CC攻击端为了避免目标主机返回的数据将自身的带宽堵死会关闭socket，或者长期接收不到目标主机回复的数据包，会超时关闭socket,其关闭socket后，陆续进入FIN_WAIT_1状态、FIN_WAIT_2状态和TIME_WAIT状态，这些状态下CC攻击端的socket资源持续被占用，而且能将CC攻击端向目标主机发送的数据包都反弹到其自身，消耗CC攻击端自身的socket资源，最终使得CC攻击端没有足够资源发送CC攻击。因此，能在有效防御CC攻击端对目标主机的危害，同时消耗CC攻击端的socket资源，能有效抑制CC攻击端发起的CC攻击，避免CC攻击造成目标主机侧带宽的消耗，进而能降低目标主机侧的运营成本。

此外，本申请实施例对于发起恶意高频CC攻击的CC攻击端，无需消耗目标主机或目标主机的代理端的资源，即可更高效地将CC攻击端向目标主机发送数据包反弹到其自身，更快速地消耗CC攻击端自身的socket资源。

由上述实施例可知，本申请实施例能使所述CC攻击端向所述目标主机的发送的CC攻击反弹到所述CC攻击端，前提是能诱导CC攻击端响应所述第二SYN数据包发送SYN/ACK数据包进入SYN_RCVD状态。而某些应用场景中，CC攻击端(使用攻击软件dossim的客户端)会绕过协议栈，伪造数据包，自己完成建立TCP链接所需的三次握手，无法正确响应本申请上述实施例中的第二SYN数据包，进而CC攻击端不会被诱导进入SYN_RCVD状态。针对该类应用场景中的CC攻击端发起的CC攻击，可直接识别进行清洗，具体可参见图4，图4是本申请CC攻击的处理方法的另一个实施例流程图，包括以下步骤401-404：

步骤401：接收到CC攻击端向目标主机发送的第一SYN数据包后，向所述CC攻击端发送第二SYN数据包。

本步骤的实现方式可参见上述实施例中步骤301的实现方式。

步骤402：接收所述CC攻击端发送的回应数据包。

本申请实施例中，若CC攻击端发起的CC攻击未绕过协议栈，则回应数据包可以是SYN/ACK数据包，若CC攻击端发起的CC攻击绕过了协议栈，则回应数据包可以是伪造的ACK数据包。

步骤403：若所述回应数据包是SYN/ACK数据包，则终止响应所述CC攻击端发送的任何数据包，以使所述CC攻击端向所述目标主机发送的CC攻击反弹到所述CC攻击端。

步骤404：若所述回应数据包是所述CC攻击端伪造的ACK数据包，则请求流量清洗侧对所述CC攻击端发送的数据包进行清洗处理。

本申请实施例中，伪造的ACK数据包不满足协议栈的协议标准，用于实现CC攻击端完成建立TCP链接所需的三次握手。

上述流量清洗侧，可以是与目标主机关联的流量清洗设备、可以是目标主机内的流量清洗模块，因此在本申请实施例需要流量清洗侧对所述CC攻击端发送的数据包进行清洗处理时，目标主机的代理端可直接调用目标主机内的流量清洗模块对所述客户端发送的数据包进行清洗，或者，将CC攻击端发送的数据包发送到与目标主机关联的流量清洗设备进行清洗。

此外，为了防止CC攻击端觉察到其已被识别，本申请实施例可在所述回应数据包是所述CC攻击端伪造的ACK数据包时，向所述CC攻击端发送用于回应所述第一SYN数据包的伪造数据包，完成伪装响应。

由上述实施例可知：本申请既可以对使用协议栈发起CC攻击的CC攻击端向目标主机发送的数据包都反弹到其自身，消耗CC攻击端自身的socket资源，最终使得CC攻击端没有足够资源发送CC攻击。因此能在有效防御CC攻击端对目标主机的危害的同时，消耗CC攻击端的socket资源，进而能有效抑制CC攻击端发起的CC攻击。本申请还可以直接清洗绕过协议栈发起的CC攻击，无需应用层判断CC攻击端发起的请求的有效性，能显著节省目标主机的CPU资源。

与前述CC攻击的处理方法的实施例相对应，本申请还提供了CC攻击的处理装置的实施例。

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

参见图6，图6是本申请CC攻击的处理装置的一个实施例框图，该装置可包括：数据包发送模块610、数据包接收模块620和攻击处理模块630。

其中，数据包发送模块610，用于在接收到CC攻击端向目标主机发送的第一SYN数据包后，向所述CC攻击端发送第二SYN数据包。

数据包接收模块620，用于接收所述CC攻击端回应所述第二SYN数据包发送的SYN/ACK数据包。

攻击处理模块630，用于丢弃并终止响应所述CC攻击端发送的任何数据包，以使所述CC攻击端向所述目标主机发送的CC攻击反弹到所述CC攻击端。

在一个可选的实现方式中，所述装置还包括(图6中未示出)：

定时模块，用于在接收到所述第一SYN数据包时，启动预设定时器，所述预设定时器的定时时长小于或等于所述CC攻击端重发第一SYN数据包的超时时长。

数据包发送模块610还用于在所述定时模块的预设定时器超时后将所述向所述CC攻击端发送第二SYN数据包。

在另一个可选的实现方式中，所述装置还包括(图6中未示出)：

攻击验证请求模块，用于在接收到客户端向所述目标主机发送的第一SYN数据包后，请求CC攻击验证侧对所述客户端进行CC攻击验证。

验证结果接收模块，用于接收所述CC攻击端返回的验证结果。

攻击侧确定模块，用于在所述验证结果表示所述客户端未通过所述CC攻击验证时，确定所述客户端为CC攻击端。

数据包发送模块610还用于在所述攻击侧确定模块确定所述客户端为CC攻击端后将所述向所述CC攻击端发送第二SYN数据包。

在另一个可选的实现方式中，所述装置还包括(图6中未示出)：

截获请求模块，用于请求钩子截获所述CC攻击端向所述目标主机发送的第一SYN数据包，所述钩子安装在所述目标主机的代理端。

截获结果接收模块，用于接收所述钩子发送的所述第一SYN数据包。

数据包发送模块610还用于在所述截获结果接收模块接收所述钩子发送的所述第一SYN数据包后向所述CC攻击端发送第二SYN数据包。

参见图7，图7是本申请CC攻击的处理装置的另一个实施例框图，该装置可包括：数据包发送模块710、回应数据包接收模块720、攻击处理子模块730和清洗处理请求模块740。

其中，数据包发送模块710，用于在接收到CC攻击端向目标主机发送的第一SYN数据包后，向所述CC攻击端发送第二SYN数据包。

回应数据包接收模块720，用于接收所述CC攻击端发送的回应数据包。

攻击处理子模块730，用于在所述回应数据包是SYN/ACK数据包时，终止响应所述CC攻击端发送的任何数据包，以使所述CC攻击端向所述目标主机发送的CC攻击反弹到所述CC攻击端。

清洗处理请求模块740，用于在所述回应数据包是所述CC攻击端伪造的ACK数据包时，请求流量清洗侧对所述CC攻击端发送的数据包进行清洗处理。

在一个可选的实现方式中，所述装置还包括(图7中未示出)：

伪造回应模块，用于在所述回应数据包是所述CC攻击端伪造的ACK数据包时，向所述CC攻击端发送用于回应所述第一SYN数据包的伪造数据包。

上述装置中各个模块的功能和作用的实现过程具体详见上述方法中对应步骤的实现过程，在此不再赘述。

对于装置实施例而言，由于其基本对应于方法实施例，所以相关之处参见方法实施例的部分说明即可。以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的模块可以是或者也可以不是物理上分开的，作为模块显示的部件可以是或者也可以不是物理模块，即可以位于一个地方，或者也可以分布到多个网络模块上。可以根据实际的需要选择其中的部分或者全部模块来实现本申请方案的目的。

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

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

Claims (13)

1.一种CC攻击的处理方法，其特征在于，包括以下步骤：

接收到CC攻击端向目标主机发送的第一SYN数据包后，向所述CC攻击端发送第二SYN数据包；所述第二SYN数据包用于诱导所述CC攻击端进入SYN_RCVD状态；

接收所述CC攻击端回应所述第二SYN数据包发送的SYN/ACK数据包；

接收到所述SYN/ACK数据包后，丢弃并终止响应所述CC攻击端发送的任何数据包，以使所述CC攻击端关闭socket后，陆续进入FIN_WAIT_1状态、FIN_WAIT_2和TIME_WAIT状态，将其向所述目标主机发送的CC攻击反弹到所述CC攻击端。

2.根据权利要求1所述的方法，其特征在于，所述方法还包括：

在接收到所述第一SYN数据包时，启动预设定时器，所述预设定时器的定时时长小于或等于所述CC攻击端重发第一SYN数据包的超时时长；

将所述向所述CC攻击端发送第二SYN数据包的步骤在所述预设定时器超时后执行。

3.根据权利要求1所述的方法，其特征在于，所述方法还包括：

接收到客户端向所述目标主机发送的第一SYN数据包后，请求CC攻击验证侧对所述客户端进行CC攻击验证；

接收所述CC攻击端返回的验证结果；

若所述验证结果表示所述客户端未通过所述CC攻击验证，则确定所述客户端为CC攻击端；

将所述向所述CC攻击端发送第二SYN数据包的步骤在确定所述客户端为CC攻击端后执行。

4.根据权利要求1所述的方法，其特征在于，所述方法还包括：

请求钩子截获所述CC攻击端向所述目标主机发送的第一SYN数据包，所述钩子安装在所述目标主机的代理端；

接收所述钩子发送的所述第一SYN数据包；

所述向所述CC攻击端发送第二SYN数据包的步骤在接收所述钩子发送的所述第一SYN数据包后执行。

5.根据权利要求1至4中任一项所述的方法，其特征在于，所述向所述CC攻击端发送第二SYN数据包后，所述方法还包括：

接收所述CC攻击端发送的回应数据包；

若所述回应数据包是SYN/ACK数据包，则终止响应所述CC攻击端发送的任何数据包，以使所述CC攻击端向所述目标主机发送的CC攻击反弹到所述CC攻击端；

若所述回应数据包是所述CC攻击端伪造的ACK数据包，则请求流量清洗侧对所述CC攻击端发送的数据包进行清洗处理。

6.根据权利要求5所述的方法，其特征在于，若所述回应数据包是所述CC攻击端伪造的ACK数据包，所述方法还包括：

向所述CC攻击端发送用于回应所述第一SYN数据包的伪造数据包。

7.一种CC攻击的处理装置，其特征在于，包括：

数据包发送模块，用于在接收到CC攻击端向目标主机发送的第一SYN数据包后，向所述CC攻击端发送第二SYN数据包；所述第二SYN数据包用于诱导所述CC攻击端进入SYN_RCVD状态；

数据包接收模块，用于接收所述CC攻击端回应所述第二SYN数据包发送的SYN/ACK数据包；

攻击处理模块，用于接收到所述SYN/ACK数据包后，丢弃并终止响应所述CC攻击端发送的任何数据包，以使所述CC攻击端关闭socket后，陆续进入FIN_WAIT_1状态、FIN_WAIT_2和TIME_WAIT状态，将其向所述目标主机发送的CC攻击反弹到所述CC攻击端。

8.根据权利要求7所述的装置，其特征在于，所述装置还包括：

定时模块，用于在接收到所述第一SYN数据包时，启动预设定时器，所述预设定时器的定时时长小于或等于所述CC攻击端重发第一SYN数据包的超时时长；

所述数据包发送模块还用于在所述定时模块的预设定时器超时后将所述向所述CC攻击端发送第二SYN数据包。

9.根据权利要求7所述的装置，其特征在于，所述装置还包括：

攻击验证请求模块，用于在接收到客户端向所述目标主机发送的第一SYN数据包后，请求CC攻击验证侧对所述客户端进行CC攻击验证；

验证结果接收模块，用于接收所述CC攻击端返回的验证结果；

攻击侧确定模块，用于在所述验证结果表示所述客户端未通过所述CC攻击验证时，确定所述客户端为CC攻击端；

所述数据包发送模块还用于在所述攻击侧确定模块确定所述客户端为CC攻击端后将所述向所述CC攻击端发送第二SYN数据包。

10.根据权利要求7所述的装置，其特征在于，所述装置还包括：

截获请求模块，用于请求钩子截获所述CC攻击端向所述目标主机发送的第一SYN数据包，所述钩子安装在所述目标主机的代理端；

截获结果接收模块，用于接收所述钩子发送的所述第一SYN数据包；

所述数据包发送模块还用于在所述截获结果接收模块接收所述钩子发送的所述第一SYN数据包后向所述CC攻击端发送第二SYN数据包。

11.根据权利要求7至10中任一项所述的装置，其特征在于，所述装置还包括：

回应数据包接收模块，用于接收所述CC攻击端发送的回应数据包；

攻击处理子模块，用于在所述回应数据包是SYN/ACK数据包时，终止响应所述CC攻击端发送的任何数据包，以使所述CC攻击端向所述目标主机发送的CC攻击反弹到所述CC攻击端；

清洗处理请求模块，用于在所述回应数据包是所述CC攻击端伪造的ACK数据包时，请求流量清洗侧对所述CC攻击端发送的数据包进行清洗处理。

12.根据权利要求11所述的装置，其特征在于，所述装置还包括：

伪造回应模块，用于在所述回应数据包是所述CC攻击端伪造的ACK数据包时，向所述CC攻击端发送用于回应所述第一SYN数据包的伪造数据包。

13.一种终端，其特征在于，包括：

处理器；

用于存储所述处理器可执行指令的存储器；

其中，所述处理器被配置为：

接收到CC攻击端向目标主机发送的第一SYN数据包后，向所述CC攻击端发送第二SYN数据包；所述第二SYN数据包用于诱导所述CC攻击端进入SYN_RCVD状态；

接收所述CC攻击端回应所述第二SYN数据包发送的SYN/ACK数据包；

接收到所述SYN/ACK数据包后，丢弃并终止响应所述CC攻击端发送的任何数据包，以使所述CC攻击端关闭socket后，陆续进入FIN_WAIT_1状态、FIN_WAIT_2和TIME_WAIT状态，将其向所述目标主机发送的CC攻击反弹到所述CC攻击端。