常見拒絕服務***行爲特徵與防護方法

 本文出自 「王達博客」 博客，轉載請與做者聯繫！

做者已受權本博客轉載

如下內容摘自筆者編著圖書《網管員必讀——網絡安全》一書。

 

1.5.2  常見拒絕服務***行爲特徵與防護方法

拒絕服務***是最多見的一類網絡***類型。在這一***原理下，它又派生了許多種不一樣的***方式。正確瞭解這些不一樣的拒絕***方式，就能夠爲正確、系統地爲本身所在企業部署完善的安全防禦系統。

***檢測的最基本手段是採用模式匹配的方法來發現******行爲。要有效的進行反***，首先必須瞭解***的原理和工做機理，只有這樣才能作到知己知彼，從而有效的防止******行爲的發生。下面咱們針對幾種典型的拒絕服務***原理進行簡要分析，並提出相應的對策。

l          死亡之Ping（Ping of death）***

因爲在早期的階段，路由器對包的最大大小是有限制的，許多操做系統TCP/IP棧規定ICMP包的大小限制在64KB之內。在對ICMP數據包的標題頭進行讀取以後，是根據該標題頭裏包含的信息來爲有效載荷生成緩衝區。當大小超過64KB的ICMP包，就會出現內存分配錯誤，致使TCP/IP堆棧崩潰，從而使接受方計算機宕機。這就是這種「死亡之Ping」***的原理所在。根據這一***原理，***們只需不斷地經過Ping命令向***目標發送超過64KB的數據包，就可以使目標計算機的TCP/IP堆棧崩潰，導致接受方宕機。

防護方法：如今全部的標準TCP/IP協議都已具備對付超過64KB大小數據包的處理能力，而且大多數防火牆可以經過對數據包中的信息和時間間隔分析，自動過濾這些***。Windows 98、Windows NT 4.0（SP3以後 ）、Windows 2000/XP/Server 2003、Linux、Solaris和Mac OS等系統都已具備抵抗通常「Ping of death」拒絕服務***的能力。此外，對防火牆進行配置，阻斷ICMP以及任何未知協議數據包，均可以防止此類***發生。

l          淚滴（teardrop）***

對於一些大的IP數據包，每每須要對其進行拆分傳送，這是爲了迎合鏈路層的MTU（最大傳輸單元）的要求。好比，一個6000字節的IP包，在MTU爲2000的鏈路上傳輸的時候，就須要分紅三個IP包。在IP報頭中有一個偏移字段和一個拆分標誌（MF）。若是MF標誌設置爲1，則表面這個IP包是一個大IP包的片段，其中偏移字段指出了這個片段在整個IP包中的位置。例如，對一個6000字節的IP包進行拆分（MTU爲2000），則三個片段中偏移字段的值依次爲：0，2000，4000。這樣接收端在所有接收完IP數據包後，就能夠根據這些信息從新組裝這幾個分次接收的拆分IP包。在這裏就又一個安全漏洞能夠利用了，就是若是***們在截取IP數據包後，把偏移字段設置成不正確的值，這樣接收端在收後這些分拆的數據包後就不能按數據包中的偏移字段值正確重合這些拆分的數據包，但接收端會不斷償試，這樣就可能導致目標計算朵操做系統因資源耗盡而崩潰。

淚滴***利用修改在TCP/IP堆棧實現中信任IP碎片中的包的標題頭所包含的信息來實現本身的***。IP分段含有指示該分段所包含的是原包的哪一段的信息，某些操做系統（如SP4之前的Windows NT 4.0）的TCP/IP在收到含有重疊偏移的僞造分段時將崩潰，不過新的操做系統已基本上能本身抵禦這種***了。

防護方法：儘量採用最新的操做系統，或者在防火牆上設置分段重組功能，由防火牆先接收到同一原包中的全部拆分數據包，而後完成重組工做，而不是直接轉發。由於防火牆上能夠設置當出現重疊字段時所採起的規則。

l          TCP SYN洪水（TCP SYN Flood）***

TCP/IP棧只能等待有限數量ACK（應答）消息，由於每臺計算機用於建立TCP/IP鏈接的內存緩衝區都是很是有限的。若是這一緩衝區充滿了等待響應的初始信息，則該計算機就會對接下來的鏈接中止響應，直到緩衝區裏的鏈接超時。

TCP SYN洪水***正是利用了這一系統漏洞來實施***的。***者利用僞造的IP地址向目標發出多個鏈接（SYN）請求。目標系統在接收到請求後發送確認信息，並等待回答。因爲***們發送請示的IP地址是僞造的，因此確認信息也不會到達任何計算機，固然也就不會有任何計算機爲此確認信息做出應答了。而在沒有接收到應答以前，目標計算機系統是不會主動放棄的，繼續會在緩衝區中保持相應鏈接信息，一直等待。當達到必定數量的等待鏈接後，緩區部內存資源耗盡，從而開始拒絕接收任何其餘鏈接請求，固然也包括原本屬於正常應用的請求，這就是***們的最終目的。

防護方法：在防火牆上過濾來自同一主機的後續鏈接。不過「SYN洪水***」仍是很是使人擔心的，因爲此類***並不尋求響應，因此沒法從一個簡單高容量的傳輸中鑑別出來。防火牆的具體抵禦TCP SYN洪水***的方法將在本書的第三章最後有詳細介紹。

l          Land***

這類***中的數據包源地址和目標地址是相同的，當操做系統接收到這類數據包時，不知道該如何處理，或者循環發送和接收該數據包，以此來消耗大量的系統資源，從而有可能形成系統崩潰或死機等現象。

防護方法：這類***的檢測方法相對來講比較容易，由於它能夠直接從判斷網絡數據包的源地址和目標地址是否相同得出是否屬於***行爲。反***的方法固然是適當地配置防火牆設備或包過濾路由器的包過濾規則。並對這種***進行審計，記錄事件發生的時間，源主機和目標主機的MAC地址和IP地址，從而能夠有效地分析並跟蹤***者的來源。

l          Smurf ***

這是一種由有趣的卡通人物而得名的拒絕服務***。Smurf***利用多數路由器中具備同時向許多計算機廣播請求的功能。***者僞造一個合法的IP地址，而後由網絡上全部的路由器廣播要求向受***計算機地址作出回答的請求。因爲這些數據包表面上看是來自已知地址的合法請求，所以網絡中的全部系統向這個地址作出回答，最終結果可致使該網絡的全部主機都對此ICMP應答請求做出答覆，致使網絡阻塞，這也就達到了***們追求的目的了。這種Smurf ***比起前面介紹的「Ping of Death」洪水的流量高出一至兩個數量級，更容易***成功。還有些新型的Smurf***，將源地址改成第三方的受害者（再也不採用假裝的IP地址），最終致使第三方雪崩。

防護方法：關閉外部路由器或防火牆的廣播地址特性，並在防火牆上設置規則，丟棄掉ICMP協議類型數據包。

l          Fraggle***

Fraggle***只是對Smurf***做了簡單的修改，使用的是UDP協議應答消息，而再也不是ICMP協議了（由於***們清楚UDP協議更加不易被用戶所有禁止）。同時Fraggle***使用了特定的端口（一般爲7號端口，但也有許多使用其餘端口實施Fraggle***的），***與Smurf***基本相似，再也不贅述。

防護方法：關閉外部路由器或防火牆的廣播地址特性。在防火牆上過濾掉UDP報文，或者屏蔽掉一些常被***們用來進行Fraggle***的端口。

l          電子郵件×××

電子郵件×××是最古老的匿名***之一，經過設置一臺計算機不斷地向同一地址發送大量電子郵件來達到***目的，此類***可以耗盡郵件接受者網絡的帶寬資源。

防護方法：對郵件地址進行過濾規則配置，自動刪除來自同一主機的過量或重複的消息。