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

背景技術(shù)：

通常，一臺客戶端與服務(wù)器在進行網(wǎng)絡(luò)通訊時，需要基于傳輸控制協(xié)議(TCP，Transmission Control Protocol)建立連接。TCP協(xié)議提供可靠的連接服務(wù)，該協(xié)議采用三次握手建立一個連接：

第一次握手：建立連接時，客戶端發(fā)送連接請求數(shù)據(jù)包SYN給服務(wù)器，等待服務(wù)器確認。

第二次握手：服務(wù)器收到連接請求數(shù)據(jù)包SYN后，必須確認客戶的SYN，因此回復(fù)一請求響應(yīng)數(shù)據(jù)包SYN/ACK。

第三次握手：客戶端收到服務(wù)器的SYN/ACK包，向服務(wù)器發(fā)送確認數(shù)據(jù)包ACK(Acknowledgment field significant)。該數(shù)據(jù)包發(fā)送至服務(wù)器完畢，客戶端和服務(wù)器，完成三次握手。之后，客戶端與服務(wù)器才真正建立起連接，并開始傳送數(shù)據(jù)。

SYN洪泛攻擊(SYN Flood，Synchronize sequence numbers Flood)是目前常見針對服務(wù)器的攻擊手段，其原理是：攻擊者發(fā)送大量偽造源IP地址和源端口的SYN包給服務(wù)器，而當(dāng)服務(wù)器返回SYN/ACK后，該攻擊者就不對其進行再確認，則該TCP連接在服務(wù)器側(cè)處于掛起狀態(tài)，以等待攻擊者的ACK。另一方面，服務(wù)器通常收不到ACK后，還會重復(fù)發(fā)送SYN/ACK給攻擊者。這樣更加會浪費服務(wù)器的資源。SYN洪泛攻擊出現(xiàn)時，攻擊者通常會發(fā)送非常大量的TCP連接，由于每一個TCP連接都沒法完成三次握手，因此大量掛起狀態(tài)的TCP連接會嚴重消耗服務(wù)器的CPU和內(nèi)存，導(dǎo)致服務(wù)器無法及時響應(yīng)其他正?？蛻舳说倪B接請求，還有可能造成服務(wù)器死機等嚴重后果。

相關(guān)技術(shù)中的SYN洪泛攻擊的防御方式有首包丟棄或TCP代理等。首包丟棄方式會造成業(yè)務(wù)卡頓，而TCP代理方式需要清洗設(shè)備一直保持在線，在沒有發(fā)生攻擊的時候會導(dǎo)致業(yè)務(wù)卡頓，并且防御效果較差，有可能造成過濾錯誤。

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

為克服相關(guān)技術(shù)中存在的問題，本申請?zhí)峁┝薙YN洪泛攻擊的處理方法及裝置。

根據(jù)本申請實施例的第一方面，提供一種SYN洪泛攻擊的處理方法，所述方法包括：

接收第一連接請求，所述第一連接請求攜帶有客戶端的源地址信息；

根據(jù)所述源地址信息向所述客戶端發(fā)起第二連接請求；

根據(jù)所述客戶端對所述第二連接請求的響應(yīng)結(jié)果，確定對所述第一連接請求的處理操作。

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

請求接收模塊，用于接收第一連接請求，所述第一連接請求攜帶有客戶端的源地址信息；

連接發(fā)起模塊，用于根據(jù)所述源地址信息向所述客戶端發(fā)起第二連接請求；

處理模塊，用于根據(jù)所述客戶端對所述第二連接請求的響應(yīng)結(jié)果，確定對所述第一連接請求的處理操作。

本申請的實施例提供的技術(shù)方案可以包括以下有益效果：

本申請在接收到第一連接請求時，清洗設(shè)備根據(jù)連接請求中攜帶的源地址信息，向該源地址信息對應(yīng)的客戶端發(fā)起第二連接請求，若是攻擊端發(fā)起的連接請求，則源地址可能為虛假IP地址，或者是非真實發(fā)起連接請求的地址，因此對于清洗設(shè)備發(fā)起的連接請求，則無法進行真實的響應(yīng)；若是真實發(fā)起連接的客戶端，對于清洗設(shè)備的連接請求，則可以進行相應(yīng)的響應(yīng)。清洗設(shè)備可以根據(jù)客戶端對所述第二連接請求的響應(yīng)結(jié)果，確定客戶端是否為攻擊端，從而確定對所述第一連接請求的處理操作。本申請能保持TCP連接的首包不丟棄，并且能同時完成回源操作，不需要進行TCP代理，還可以有效地穿透NAT，對于SYN Flood的防御效果較好。

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

附圖說明

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

圖1是相關(guān)技術(shù)中TCP協(xié)議中采用三次握手建立連接的示意圖。

圖2A是本申請根據(jù)一示例性實施例示出的一種SYN洪泛攻擊的處理方法的應(yīng)用場景示意圖。

圖2B是本申請根據(jù)一示例性實施例示出的一種SYN洪泛攻擊的處理方法的流程示意圖。

圖3是本申請根據(jù)一示例性實施例示出的另一種SYN洪泛攻擊的處理方法的流程示意圖。

圖4是本申請SYN洪泛攻擊的處理裝置所在設(shè)備的一種硬件結(jié)構(gòu)圖。

圖5是本申請根據(jù)一示例性實施例示出的一種SYN洪泛攻擊的處理裝置的框圖。

具體實施方式

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

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

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

參考圖1，圖1是相關(guān)技術(shù)中TCP協(xié)議中采用三次握手建立連接的示意圖，其建立連接的過程包括：

第一次握手：建立連接時，客戶端發(fā)送SYN包(SYN＝j(luò))到服務(wù)器，并進入SYN-SEND狀態(tài)，等待服務(wù)器確認。

第二次握手：服務(wù)器收到SYN包，必須確認客戶的SYN(ACK＝j(luò)+1)，同時自己也發(fā)送一個SYN包(SYN＝k)，即SYN/ACK包，此時服務(wù)器進入SYN-RECV狀態(tài)。

第三次握手：客戶端收到服務(wù)器的SYN/ACK包，向服務(wù)器發(fā)送確認包ACK(ACK＝k+1)，此包發(fā)送完畢，客戶端和服務(wù)器進入ESTABLISHED(連接成功)狀態(tài)，完成三次握手。

經(jīng)過這三步，TCP連接就建立完成。TCP協(xié)議為了實現(xiàn)可靠傳輸，在三次握手的過程中設(shè)置了一些異常處理機制。第三次握手中，如果服務(wù)器沒有收到客戶端的最終確認數(shù)據(jù)包ACK，會一直處于SYN_RECV狀態(tài)，也即是將客戶端的IP地址加入等待列表，并重發(fā)第二步的SYN/ACK。重發(fā)一般進行3-5次，大約間隔30秒左右輪詢一次等待列表重試所有客戶端。另一方面，服務(wù)器在發(fā)出了SYN/ACK報文后，會預(yù)分配資源為即將建立的TCP連接儲存信息做準備，這個資源在等待重試期間一直保留。更為重要的是，服務(wù)器資源有限，可以維護的SYN_RECV狀態(tài)超過極限后就不再接受新的SYN報文，也就是拒絕新的TCP連接請求。

SYN Flood正是利用了TCP協(xié)議的設(shè)定，達到攻擊的目的。攻擊者偽裝大量的IP地址給服務(wù)器發(fā)送SYN，由于偽造的IP地址通常為不真實的IP地址或者其他沒有發(fā)起連接請求的設(shè)備，因此服務(wù)器無法接收到響應(yīng)數(shù)據(jù)包。并且，服務(wù)器會維持一個龐大的等待列表，不停的重試發(fā)送SYN/ACK報文，同時占用著大量的資源無法釋放。更關(guān)鍵的是，被攻擊服務(wù)器的SYN_RECV隊列被惡意的數(shù)據(jù)包占滿，不再接受新的SYN請求，合法用戶無法完成三次握手建立起TCP連接，因此造成服務(wù)器發(fā)生拒絕服務(wù)的嚴重后果。

相關(guān)技術(shù)中防御SYN Flood的方式包括有首包丟棄，其處理方式是將任一設(shè)備發(fā)送第一個連接請求數(shù)據(jù)包進行丟棄。該方式雖然可以達到較好的防御效果，但由于需要客戶端重新發(fā)起連接請求，因此會造成業(yè)務(wù)延遲和卡頓，犧牲了業(yè)務(wù)體驗。

相關(guān)技術(shù)中防御SYN Flood的方式還包括有TCP代理，該方式通過設(shè)置于客戶端與服務(wù)器之間的清洗設(shè)備，對來自客戶端的連接請求通過預(yù)先設(shè)定的清洗策略判斷發(fā)起請求客戶端是否為真實客戶端，若為真實客戶端再將連接交互給服務(wù)器。該方式需要清洗設(shè)備一直在線，由于連接請求都需經(jīng)過清洗設(shè)備，因此在沒有發(fā)生攻擊的情況下，該方式會導(dǎo)致連接請求沒有及時到達服務(wù)器，增加請求處理時間。并且，相關(guān)技術(shù)中的清洗策略通常是根據(jù)預(yù)設(shè)的攻擊特征，通過判斷連接請求是否符合特征而確定連接請求是否為攻擊端所發(fā)起，因此很容易造成誤判，導(dǎo)致真實的連接請求被過濾。

而本申請實施例中所提供的方案，能保持TCP連接的首包不丟棄，并且能同時完成回源操作，不需要進行TCP代理，還可以有效地穿透NAT，對于SYN Flood的防御效果較好。接下來對本申請實施例進行詳細說明。

如圖2A所示，是根據(jù)一示例性實施例示出的一種SYN洪泛攻擊的處理方法的應(yīng)用場景圖，圖2A中包括客戶端220、裝設(shè)有客戶端220的終端、服務(wù)器240以及在終端和服務(wù)器240之間進行信號轉(zhuǎn)發(fā)的交換機260，所述終端與服務(wù)器240通過無線網(wǎng)絡(luò)或有線網(wǎng)絡(luò)連接，并基于網(wǎng)絡(luò)連接在兩者之間進行信息傳輸和交互。所述終端可以包括智能手機、個人計算機、筆記本電腦、個人數(shù)字助理、平板電腦等終端設(shè)備中的至少一種?？梢岳斫獾氖?，本實施例的服務(wù)器僅以一臺服務(wù)器設(shè)備為例進行說明，在實際應(yīng)用中，服務(wù)器還可以是服務(wù)器集群或云服務(wù)器等。

其中，服務(wù)器240，運行有向客戶端220提供各種服務(wù)的服務(wù)端，該服務(wù)端可通過網(wǎng)絡(luò)向客戶端120提供各種服務(wù)，如FTP(File Transfer Protocol，文件傳輸協(xié)議)、游戲端口、聊天房間、網(wǎng)頁論壇或購物平臺等。服務(wù)端向客戶端220提供服務(wù)前，需要客戶端220通過其所在終端與服務(wù)器240建立連接，該連接通常是基于TCP協(xié)議建立的TCP連接。

本實施例中還包括有檢測設(shè)備，檢測設(shè)備為獨立設(shè)備，其可以與交換機連接，并拷貝交換機的流量數(shù)據(jù)，以進行是否發(fā)生SYN Flood的判斷，當(dāng)檢測設(shè)備判斷發(fā)生SYN Flood時，檢測設(shè)備可以通知交換機將流量(也即是客戶端發(fā)起的連接請求)引入至清洗設(shè)備。具體的，檢測設(shè)備如何判斷是否發(fā)生SYN Flood的過程，可以參考相關(guān)技術(shù)中的描述，本實施例對此不進行贅述。

本實施例提供的是服務(wù)器處于被SYN Flood攻擊狀態(tài)時進行的處理方法，本實施例的處理方法可以應(yīng)用于圖2A所示的清洗設(shè)備中，如圖2B所示，是本實施例中SYN洪泛攻擊的處理方法的流程圖，包括以下步驟201至203：

在步驟201中，接收第一連接請求，所述第一連接請求攜帶有客戶端的源地址信息。

本實施例中，清洗設(shè)備無需實時在線，可以在確定服務(wù)器處于被SYN Flood攻擊狀態(tài)時上線，并接收交換機所引入的流量，也即接收多臺客戶端發(fā)起的連接請求。在實際應(yīng)用中，連接請求可以具體是連接請求數(shù)據(jù)包SYN，該SYN中攜帶有源IP(Internet Protocol，網(wǎng)絡(luò)之間互連的協(xié)議)地址、源端口地址等源地址信息。

在步驟202中，根據(jù)所述源地址信息向所述客戶端發(fā)起第二連接請求。

有別于相關(guān)技術(shù)中復(fù)雜的處理方式，本申請實施例的方案，在接收到第一連接請求時，清洗設(shè)備根據(jù)連接請求中攜帶的源地址信息，向該源地址信息對應(yīng)的客戶端發(fā)起第二連接請求。該第二連接請求可以是清洗設(shè)備根據(jù)源地址信息和本設(shè)備的地址信息所生成的連接請求數(shù)據(jù)包SYN。

在步驟203中，根據(jù)所述客戶端對所述第二連接請求的響應(yīng)結(jié)果，確定對所述第一連接請求的處理操作。

根據(jù)TCP協(xié)議，設(shè)備在接收到連接請求數(shù)據(jù)包SYN，通常需反饋一響應(yīng)連接數(shù)據(jù)包SYN/ACK。當(dāng)SYN Flood發(fā)生時，若是攻擊端發(fā)起的連接請求，則源地址可能為虛假IP地址，或者是非真實發(fā)起連接請求的地址，因此對于清洗設(shè)備發(fā)起的連接請求，則無法進行真實的響應(yīng)；若是真實的客戶端，對于清洗設(shè)備的連接請求，則可以進行相應(yīng)的響應(yīng)。清洗設(shè)備可以根據(jù)客戶端對所述第二連接請求的響應(yīng)結(jié)果，確定客戶端是否為攻擊端，從而確定對所述第一連接請求的處理操作。

本申請實施例的方案能實現(xiàn)相關(guān)技術(shù)中無法實現(xiàn)的回源處理：

當(dāng)SYN Flood攻擊的時候，清洗設(shè)備根據(jù)第一連接請求中的源地址信息，向該源地址信息對應(yīng)的設(shè)備發(fā)起第二連接請求。清洗設(shè)備通過發(fā)起第二SYN，可以對發(fā)來的第一SYN進行回源，并通過觀察客戶端是否能夠正確響應(yīng)這個回源來判斷發(fā)起連接的客戶端是否是真實的。上述整個過程由清洗設(shè)備自動完成，不需要人工介入，其處理效率高，對虛假SYN的過濾處理效果好。

本申請實施例的方案能有效的穿透NAT(Network Address Translation，網(wǎng)絡(luò)地址轉(zhuǎn)換)：

NAT穿透(NAT Traversal)是回源中首先要解決的問題，以證明客戶端是否真實存在，如果不能穿透客戶端的NAT，則無法實現(xiàn)回源。常見的客戶端的NAT都是普通的家用路由器，以家用路由器為例，家用路由器的NAT策略是Port Restricted Cone NAT，也即路由器打開的端口只接受兩邊(客戶端和服務(wù)器)IP地址和端口地址都吻合的數(shù)據(jù)包穿透。常見的NAT穿透方式都需要兩端的配合，是一個性能耗損非常高的過程，并且一次穿透需要多次數(shù)據(jù)包往來，由于需要雙端配合，相關(guān)技術(shù)中的效率和功能都無法滿足。

本申請中，由于第一SYN攜帶有源地址信息，而清洗設(shè)備基于第一SYN向客戶端發(fā)送了第二SYN。若發(fā)起第一SYN的設(shè)備為真實的客戶端，則清洗設(shè)備發(fā)送的第二SYN可以簡單便捷地實現(xiàn)NAT穿透，從而根據(jù)客戶端的響應(yīng)結(jié)果精準地判斷出客戶端是否為真實客戶端，因此本申請實施例對客戶端的誤判率基本為零，準確率非常高。

由前述分析可知，若是攻擊端發(fā)起的連接請求，對于清洗設(shè)備發(fā)起的連接請求，則無法進行真實的響應(yīng)；若是真實的客戶端，則對于清洗設(shè)備的連接請求，則可以進行相應(yīng)的響應(yīng)。清洗設(shè)備則可以根據(jù)客戶端對所述第二連接請求的響應(yīng)結(jié)果，確定客戶端是否為攻擊端，從而確定對所述第一連接請求的處理操作，對于具體的處理操作，可以根據(jù)實際需求而靈活配置，接下來闡述幾種可選的實施方式。

第一種方式：

所述根據(jù)所述客戶端對所述第二連接請求的響應(yīng)結(jié)果，確定對所述第一連接請求的處理操作，可以包括：

若沒有接收到所述客戶端針對所述第二連接請求所反饋的連接響應(yīng)，則過濾所述第一連接請求。

其中，所述過濾可以是丟棄第一連接請求數(shù)據(jù)包SYN。若是攻擊端發(fā)起的連接請求，則源地址可能為虛假IP地址，或者是非真實發(fā)起連接請求的地址，因此對于清洗設(shè)備發(fā)起的第二連接請求SYN，源地址信息對應(yīng)的客戶端則無法進行真實的響應(yīng)，因此，當(dāng)沒有接收到第二SYN對應(yīng)的SYN/ACK，清洗設(shè)備可以確定第一SYN為攻擊端所發(fā)起，因此可直接丟棄第一SYN，達到防御SYN Flood的目的。

第二種方式：

所述根據(jù)所述客戶端對所述第二連接請求的響應(yīng)結(jié)果，確定對所述第一連接請求的處理操作，可以包括：

若接收到所述客戶端針對所述第二連接請求所反饋的連接響應(yīng)，則基于所述第一連接請求和第二連接請求與所述客戶端建立同步打開連接，并將所建立的連接交付給服務(wù)器。

相關(guān)技術(shù)中的TCP協(xié)議定義了同步打開(simultaneous open)策略。同時打開是指：TCP雙端中，一端打開端口向另一端發(fā)送SYN之后，另一端也同時發(fā)送SYN至同樣的端口。因此，連接可以由任一方或雙方發(fā)起，一旦連接建立，數(shù)據(jù)就可以雙向?qū)Φ鹊亓鲃?，而沒有所謂的主從關(guān)系。這種情況在現(xiàn)實中幾乎不可能發(fā)生，因為連接雙方必須需要知道對方的端口值。

本實施例利用TCP協(xié)議支持同時打開的機制，清洗設(shè)備模擬了一個對等的SYN連接，從而實現(xiàn)了回源目的，客戶端與清洗設(shè)備可以認為雙方是完全對稱的。因為在回源的時候，清洗設(shè)備所回復(fù)的SYN/ACK與客戶端發(fā)送的SYN/ACK報文屬于同一個TCP連接，并且這個連接是客戶端發(fā)起的，所以這種回源可以穿過任何一種嚴格的NAT。

本申請實施例中，對于真實發(fā)起第一SYN的客戶端，若清洗設(shè)備向其發(fā)起第二SYN，則該客戶端會反饋針對第二SYN的SYN/ACK。通過客戶端的反饋，清洗設(shè)備可確定第一SYN為真實客戶端所發(fā)起，因此清洗設(shè)備可以與客戶端建立同步打開連接。

在一個可選的實現(xiàn)方式中，所述基于所述第一連接請求和第二連接請求與所述客戶端建立同步打開連接，并將所建立的連接交付給服務(wù)器，包括：

接收客戶端針對第二連接請求反饋的第二請求響應(yīng)數(shù)據(jù)包，并向客戶端反饋針對所述第一連接請求的第一請求響應(yīng)數(shù)據(jù)包。

接收客戶端針對所述第一請求響應(yīng)數(shù)據(jù)包反饋的確認數(shù)據(jù)包。

將所建立的連接交互給服務(wù)器后，向客戶端發(fā)送基于所述第一請求響應(yīng)數(shù)據(jù)包的確認數(shù)據(jù)包。

具體的，上述過程可以參考圖3，圖3是本申請根據(jù)一示例性實施例示出的另一種SYN洪泛攻擊的處理方法的示意圖，圖3中包括客戶端、清洗設(shè)備和服務(wù)器，包括如下步驟301至307：

在步驟301中，客戶端發(fā)送第一SYN。其中該第一SYN引入至清洗設(shè)備。

在步驟302中，清洗設(shè)備向客戶端發(fā)送第二SYN。

在步驟303中，客戶端向清洗設(shè)備反饋針對第二SYN的第二SYN/ACK。

在步驟304中，清洗設(shè)備向客戶端反饋針對第一SYN的第一SYN/ACK。

在步驟305中，客戶端向清洗設(shè)備反饋針對第一SYN/ACK的ACK。

在步驟306中，清洗設(shè)備將所建立的連接交付給服務(wù)器。

在步驟307中，清洗設(shè)備在連接交付完成后，向客戶端反饋針對第二SYN/ACK的ACK。

本實施例還可以控制連接交付(即將所建立的TCP連接轉(zhuǎn)移給服務(wù)器的過程)的時機。相關(guān)技術(shù)中的TCP代理和TCP緩存的方式，由于與客戶端建立了連接，則客戶端就會發(fā)來數(shù)據(jù)。此時，清洗設(shè)備可能正在進行連接交付，但由于數(shù)據(jù)已經(jīng)發(fā)送過來，清洗設(shè)備還必須進行數(shù)據(jù)轉(zhuǎn)換及緩存?；蛘?，也有采用零窗口建立連接的方式，但使用零窗口可能導(dǎo)致客戶端建立很長時間仍不能發(fā)送數(shù)據(jù)。

而本申請可以靈活地控制客戶端發(fā)送數(shù)據(jù)的時機，清洗設(shè)備可以在連接交付完成后，再執(zhí)行向客戶端回復(fù)針對第二SYN/ACK的ACK的步驟，因此可以使客戶端的數(shù)據(jù)直接發(fā)送給服務(wù)器，清洗設(shè)備并不需要進行數(shù)據(jù)處理。

第三種方式：

所述根據(jù)所述客戶端對所述第二連接請求的響應(yīng)結(jié)果，確定對所述第一連接請求的處理操作，可以包括：

若接收到所述客戶端在針對第二連接請求所發(fā)送的第三連接請求，則將所述第一連接請求和/或第三連接請求轉(zhuǎn)發(fā)給服務(wù)器。

對于部分不支持同步打開策略的設(shè)備，若是真實發(fā)起連接的客戶端，由于清洗設(shè)備在接收到第一連接請求時，沒有回復(fù)SYN/ACK，而是回復(fù)第二連接請求，客戶端則會重新發(fā)起連接請求，因此清洗設(shè)備可以將連接請求轉(zhuǎn)發(fā)給服務(wù)器，使服務(wù)器與客戶端建立連接。若是真實的客戶端，則客戶端兩次發(fā)起的第一連接請求和第三連接請求可以認為是相同的，因此，清洗設(shè)備所轉(zhuǎn)發(fā)的連接請求可以是第一連接請求或第三連接請求，或者還可以是同時將上述兩個連接請求同時轉(zhuǎn)發(fā)。

與前述SYN洪泛攻擊的處理方法的實施例相對應(yīng)，本申請還提供了SYN洪泛攻擊的處理裝置及其所應(yīng)用的設(shè)備的實施例。

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

如圖5所示，圖5是本申請根據(jù)一示例性實施例示出的一種SYN洪泛攻擊的處理裝置的框圖，所述裝置包括：

請求接收模塊51，用于接收第一連接請求，所述第一連接請求攜帶有客戶端的源地址信息。

連接發(fā)起模塊52，用于根據(jù)所述源地址信息向所述客戶端發(fā)起第二連接請求。

處理模塊53，用于根據(jù)所述客戶端對所述第二連接請求的響應(yīng)結(jié)果，確定對所述第一連接請求的處理操作。

在一個可選的實現(xiàn)方式中，所述處理模塊53，可以包括(圖5未示出)：

第一處理子模塊，用于若接收到所述客戶端針對所述第二連接請求所反饋的連接響應(yīng)，則基于所述第一連接請求和第二連接請求與所述客戶端建立同步打開連接，并將所建立的連接交付給服務(wù)器。

在一個可選的實現(xiàn)方式中，所述第一處理子模塊，包括(圖5未示出)：

接收客戶端針對第二連接請求反饋的第二請求響應(yīng)數(shù)據(jù)包，并向客戶端反饋針對所述第一連接請求的第一請求響應(yīng)數(shù)據(jù)包；接收客戶端針對所述第一請求響應(yīng)數(shù)據(jù)包反饋的確認數(shù)據(jù)包；將所建立的連接交互給服務(wù)器，向客戶端發(fā)送針對所述第一請求響應(yīng)數(shù)據(jù)包的確認數(shù)據(jù)包。

在一個可選的實現(xiàn)方式中，所述處理模塊53，包括(圖5未示出)：

第二處理子模塊，用于若沒有接收到所述客戶端針對所述第二連接請求所反饋的連接響應(yīng)，則過濾所述第一連接請求。

在一個可選的實現(xiàn)方式中，所述處理模塊53，包括(圖5未示出)：

第三處理子模塊，用于若接收到所述客戶端在針對第二連接請求所發(fā)送的第三連接請求，則將所述第一連接請求轉(zhuǎn)發(fā)給服務(wù)器。

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

對于裝置實施例而言，由于其基本對應(yīng)于方法實施例，所以相關(guān)之處參見方法實施例的部分說明即可。以上所描述的裝置實施例僅僅是示意性的，其中所述作為分離部件說明的模塊可以是或者也可以不是物理上分開的，作為模塊顯示的部件可以是或者也可以不是物理模塊，即可以位于一個地方，或者也可以分布到多個網(wǎng)絡(luò)模塊上。可以根據(jù)實際的需要選擇其中的部分或者全部模塊來實現(xiàn)本申請方案的目的。本領(lǐng)域普通技術(shù)人員在不付出創(chuàng)造性勞動的情況下，即可以理解并實施。

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

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

以上所述僅為本申請的較佳實施例而已，并不用以限制本申請，凡在本申請的精神和原則之內(nèi)，所做的任何修改、等同替換、改進等，均應(yīng)包含在本申請保護的范圍之內(nèi)。