本申請涉及網(wǎng)絡(luò)通信技術(shù)領(lǐng)域，尤其涉及CC攻擊的處理方法、裝置及終端。

背景技術(shù)：

隨著網(wǎng)絡(luò)技術(shù)的不斷發(fā)展，接入網(wǎng)絡(luò)的用戶端和各種應(yīng)用服務(wù)器越來越多，同時(shí)隨著網(wǎng)絡(luò)攻擊的擴(kuò)散，越來越多的網(wǎng)絡(luò)應(yīng)用受到日益嚴(yán)重的安全威脅，而基于頁面的DDoS攻擊(CC攻擊)逐漸成為網(wǎng)絡(luò)攻擊的主要手段，危害也逐漸加大。

CC攻擊，一般通過攻擊程序比如代理服務(wù)器或者其他控制系統(tǒng)向目標(biāo)主機(jī)發(fā)起大量HTTP連接。為了防御CC攻擊，可對發(fā)送請求的客戶端進(jìn)行確認(rèn)碼驗(yàn)證，如果發(fā)送請求的客戶端被自然人使用，則向所述客戶端推送確認(rèn)頁面，自然人很顯然可以正確識別確認(rèn)頁面中的確認(rèn)碼，也可以輸入正確的確認(rèn)碼。如此，即可允許訪問被保護(hù)的目標(biāo)主機(jī)。而如果客戶端為攻擊程序，比如為代理或者木馬，由于目前的技術(shù)無法使攻擊程序快速正確識別確認(rèn)碼，因此，攻擊程序難以實(shí)現(xiàn)對確認(rèn)碼的驗(yàn)證，進(jìn)而也就無法真正訪問目標(biāo)主機(jī)。

上述CC攻擊防御方法，雖然能在一定程度上防御CC攻擊對目標(biāo)主機(jī)的危害，但是不會對發(fā)起CC攻擊的客戶端造成任何影響，難以有效抑制客戶端發(fā)起CC攻擊。

技術(shù)實(shí)現(xiàn)要素：

本申請?zhí)峁〤C攻擊的處理方法、裝置及終端，以解決現(xiàn)有CC攻擊防御方法難以有效抑制客戶端發(fā)起CC攻擊的問題。

根據(jù)本申請實(shí)施例的第一方面，提供一種CC攻擊的處理方法，包括以下步驟：

接收到CC攻擊端向目標(biāo)主機(jī)發(fā)送的第一SYN數(shù)據(jù)包后，向所述CC攻擊端發(fā)送第二SYN數(shù)據(jù)包；

接收所述CC攻擊端回應(yīng)所述第二SYN數(shù)據(jù)包發(fā)送的SYN/ACK數(shù)據(jù)包；

丟棄并終止響應(yīng)所述CC攻擊端發(fā)送的任何數(shù)據(jù)包，以使所述CC攻擊端向所述目標(biāo)主機(jī)發(fā)送的CC攻擊反彈到所述CC攻擊端。

在一個(gè)實(shí)施例中，所述方法還包括：

在接收到所述第一SYN數(shù)據(jù)包時(shí)，啟動(dòng)預(yù)設(shè)定時(shí)器，所述預(yù)設(shè)定時(shí)器的定時(shí)時(shí)長小于或等于所述CC攻擊端重發(fā)第一SYN數(shù)據(jù)包的超時(shí)時(shí)長；

將所述向所述CC攻擊端發(fā)送第二SYN數(shù)據(jù)包的步驟在所述預(yù)設(shè)定時(shí)器超時(shí)后執(zhí)行。

在一個(gè)實(shí)施例中，所述方法還包括：

接收到客戶端向所述目標(biāo)主機(jī)發(fā)送的第一SYN數(shù)據(jù)包后，請求CC攻擊驗(yàn)證側(cè)對所述客戶端進(jìn)行CC攻擊驗(yàn)證；

接收所述CC攻擊端返回的驗(yàn)證結(jié)果；

若所述驗(yàn)證結(jié)果表示所述客戶端未通過所述CC攻擊驗(yàn)證，則確定所述客戶端為CC攻擊端；

將所述向所述CC攻擊端發(fā)送第二SYN數(shù)據(jù)包的步驟在確定所述客戶端為CC攻擊端后執(zhí)行。

在一個(gè)實(shí)施例中，所述方法還包括：

請求鉤子截獲所述CC攻擊端向所述目標(biāo)主機(jī)發(fā)送的第一SYN數(shù)據(jù)包，所述鉤子安裝在所述目標(biāo)主機(jī)的代理端；

接收所述鉤子發(fā)送的所述第一SYN數(shù)據(jù)包；

所述向所述CC攻擊端發(fā)送第二SYN數(shù)據(jù)包的步驟在接收所述鉤子發(fā)送的所述第一SYN數(shù)據(jù)包后執(zhí)行。

在一個(gè)實(shí)施例中，所述向所述CC攻擊端發(fā)送第二SYN數(shù)據(jù)包后，所述方法還包括：

接收所述CC攻擊端發(fā)送的回應(yīng)數(shù)據(jù)包；

若所述回應(yīng)數(shù)據(jù)包是SYN/ACK數(shù)據(jù)包，則終止響應(yīng)所述CC攻擊端發(fā)送的任何數(shù)據(jù)包，以使所述CC攻擊端向所述目標(biāo)主機(jī)發(fā)送的CC攻擊反彈到所述CC攻擊端；

若所述回應(yīng)數(shù)據(jù)包是所述CC攻擊端偽造的ACK數(shù)據(jù)包，則請求流量清洗側(cè)對所述CC攻擊端發(fā)送的數(shù)據(jù)包進(jìn)行清洗處理。

在一個(gè)實(shí)施例中，若所述回應(yīng)數(shù)據(jù)包是所述CC攻擊端偽造的ACK數(shù)據(jù)包，所述方法還包括：

向所述CC攻擊端發(fā)送用于回應(yīng)所述第一SYN數(shù)據(jù)包的偽造數(shù)據(jù)包。

根據(jù)本申請實(shí)施例的第二方面，提供一種CC攻擊的處理裝置，包括：

數(shù)據(jù)包發(fā)送模塊，用于在接收到CC攻擊端向目標(biāo)主機(jī)發(fā)送的第一SYN數(shù)據(jù)包后，向所述CC攻擊端發(fā)送第二SYN數(shù)據(jù)包；

數(shù)據(jù)包接收模塊，用于接收所述CC攻擊端回應(yīng)所述第二SYN數(shù)據(jù)包發(fā)送的SYN/ACK數(shù)據(jù)包；

攻擊處理模塊，用于丟棄并終止響應(yīng)所述CC攻擊端發(fā)送的任何數(shù)據(jù)包，以使所述CC攻擊端向所述目標(biāo)主機(jī)發(fā)送的CC攻擊反彈到所述CC攻擊端。

在一個(gè)實(shí)施例中，所述裝置還包括：

定時(shí)模塊，用于在接收到所述第一SYN數(shù)據(jù)包時(shí)，啟動(dòng)預(yù)設(shè)定時(shí)器，所述預(yù)設(shè)定時(shí)器的定時(shí)時(shí)長小于或等于所述CC攻擊端重發(fā)第一SYN數(shù)據(jù)包的超時(shí)時(shí)長；

所述數(shù)據(jù)包發(fā)送模塊還用于在所述定時(shí)模塊的預(yù)設(shè)定時(shí)器超時(shí)后將所述向所述CC攻擊端發(fā)送第二SYN數(shù)據(jù)包。

在一個(gè)實(shí)施例中，所述裝置還包括：

攻擊驗(yàn)證請求模塊，用于在接收到客戶端向所述目標(biāo)主機(jī)發(fā)送的第一SYN數(shù)據(jù)包后，請求CC攻擊驗(yàn)證側(cè)對所述客戶端進(jìn)行CC攻擊驗(yàn)證；

驗(yàn)證結(jié)果接收模塊，用于接收所述CC攻擊端返回的驗(yàn)證結(jié)果；

攻擊側(cè)確定模塊，用于在所述驗(yàn)證結(jié)果表示所述客戶端未通過所述CC攻擊驗(yàn)證時(shí)，確定所述客戶端為CC攻擊端；

所述數(shù)據(jù)包發(fā)送模塊還用于在所述攻擊側(cè)確定模塊確定所述客戶端為CC攻擊端后將所述向所述CC攻擊端發(fā)送第二SYN數(shù)據(jù)包。

在一個(gè)實(shí)施例中，所述裝置還包括：

截獲請求模塊，用于請求鉤子截獲所述CC攻擊端向所述目標(biāo)主機(jī)發(fā)送的第一SYN數(shù)據(jù)包，所述鉤子安裝在所述目標(biāo)主機(jī)的代理端；

截獲結(jié)果接收模塊，用于接收所述鉤子發(fā)送的所述第一SYN數(shù)據(jù)包；

所述數(shù)據(jù)包發(fā)送模塊還用于在所述截獲結(jié)果接收模塊接收所述鉤子發(fā)送的所述第一SYN數(shù)據(jù)包后向所述CC攻擊端發(fā)送第二SYN數(shù)據(jù)包。

在一個(gè)實(shí)施例中，所述裝置還包括：

回應(yīng)數(shù)據(jù)包接收模塊，用于接收所述CC攻擊端發(fā)送的回應(yīng)數(shù)據(jù)包；

攻擊處理子模塊，用于在所述回應(yīng)數(shù)據(jù)包是SYN/ACK數(shù)據(jù)包時(shí)，終止響應(yīng)所述CC攻擊端發(fā)送的任何數(shù)據(jù)包，以使所述CC攻擊端向所述目標(biāo)主機(jī)發(fā)送的CC攻擊反彈到所述CC攻擊端；

清洗處理請求模塊，用于在所述回應(yīng)數(shù)據(jù)包是所述CC攻擊端偽造的ACK數(shù)據(jù)包時(shí)，請求流量清洗側(cè)對所述CC攻擊端發(fā)送的數(shù)據(jù)包進(jìn)行清洗處理。

在一個(gè)實(shí)施例中，所述裝置還包括：

偽造回應(yīng)模塊，用于在所述回應(yīng)數(shù)據(jù)包是所述CC攻擊端偽造的ACK數(shù)據(jù)包時(shí)，向所述CC攻擊端發(fā)送用于回應(yīng)所述第一SYN數(shù)據(jù)包的偽造數(shù)據(jù)包。

根據(jù)本申請實(shí)施例的第三方面，提供一種終端，其特征在于，包括：

處理器；

用于存儲所述處理器可執(zhí)行指令的存儲器；

其中，所述處理器被配置為：

接收到CC攻擊端向目標(biāo)主機(jī)發(fā)送的第一SYN數(shù)據(jù)包后，向所述CC攻擊端發(fā)送第二SYN數(shù)據(jù)包；

接收所述CC攻擊端回應(yīng)所述第二SYN數(shù)據(jù)包發(fā)送的SYN/ACK數(shù)據(jù)包；

丟棄并終止響應(yīng)所述CC攻擊端發(fā)送的任何數(shù)據(jù)包，以使所述CC攻擊端向所述目標(biāo)主機(jī)發(fā)送的CC攻擊反彈到所述CC攻擊端。

應(yīng)用本申請實(shí)施例，接收到CC攻擊端向目標(biāo)主機(jī)發(fā)送的第一SYN數(shù)據(jù)包后，向所述CC攻擊端發(fā)送第二SYN數(shù)據(jù)包；接收所述CC攻擊端回應(yīng)所述第二SYN數(shù)據(jù)包發(fā)送的SYN/ACK數(shù)據(jù)包后，丟棄并終止響應(yīng)所述CC攻擊端發(fā)送的任何數(shù)據(jù)包，可使CC攻擊端響應(yīng)所述第二SYN數(shù)據(jù)包發(fā)送SYN/ACK數(shù)據(jù)包括后進(jìn)入SYN_RCVD狀態(tài)，其關(guān)閉socket后，陸續(xù)進(jìn)入FIN_WAIT_1狀態(tài)、FIN_WAIT_2狀態(tài)和TIME_WAIT狀態(tài)，這些狀態(tài)下CC攻擊端的socket資源持續(xù)被占用，而且能將CC攻擊端向目標(biāo)主機(jī)發(fā)送的數(shù)據(jù)包都反彈到其自身，消耗CC攻擊端自身的socket資源，最終使得CC攻擊端沒有足夠資源發(fā)送CC攻擊。因此，能在有效防御CC攻擊端對目標(biāo)主機(jī)的危害的同時(shí)，消耗CC攻擊端的socket資源，進(jìn)而能有效抑制CC攻擊端發(fā)起的CC攻擊。

應(yīng)當(dāng)理解的是，以上的一般描述和后文的細(xì)節(jié)描述僅是示例性和解釋性的，并不能限制本申請。

附圖說明

此處的附圖被并入說明書中并構(gòu)成本說明書的一部分，示出了符合本申請的實(shí)施例，并與說明書一起用于解釋本申請的原理。

圖1是本申請實(shí)施例實(shí)現(xiàn)CC攻擊的處理的一個(gè)應(yīng)用場景示意圖；

圖2是本申請CC攻擊的處理方法的實(shí)施例中的TCP連接的狀態(tài)轉(zhuǎn)換圖；

圖3是本申請CC攻擊的處理方法的一個(gè)實(shí)施例流程圖；

圖4是本申請CC攻擊的處理方法的另一個(gè)實(shí)施例流程圖；

圖5是本申請CC攻擊的處理裝置所在終端的一種硬件結(jié)構(gòu)圖；

圖6是本申請CC攻擊的處理裝置的一個(gè)實(shí)施例框圖；

圖7是本申請CC攻擊的處理裝置的另一個(gè)實(shí)施例框圖。

具體實(shí)施方式

這里將詳細(xì)地對示例性實(shí)施例進(jìn)行說明，其示例表示在附圖中。下面的描述涉及附圖時(shí)，除非另有表示，不同附圖中的相同數(shù)字表示相同或相似的要素。以下示例性實(shí)施例中所描述的實(shí)施方式并不代表與本申請相一致的所有實(shí)施方式。相反，它們僅是與如所附權(quán)利要求書中所詳述的、本申請的一些方面相一致的裝置和方法的例子。

在本申請使用的術(shù)語是僅僅出于描述特定實(shí)施例的目的，而非旨在限制本申請。在本申請和所附權(quán)利要求書中所使用的單數(shù)形式的“一種”、“所述”和“該”也旨在包括多數(shù)形式，除非上下文清楚地表示其他含義。還應(yīng)當(dāng)理解，本文中使用的術(shù)語“和/或”是指并包含一個(gè)或多個(gè)相關(guān)聯(lián)的列出項(xiàng)目的任何或所有可能組合。

應(yīng)當(dāng)理解，盡管在本申請可能采用術(shù)語第一、第二、第三等來描述各種信息，但這些信息不應(yīng)限于這些術(shù)語。這些術(shù)語僅用來將同一類型的信息彼此區(qū)分開。例如，在不脫離本申請范圍的情況下，第一信息也可以被稱為第二信息，類似地，第二信息也可以被稱為第一信息。取決于語境，如在此所使用的詞語“如果”可以被解釋成為“在……時(shí)”或“當(dāng)……時(shí)”或“響應(yīng)于確定”。

請參閱圖1，圖1是本申請實(shí)施例實(shí)現(xiàn)CC攻擊的處理的一個(gè)應(yīng)用場景示意圖。

圖1所示應(yīng)用場景示意圖，包括客戶端120、裝設(shè)有客戶端120的終端以及作為目標(biāo)主機(jī)的服務(wù)器140，所述終端與服務(wù)器140通過無線網(wǎng)絡(luò)或有線網(wǎng)絡(luò)連接，并基于網(wǎng)絡(luò)連接在兩者之間進(jìn)行信息傳輸和交互。所述終端可以包括智能手機(jī)、臺式機(jī)、筆記本、個(gè)人數(shù)字助理、平板電腦等終端設(shè)備中的至少一種?？梢岳斫獾氖?，本實(shí)施例的目標(biāo)主機(jī)僅以服務(wù)器為例進(jìn)行說明，還可以是PC(Personal Computer，個(gè)人計(jì)算機(jī))或平板電腦等智能終端。

服務(wù)器140，運(yùn)行有向客戶端120提供各種服務(wù)的服務(wù)端，該服務(wù)端可通過網(wǎng)絡(luò)向客戶端120提供各種服務(wù)，如FTP(File Transfer Protocol，文件傳輸協(xié)議)、游戲端口、聊天房間、網(wǎng)頁論壇等。服務(wù)端向客戶端120提供服務(wù)前，需要客戶端120通過其所在終端與服務(wù)器140建立一條鏈接，該條鏈接通常是基于TCP協(xié)議建立的TCP鏈接，而TCP鏈接的狀態(tài)轉(zhuǎn)換如圖2所示，TCP鏈接的建立可以簡單的稱為三次握手，TCP鏈接的中止則可以叫做四次握手。

下面簡要說明圖2所示的TCP鏈接的狀態(tài)轉(zhuǎn)移過程：

首先說明下圖2中的粗線，即客戶端120的狀態(tài)轉(zhuǎn)移過程：在CLOSED狀態(tài)下，客戶端120向目的服務(wù)器140發(fā)起鏈接，即向服務(wù)器140發(fā)送SYN k數(shù)據(jù)包，也就是客戶端120調(diào)用了connect函數(shù)，然后進(jìn)入SYN_SENT狀態(tài)，此時(shí)若等待服務(wù)器140返回對SYN k數(shù)據(jù)包的ACK數(shù)據(jù)包超時(shí)，則客戶端120重新進(jìn)入CLOSED狀態(tài)，若客戶端120準(zhǔn)時(shí)收到了服務(wù)器140返回來的ACK數(shù)據(jù)包以及自己的SYN j數(shù)據(jù)包(即返回SYN/ACK數(shù)據(jù)包)，客戶端120先向服務(wù)器140發(fā)送回應(yīng)SYN j數(shù)據(jù)包的ACK數(shù)據(jù)包，然后進(jìn)入ESTABLISHED狀態(tài)，也就是說客戶端120與服務(wù)器140連接成功。在此狀態(tài)下，客戶端120與服務(wù)器140進(jìn)行正常的通信。

若通信結(jié)束，客戶端120向服務(wù)器140發(fā)送FIN數(shù)據(jù)包，也就是客戶端120調(diào)用了close函數(shù)，然后客戶端120進(jìn)入FIN_WAIT_1狀態(tài)等待著服務(wù)器140返回來回應(yīng)FIN數(shù)據(jù)包的ACK數(shù)據(jù)包，當(dāng)接收到服務(wù)器140返回來的ACK數(shù)據(jù)包后，客戶端120進(jìn)入FIN_WAIT_2狀態(tài)，因?yàn)橥ㄐ攀请p端的，所以服務(wù)器140也會向客戶端120發(fā)送FIN數(shù)據(jù)包(也就是服務(wù)器140也調(diào)用了close函數(shù))，這時(shí)客戶端120向服務(wù)器140發(fā)送回應(yīng)FIN數(shù)據(jù)包的ACK數(shù)據(jù)包，同時(shí)進(jìn)行入TIME_WAIT狀態(tài)。TIME_WAIT狀態(tài)持續(xù)2MSL(MSL最長分節(jié)生命期)后，進(jìn)入CLOSED狀態(tài)，也就socket(網(wǎng)絡(luò)上的兩個(gè)程序通過一個(gè)雙向的通信連接實(shí)現(xiàn)數(shù)據(jù)的交換，這個(gè)連接的一端稱為一個(gè)socket)正式關(guān)閉。之所以在WAIT_2和CLOSED之間加入一個(gè)TIME_WAIT狀態(tài)且維持2MSL，是出于兩個(gè)目的，1)確保TCP全雙工的終止，例如：在FIN_WAIT_2狀態(tài)時(shí)，客戶端120發(fā)完ACK數(shù)據(jù)包的后就關(guān)閉了，而此時(shí)這個(gè)ACK數(shù)據(jù)包又發(fā)丟失了，這將導(dǎo)致服務(wù)器140收不到其回應(yīng)FIN數(shù)據(jù)包的ACK數(shù)據(jù)包而無法關(guān)閉。2)確保上一次鏈接產(chǎn)生的數(shù)據(jù)包，在下一次再次鏈接之前就全部消失，不對下一次鏈接產(chǎn)生影響。

其次說明下圖2中的虛線，即服務(wù)器140的狀態(tài)轉(zhuǎn)移過程：服務(wù)器140處在LISTEN狀態(tài)時(shí)，也就是服務(wù)器140調(diào)用了listen和accept函數(shù)，此時(shí)服務(wù)器140收到了客戶端120發(fā)送來的連接請求，也就是SYN k數(shù)據(jù)包，然后返回給客戶端120自己的同步數(shù)據(jù)包SYN j數(shù)據(jù)包和對客戶端120的SYN k數(shù)據(jù)包進(jìn)行回應(yīng)的ACK k+1數(shù)據(jù)包(即，回復(fù)SYN/ACK數(shù)據(jù)包)。此時(shí)服務(wù)器140進(jìn)入SYS_RCVD狀態(tài)，等待著客戶端120返回對ACK j+1數(shù)據(jù)包進(jìn)行回應(yīng)確認(rèn)的ACK數(shù)據(jù)包，若收到了此ACK數(shù)據(jù)包，服務(wù)器140進(jìn)入ESTABLISHED狀態(tài)，若沒有收到還會重復(fù)發(fā)送(上圖沒有標(biāo)出若服務(wù)器140發(fā)送完SYN J ACK k+1數(shù)據(jù)包后客戶端120宕機(jī)了后的狀態(tài)，一般會有一個(gè)重發(fā)機(jī)制)。服務(wù)器140的socket關(guān)閉過程與客戶端120的關(guān)閉過程有些不一樣，因?yàn)榉?wù)器140是被迫關(guān)閉，此時(shí)服務(wù)器140收到客戶端120發(fā)來的FIN數(shù)據(jù)包，然后向客戶端120返回對FIN數(shù)據(jù)包回應(yīng)確認(rèn)的ACK數(shù)據(jù)包，并進(jìn)入CLOSE_WAIT狀態(tài)，在此狀態(tài)下，服務(wù)器140將自己socket內(nèi)的數(shù)據(jù)處理完畢之后，同樣向客戶端120發(fā)送FIN數(shù)據(jù)包也就是調(diào)用close函數(shù)，此時(shí)服務(wù)器140進(jìn)入LAST_ACK狀態(tài)，在收到來自客戶端120的ACK數(shù)據(jù)包后進(jìn)入最終的CLOSED狀態(tài)。

最后說明下圖2中的細(xì)線，細(xì)線代表客戶端120和服務(wù)器140同時(shí)打開和同時(shí)關(guān)閉時(shí)，TCP鏈接的狀態(tài)轉(zhuǎn)變，同時(shí)打開即客戶端120發(fā)送了SYN數(shù)據(jù)包之后，服務(wù)器140也恰好發(fā)送了SYN數(shù)據(jù)包到客戶端120的同樣的端口；同時(shí)關(guān)閉即客戶端120發(fā)送了FIN數(shù)據(jù)包之后，服務(wù)器140也恰好發(fā)送了FIN數(shù)據(jù)包到客戶端120的同樣的端口。這兩種狀態(tài)在現(xiàn)實(shí)中幾乎不發(fā)生，即使發(fā)生也一般發(fā)生在兩個(gè)服務(wù)器之間，因?yàn)樗麄儽仨毿枰缹Ψ降亩丝谥怠?/p>

圖2中的RST是另一種關(guān)閉鏈接的方式，應(yīng)用程序應(yīng)該可以判斷RST包的真實(shí)性，即是否為異常中止。

本申請實(shí)施例的CC攻擊的處理方法，可在客戶端120要對服務(wù)器140發(fā)起CC攻擊時(shí)，基于以上所述的TCP鏈接的狀態(tài)轉(zhuǎn)移過程，利用客戶端120與服務(wù)器140之間的同步打開狀態(tài)，在接收到客戶端120向服務(wù)器140發(fā)送第一SYN數(shù)據(jù)包后，向客戶端120發(fā)送第二SYN數(shù)據(jù)包，接收到客戶端120回復(fù)的SYN/ACK數(shù)據(jù)包后，不再回復(fù)客戶端120的任何數(shù)據(jù)包，可使客戶端120響應(yīng)所述第二SYN數(shù)據(jù)包發(fā)送SYN/ACK數(shù)據(jù)包括后陸續(xù)進(jìn)入SYN_RCVD狀態(tài)，其關(guān)閉socket后，陸續(xù)進(jìn)入FIN_WAIT_1狀態(tài)、FIN_WAIT_2和TIME_WAIT狀態(tài)。從而使客戶端120的后續(xù)表現(xiàn)就好像自身是服務(wù)器140一樣，所有針對服務(wù)器140的鏈接請求(SYN數(shù)據(jù)包)都被反彈給了自己，從而消耗其自身的socket資源。因此，能在有效防御客戶端120對服務(wù)器140的CC攻擊，同時(shí)消耗客戶端120的socket資源，進(jìn)而能有效抑制客戶端120發(fā)起的CC攻擊。

本申請實(shí)施例的CC攻擊的處理方法可直接運(yùn)行于服務(wù)器140，也可運(yùn)行于服務(wù)器140前端的代理端，代理端如nginx(高性能的HTTP和反向代理服務(wù)器)等。下面將結(jié)合附圖1和圖2對本申請實(shí)施例進(jìn)行詳細(xì)描述。

參見圖3，圖3是本申請CC攻擊的處理方法的一個(gè)實(shí)施例流程圖，包括以下步驟301-303：

步驟301：接收到CC攻擊端向目標(biāo)主機(jī)發(fā)送的第一SYN數(shù)據(jù)包后，向所述CC攻擊端發(fā)送第二SYN數(shù)據(jù)包。

參閱圖2可知，SYN(synchronous)是TCP/IP建立連接時(shí)使用的握手信號，在客戶端和服務(wù)器之間建立正常的TCP網(wǎng)絡(luò)連接時(shí)，客戶端首先發(fā)出一個(gè)SYN數(shù)據(jù)包，服務(wù)器使用SYN與ACK數(shù)據(jù)包(SYN/ACK數(shù)據(jù)包)應(yīng)答，表示接收到了這個(gè)SYN數(shù)據(jù)包，最后客戶端再以ACK數(shù)據(jù)包響應(yīng)。這樣在客戶端和服務(wù)器之間才能建立起可靠的TCP連接，數(shù)據(jù)信息才可以在客戶端和服務(wù)器之間傳遞。但是，在客戶端作為CC攻擊端，對服務(wù)器發(fā)起CC攻擊時(shí)，SYN攻擊是最常見又最容易被利用的一種攻擊手法，利用TCP協(xié)議缺陷，客戶端在短時(shí)間內(nèi)偽造大量不存在的IP地址，向服務(wù)器不斷地發(fā)送大量的第一SYN數(shù)據(jù)包，第一SYN數(shù)據(jù)包為偽造的數(shù)據(jù)包，若服務(wù)器回復(fù)確認(rèn)數(shù)據(jù)包，并等待客戶端的確認(rèn)，由于源地址是不存在的，服務(wù)器需要不斷的重發(fā)確認(rèn)包直至超時(shí)，這些偽造的第一SYN數(shù)據(jù)包將長時(shí)間占用未連接隊(duì)列，正常的SYN數(shù)據(jù)包被丟棄，服務(wù)器對應(yīng)的目標(biāo)系統(tǒng)運(yùn)行緩慢，嚴(yán)重者引起網(wǎng)絡(luò)堵塞甚至系統(tǒng)癱瘓。

為了避免服務(wù)器接收到發(fā)起CC攻擊的客戶端發(fā)送的第一SYN數(shù)據(jù)包后，回復(fù)確認(rèn)數(shù)據(jù)包并等待發(fā)起CC攻擊的客戶端的確認(rèn)，導(dǎo)致服務(wù)器對應(yīng)的目標(biāo)系統(tǒng)運(yùn)行緩慢，甚至引起網(wǎng)絡(luò)堵塞甚至系統(tǒng)癱瘓，可在接收到發(fā)起CC攻擊的客戶端發(fā)送的第一SYN數(shù)據(jù)包后，不回復(fù)確認(rèn)數(shù)據(jù)包，而是向發(fā)起CC攻擊的客戶端(即CC攻擊端)發(fā)送所述第二SYN數(shù)據(jù)包，等同于發(fā)起CC攻擊的客戶端與服務(wù)器處于同時(shí)打開狀態(tài)，誘導(dǎo)發(fā)起CC攻擊的客戶端回復(fù)對第二SYN數(shù)據(jù)包的確認(rèn)數(shù)據(jù)包，并等待確認(rèn)。

本申請實(shí)施例的所述第二SYN數(shù)據(jù)包是向發(fā)起CC攻擊的客戶端發(fā)送，不影響發(fā)起正常鏈接請求的客戶端，在接收到客戶端向所述目標(biāo)主機(jī)發(fā)送的第一SYN數(shù)據(jù)包后，可先驗(yàn)證發(fā)送第一SYN數(shù)據(jù)包的客戶端是否對目標(biāo)主機(jī)進(jìn)行CC攻擊，若是，再向客戶端發(fā)送所述第一SYN數(shù)據(jù)包。

在某些應(yīng)用場景中，本申請實(shí)施例的CC攻擊的處理方法應(yīng)用于目標(biāo)主機(jī)的代理端，驗(yàn)證發(fā)送第一SYN數(shù)據(jù)包的客戶端是否對目標(biāo)主機(jī)進(jìn)行CC攻擊時(shí)，可請求CC攻擊驗(yàn)證側(cè)對所述客戶端進(jìn)行CC攻擊驗(yàn)證，然后接收所述CC攻擊端返回的驗(yàn)證結(jié)果，若所述驗(yàn)證結(jié)果表示所述客戶端未通過所述CC攻擊驗(yàn)證，則確定所述客戶端為CC攻擊端，將所述向所述CC攻擊端發(fā)送第二SYN數(shù)據(jù)包的步驟在確定所述客戶端為CC攻擊端后執(zhí)行。若所述驗(yàn)證結(jié)果表示所述客戶端通過了所述CC攻擊驗(yàn)證，則確定所述客戶端不是CC攻擊端，繼續(xù)發(fā)送所述第一SYN數(shù)據(jù)包至所述目標(biāo)主機(jī)。

實(shí)際應(yīng)用時(shí)，上述攻擊驗(yàn)證側(cè)，可以是與目標(biāo)主機(jī)關(guān)聯(lián)的CC攻擊驗(yàn)證設(shè)備、可以是目標(biāo)主機(jī)內(nèi)的CC攻擊驗(yàn)證模塊、還可以是流量清洗設(shè)備內(nèi)的CC攻擊驗(yàn)證模塊，因此在本申請實(shí)施例需要對所述客戶端進(jìn)行CC攻擊驗(yàn)證時(shí)，目標(biāo)主機(jī)的代理端可直接調(diào)用目標(biāo)主機(jī)內(nèi)的CC攻擊驗(yàn)證模塊對所述客戶端進(jìn)行CC攻擊驗(yàn)證，或者，請求所述CC攻擊驗(yàn)證設(shè)備或所述流量清洗設(shè)備對所述客戶端進(jìn)行CC攻擊驗(yàn)證。

針對上述應(yīng)用于目標(biāo)主機(jī)的代理端的CC攻擊的處理方法，若CC攻擊端向目標(biāo)主機(jī)發(fā)送的第一SYN數(shù)據(jù)包，不需要代理端轉(zhuǎn)發(fā)，那么本申請實(shí)施例可請求代理端安裝的鉤子截獲所述CC攻擊端向所述目標(biāo)主機(jī)發(fā)送的第一SYN數(shù)據(jù)包，接收所述鉤子發(fā)送的所述第一SYN數(shù)據(jù)包，然后向所述CC攻擊端發(fā)送第二SYN數(shù)據(jù)包。

在某些例子中，CC攻擊端向目標(biāo)主機(jī)發(fā)送第一SYN數(shù)據(jù)包后，若預(yù)設(shè)時(shí)段內(nèi)接收不到回應(yīng)數(shù)據(jù)包，會延時(shí)重發(fā)所述第一SYN數(shù)據(jù)包，CC攻擊端的操作系統(tǒng)，重發(fā)時(shí)間和重發(fā)次數(shù)不同，例如，windows系統(tǒng)會重發(fā)3次，第一次重發(fā)時(shí)間是3s，若在發(fā)送第一SYN數(shù)據(jù)包后3s內(nèi)接收不到回應(yīng)數(shù)據(jù)包，則第一次重發(fā)所述第一SYN數(shù)據(jù)包，第二次重發(fā)時(shí)間是6s，第三次重發(fā)時(shí)間是12s，三次重發(fā)之后超時(shí)返回，超時(shí)時(shí)間是21s；Linux系統(tǒng)一般重發(fā)5次，第一次重發(fā)時(shí)間是2s，第二次重發(fā)時(shí)間是4s，第三次重發(fā)時(shí)間是8s，第四次重發(fā)時(shí)間是16s，第五次重發(fā)時(shí)間是32s，五次重發(fā)之后超時(shí)返回，超時(shí)時(shí)間是62s。

為了耗盡CC攻擊端的socket資源，可使CC攻擊端盡可能多的進(jìn)行延時(shí)重發(fā)，因此，本申請實(shí)施例的CC攻擊的處理方法，在接收到所述第一SYN數(shù)據(jù)包時(shí)，啟動(dòng)預(yù)設(shè)定時(shí)器，所述預(yù)設(shè)定時(shí)器的定時(shí)時(shí)長小于或等于所述CC攻擊端重發(fā)第一SYN數(shù)據(jù)包的超時(shí)時(shí)長，將所述向所述CC攻擊端發(fā)送第二SYN數(shù)據(jù)包的步驟在所述預(yù)設(shè)定時(shí)器超時(shí)后執(zhí)行。所述CC攻擊端重發(fā)第一SYN數(shù)據(jù)包的超時(shí)時(shí)長由CC攻擊端的操作系統(tǒng)決定，可以為上述的21s或62s。

通過上述定時(shí)器的啟動(dòng)，本申請實(shí)施例延遲第二SYN數(shù)據(jù)包的發(fā)送，使CC攻擊端在SYN_SENT狀態(tài)進(jìn)行多次延時(shí)重發(fā)第一SYN數(shù)據(jù)包，消耗自身的sokcet資源。例如，對于多線程的CC攻擊，本申請實(shí)施例通過定時(shí)器的啟動(dòng)延遲第二SYN數(shù)據(jù)包的發(fā)送，可最大化每個(gè)連接的延時(shí)，將所有的線程都堵住，就可以快速降低客戶端發(fā)送cc攻擊的頻率；對于使用異步連接的CC攻擊，本申請實(shí)施例通過定時(shí)器的啟動(dòng)延遲第二SYN數(shù)據(jù)包的發(fā)送，可以延緩每一個(gè)鏈接的建立數(shù)目，如此，客戶端的TCP資源將大量的處于SYN_SENT、SYN_RCVD和FIN_WAIT_1狀態(tài)，直至耗盡資源。

步驟302：接收所述CC攻擊端回應(yīng)所述第二SYN數(shù)據(jù)包發(fā)送的SYN/ACK數(shù)據(jù)包。

本申請實(shí)施例中，接收到CC攻擊端發(fā)送SYN/ACK數(shù)據(jù)包后，即成功誘導(dǎo)CC攻擊端進(jìn)入SYN_RCVD狀態(tài)，CC攻擊端的socket關(guān)閉后，會依次進(jìn)入FIN_WAIT_1狀態(tài)、FIN_WAIT_2和TIME_WAIT狀態(tài)?？墒笴C攻擊端的后續(xù)表現(xiàn)就好像自身是目標(biāo)主機(jī)一樣，所有針對目標(biāo)主機(jī)的鏈接請求(數(shù)據(jù)包)都被反彈給了自己，從而消耗其自身的socket資源。

步驟303：丟棄并終止響應(yīng)所述CC攻擊端發(fā)送的任何數(shù)據(jù)包，以使所述CC攻擊端向所述目標(biāo)主機(jī)發(fā)送的CC攻擊反彈到所述CC攻擊端。

本申請實(shí)施例，在首次接收到CC攻擊端發(fā)送SYN/ACK數(shù)據(jù)包后，即成功誘導(dǎo)CC攻擊端進(jìn)入SYN_RCVD狀態(tài)，為了盡可能延長CC攻擊端處于各個(gè)TCP狀態(tài)的時(shí)間，丟棄并不再響應(yīng)所述CC攻擊端發(fā)送的任何數(shù)據(jù)包，即不響應(yīng)CC攻擊端的任何請求，不回復(fù)任何數(shù)據(jù)。例如：重復(fù)接收到CC攻擊端發(fā)送的第一SYN數(shù)據(jù)包，不回復(fù)SYN/ACK數(shù)據(jù)包；重復(fù)接收到CC攻擊端發(fā)送的SYN/ACK數(shù)據(jù)包，也不回復(fù)ACK數(shù)據(jù)包。

誘導(dǎo)CC攻擊端響應(yīng)所述第二SYN數(shù)據(jù)包發(fā)送SYN/ACK數(shù)據(jù)包進(jìn)入SYN_RCVD狀態(tài)后，CC攻擊端為了避免目標(biāo)主機(jī)返回的數(shù)據(jù)將自身的帶寬堵死會關(guān)閉socket，或者長期接收不到目標(biāo)主機(jī)回復(fù)的數(shù)據(jù)包，會超時(shí)關(guān)閉socket,其關(guān)閉socket后，陸續(xù)進(jìn)入FIN_WAIT_1狀態(tài)、FIN_WAIT_2狀態(tài)和TIME_WAIT狀態(tài)，這些狀態(tài)下CC攻擊端的socket資源持續(xù)被占用，而且能將CC攻擊端向目標(biāo)主機(jī)發(fā)送的數(shù)據(jù)包都反彈到其自身，消耗CC攻擊端自身的socket資源，最終使得CC攻擊端沒有足夠資源發(fā)送CC攻擊。因此，能在有效防御CC攻擊端對目標(biāo)主機(jī)的危害，同時(shí)消耗CC攻擊端的socket資源，能有效抑制CC攻擊端發(fā)起的CC攻擊，避免CC攻擊造成目標(biāo)主機(jī)側(cè)帶寬的消耗，進(jìn)而能降低目標(biāo)主機(jī)側(cè)的運(yùn)營成本。

此外，本申請實(shí)施例對于發(fā)起惡意高頻CC攻擊的CC攻擊端，無需消耗目標(biāo)主機(jī)或目標(biāo)主機(jī)的代理端的資源，即可更高效地將CC攻擊端向目標(biāo)主機(jī)發(fā)送數(shù)據(jù)包反彈到其自身，更快速地消耗CC攻擊端自身的socket資源。

由上述實(shí)施例可知，本申請實(shí)施例能使所述CC攻擊端向所述目標(biāo)主機(jī)的發(fā)送的CC攻擊反彈到所述CC攻擊端，前提是能誘導(dǎo)CC攻擊端響應(yīng)所述第二SYN數(shù)據(jù)包發(fā)送SYN/ACK數(shù)據(jù)包進(jìn)入SYN_RCVD狀態(tài)。而某些應(yīng)用場景中，CC攻擊端(使用攻擊軟件dossim的客戶端)會繞過協(xié)議棧，偽造數(shù)據(jù)包，自己完成建立TCP鏈接所需的三次握手，無法正確響應(yīng)本申請上述實(shí)施例中的第二SYN數(shù)據(jù)包，進(jìn)而CC攻擊端不會被誘導(dǎo)進(jìn)入SYN_RCVD狀態(tài)。針對該類應(yīng)用場景中的CC攻擊端發(fā)起的CC攻擊，可直接識別進(jìn)行清洗，具體可參見圖4，圖4是本申請CC攻擊的處理方法的另一個(gè)實(shí)施例流程圖，包括以下步驟401-404：

步驟401：接收到CC攻擊端向目標(biāo)主機(jī)發(fā)送的第一SYN數(shù)據(jù)包后，向所述CC攻擊端發(fā)送第二SYN數(shù)據(jù)包。

本步驟的實(shí)現(xiàn)方式可參見上述實(shí)施例中步驟301的實(shí)現(xiàn)方式。

步驟402：接收所述CC攻擊端發(fā)送的回應(yīng)數(shù)據(jù)包。

本申請實(shí)施例中，若CC攻擊端發(fā)起的CC攻擊未繞過協(xié)議棧，則回應(yīng)數(shù)據(jù)包可以是SYN/ACK數(shù)據(jù)包，若CC攻擊端發(fā)起的CC攻擊繞過了協(xié)議棧，則回應(yīng)數(shù)據(jù)包可以是偽造的ACK數(shù)據(jù)包。

步驟403：若所述回應(yīng)數(shù)據(jù)包是SYN/ACK數(shù)據(jù)包，則終止響應(yīng)所述CC攻擊端發(fā)送的任何數(shù)據(jù)包，以使所述CC攻擊端向所述目標(biāo)主機(jī)發(fā)送的CC攻擊反彈到所述CC攻擊端。

步驟404：若所述回應(yīng)數(shù)據(jù)包是所述CC攻擊端偽造的ACK數(shù)據(jù)包，則請求流量清洗側(cè)對所述CC攻擊端發(fā)送的數(shù)據(jù)包進(jìn)行清洗處理。

本申請實(shí)施例中，偽造的ACK數(shù)據(jù)包不滿足協(xié)議棧的協(xié)議標(biāo)準(zhǔn)，用于實(shí)現(xiàn)CC攻擊端完成建立TCP鏈接所需的三次握手。

上述流量清洗側(cè)，可以是與目標(biāo)主機(jī)關(guān)聯(lián)的流量清洗設(shè)備、可以是目標(biāo)主機(jī)內(nèi)的流量清洗模塊，因此在本申請實(shí)施例需要流量清洗側(cè)對所述CC攻擊端發(fā)送的數(shù)據(jù)包進(jìn)行清洗處理時(shí)，目標(biāo)主機(jī)的代理端可直接調(diào)用目標(biāo)主機(jī)內(nèi)的流量清洗模塊對所述客戶端發(fā)送的數(shù)據(jù)包進(jìn)行清洗，或者，將CC攻擊端發(fā)送的數(shù)據(jù)包發(fā)送到與目標(biāo)主機(jī)關(guān)聯(lián)的流量清洗設(shè)備進(jìn)行清洗。

此外，為了防止CC攻擊端覺察到其已被識別，本申請實(shí)施例可在所述回應(yīng)數(shù)據(jù)包是所述CC攻擊端偽造的ACK數(shù)據(jù)包時(shí)，向所述CC攻擊端發(fā)送用于回應(yīng)所述第一SYN數(shù)據(jù)包的偽造數(shù)據(jù)包，完成偽裝響應(yīng)。

由上述實(shí)施例可知：本申請既可以對使用協(xié)議棧發(fā)起CC攻擊的CC攻擊端向目標(biāo)主機(jī)發(fā)送的數(shù)據(jù)包都反彈到其自身，消耗CC攻擊端自身的socket資源，最終使得CC攻擊端沒有足夠資源發(fā)送CC攻擊。因此能在有效防御CC攻擊端對目標(biāo)主機(jī)的危害的同時(shí)，消耗CC攻擊端的socket資源，進(jìn)而能有效抑制CC攻擊端發(fā)起的CC攻擊。本申請還可以直接清洗繞過協(xié)議棧發(fā)起的CC攻擊，無需應(yīng)用層判斷CC攻擊端發(fā)起的請求的有效性，能顯著節(jié)省目標(biāo)主機(jī)的CPU資源。

與前述CC攻擊的處理方法的實(shí)施例相對應(yīng)，本申請還提供了CC攻擊的處理裝置的實(shí)施例。

本申請CC攻擊的處理裝置的實(shí)施例可以應(yīng)用在終端上。裝置實(shí)施例可以通過軟件實(shí)現(xiàn)，也可以通過硬件或者軟硬件結(jié)合的方式實(shí)現(xiàn)。以軟件實(shí)現(xiàn)為例，作為一個(gè)邏輯意義上的裝置，是通過其所在終端的處理器將非易失性存儲器中對應(yīng)的計(jì)算機(jī)程序指令讀取到內(nèi)存中運(yùn)行形成的。從硬件層面而言，如圖5所示，為本申請CC攻擊的處理裝置所在終端的一種硬件結(jié)構(gòu)圖，除了圖5所示的處理器510、網(wǎng)絡(luò)接口520、內(nèi)存530、以及非易失性存儲器540之外，實(shí)施例中裝置所在的終端通常根據(jù)該終端的實(shí)際功能，還可以包括其他硬件，對此不再贅述。

參見圖6，圖6是本申請CC攻擊的處理裝置的一個(gè)實(shí)施例框圖，該裝置可包括：數(shù)據(jù)包發(fā)送模塊610、數(shù)據(jù)包接收模塊620和攻擊處理模塊630。

其中，數(shù)據(jù)包發(fā)送模塊610，用于在接收到CC攻擊端向目標(biāo)主機(jī)發(fā)送的第一SYN數(shù)據(jù)包后，向所述CC攻擊端發(fā)送第二SYN數(shù)據(jù)包。

數(shù)據(jù)包接收模塊620，用于接收所述CC攻擊端回應(yīng)所述第二SYN數(shù)據(jù)包發(fā)送的SYN/ACK數(shù)據(jù)包。

攻擊處理模塊630，用于丟棄并終止響應(yīng)所述CC攻擊端發(fā)送的任何數(shù)據(jù)包，以使所述CC攻擊端向所述目標(biāo)主機(jī)發(fā)送的CC攻擊反彈到所述CC攻擊端。

在一個(gè)可選的實(shí)現(xiàn)方式中，所述裝置還包括(圖6中未示出)：

定時(shí)模塊，用于在接收到所述第一SYN數(shù)據(jù)包時(shí)，啟動(dòng)預(yù)設(shè)定時(shí)器，所述預(yù)設(shè)定時(shí)器的定時(shí)時(shí)長小于或等于所述CC攻擊端重發(fā)第一SYN數(shù)據(jù)包的超時(shí)時(shí)長。

數(shù)據(jù)包發(fā)送模塊610還用于在所述定時(shí)模塊的預(yù)設(shè)定時(shí)器超時(shí)后將所述向所述CC攻擊端發(fā)送第二SYN數(shù)據(jù)包。

在另一個(gè)可選的實(shí)現(xiàn)方式中，所述裝置還包括(圖6中未示出)：

攻擊驗(yàn)證請求模塊，用于在接收到客戶端向所述目標(biāo)主機(jī)發(fā)送的第一SYN數(shù)據(jù)包后，請求CC攻擊驗(yàn)證側(cè)對所述客戶端進(jìn)行CC攻擊驗(yàn)證。

驗(yàn)證結(jié)果接收模塊，用于接收所述CC攻擊端返回的驗(yàn)證結(jié)果。

攻擊側(cè)確定模塊，用于在所述驗(yàn)證結(jié)果表示所述客戶端未通過所述CC攻擊驗(yàn)證時(shí)，確定所述客戶端為CC攻擊端。

數(shù)據(jù)包發(fā)送模塊610還用于在所述攻擊側(cè)確定模塊確定所述客戶端為CC攻擊端后將所述向所述CC攻擊端發(fā)送第二SYN數(shù)據(jù)包。

在另一個(gè)可選的實(shí)現(xiàn)方式中，所述裝置還包括(圖6中未示出)：

截獲請求模塊，用于請求鉤子截獲所述CC攻擊端向所述目標(biāo)主機(jī)發(fā)送的第一SYN數(shù)據(jù)包，所述鉤子安裝在所述目標(biāo)主機(jī)的代理端。

截獲結(jié)果接收模塊，用于接收所述鉤子發(fā)送的所述第一SYN數(shù)據(jù)包。

數(shù)據(jù)包發(fā)送模塊610還用于在所述截獲結(jié)果接收模塊接收所述鉤子發(fā)送的所述第一SYN數(shù)據(jù)包后向所述CC攻擊端發(fā)送第二SYN數(shù)據(jù)包。

參見圖7，圖7是本申請CC攻擊的處理裝置的另一個(gè)實(shí)施例框圖，該裝置可包括：數(shù)據(jù)包發(fā)送模塊710、回應(yīng)數(shù)據(jù)包接收模塊720、攻擊處理子模塊730和清洗處理請求模塊740。

其中，數(shù)據(jù)包發(fā)送模塊710，用于在接收到CC攻擊端向目標(biāo)主機(jī)發(fā)送的第一SYN數(shù)據(jù)包后，向所述CC攻擊端發(fā)送第二SYN數(shù)據(jù)包。

回應(yīng)數(shù)據(jù)包接收模塊720，用于接收所述CC攻擊端發(fā)送的回應(yīng)數(shù)據(jù)包。

攻擊處理子模塊730，用于在所述回應(yīng)數(shù)據(jù)包是SYN/ACK數(shù)據(jù)包時(shí)，終止響應(yīng)所述CC攻擊端發(fā)送的任何數(shù)據(jù)包，以使所述CC攻擊端向所述目標(biāo)主機(jī)發(fā)送的CC攻擊反彈到所述CC攻擊端。

清洗處理請求模塊740，用于在所述回應(yīng)數(shù)據(jù)包是所述CC攻擊端偽造的ACK數(shù)據(jù)包時(shí)，請求流量清洗側(cè)對所述CC攻擊端發(fā)送的數(shù)據(jù)包進(jìn)行清洗處理。

在一個(gè)可選的實(shí)現(xiàn)方式中，所述裝置還包括(圖7中未示出)：

偽造回應(yīng)模塊，用于在所述回應(yīng)數(shù)據(jù)包是所述CC攻擊端偽造的ACK數(shù)據(jù)包時(shí)，向所述CC攻擊端發(fā)送用于回應(yīng)所述第一SYN數(shù)據(jù)包的偽造數(shù)據(jù)包。

上述裝置中各個(gè)模塊的功能和作用的實(shí)現(xiàn)過程具體詳見上述方法中對應(yīng)步驟的實(shí)現(xiàn)過程，在此不再贅述。

對于裝置實(shí)施例而言，由于其基本對應(yīng)于方法實(shí)施例，所以相關(guān)之處參見方法實(shí)施例的部分說明即可。以上所描述的裝置實(shí)施例僅僅是示意性的，其中所述作為分離部件說明的模塊可以是或者也可以不是物理上分開的，作為模塊顯示的部件可以是或者也可以不是物理模塊，即可以位于一個(gè)地方，或者也可以分布到多個(gè)網(wǎng)絡(luò)模塊上?？梢愿鶕?jù)實(shí)際的需要選擇其中的部分或者全部模塊來實(shí)現(xiàn)本申請方案的目的。

本領(lǐng)域普通技術(shù)人員在不付出創(chuàng)造性勞動(dòng)的情況下，即可以理解并實(shí)施。本領(lǐng)域技術(shù)人員在考慮說明書及實(shí)踐這里公開的發(fā)明后，將容易想到本申請的其它實(shí)施方案。本申請旨在涵蓋本申請的任何變型、用途或者適應(yīng)性變化，這些變型、用途或者適應(yīng)性變化遵循本申請的一般性原理并包括本申請未公開的本技術(shù)領(lǐng)域中的公知常識或慣用技術(shù)手段。說明書和實(shí)施例僅被視為示例性的，本申請的真正范圍和精神由下面的權(quán)利要求指出。

應(yīng)當(dāng)理解的是，本申請并不局限于上面已經(jīng)描述并在附圖中示出的精確結(jié)構(gòu)，并且可以在不脫離其范圍進(jìn)行各種修改和改變。本申請的范圍僅由所附的權(quán)利要求來限制。