SYN洪泛攻擊的處理方法及裝置與流程

2023-07-28 04:24:51 4

本申請涉及網絡通信技術領域，尤其涉及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洪泛攻擊的處理方法中對應步驟的實現過程，在此不再贅述。

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

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

應當理解的是，本申請並不局限於上面已經描述並在附圖中示出的精確結構，並且可以在不脫離其範圍進行各種修改和改變。本申請的範圍僅由所附的權利要求來限制。

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