新人開車——應用層拒絕服務攻擊

1、DDOS介紹

　　DDOS又稱爲分佈式拒絕服務，全稱是Distributed Denial of Service。DDOS本是利用合理的請求形成資源過載，致使服務不可用。

　　分佈式拒絕服務攻擊，將正常的請求放大了若干倍，經過若干個網絡節點同時發起攻擊，以達成規模效應。這些網絡節點每每是黑客們所控制的「肉雞」，數量達到必定規模後，就造成了一個僵屍網絡。大量的僵屍網絡，甚至達到了數萬、數十萬臺的規模。如此規模的僵屍網絡發起的DDOS攻擊，幾乎是不可能阻擋的。

　　常見的DDOS攻擊有SYN flood、UDP flood、ICMP flood等。其中SYN flood 是一種最爲經典的DDOS攻擊，其發如今1996年，但至今仍然保持這很是強大的生命力。SYN flood 如此猖獗是由於它利用了TCP協議設計中的缺陷，而tcp/ip協議是整個互聯網的基礎，牽一髮而動全身，現在想要修復這樣的缺陷幾乎成爲不可能的事情。

　　想要理解DDOS還要知道TCP三次握手過程：

　　1）、客戶端向服務器端發送一個syn包，包含客戶端使用的端口號和初始序列號x;

　　2)、服務器端收到客戶端發送來的syn包後，向客戶端發送一個syn加ack都置位的TCP報文，包含確認號x+1和服務器端的初始序列號y；

　　3）、客戶端收到服務器端返回的syn+ack保溫後，向服務器端返回一個確認號爲y+一、序號爲X+1的ACK報文，一個標準的TCP鏈接完成。

　　而SYN FLOOD在攻擊時，首先僞造大量的源ip地址，分別向服務器端發送大量的SYN包，此時服務器端會返回syn/ack包，由於源地址路是僞造的，因此僞造的ip並不會應答，服務器端並無收到僞造ip的迴應，會重試3-5次而且等待一個syn time，若是超時則丟棄這個鏈接。攻擊者大量發送這種僞造源地址的syn請求，服務器端將會小號很是多的資源（cpu和內存）來處理這些半鏈接，同時還要不斷的對這些ip進行syn/ack重試。最後的結果是服務器無暇理睬正常的請求，致使拒絕服務攻擊。

　　對抗syn flood的主要措施有syn cookie、syn proxy、safereset算法。syn cookie的主要思想是爲每個ip地址分配一個"cookie",並統計每個ip地址訪問頻率。若是在短期內收到大量的來自同一個ip地址的數據包，則認爲收到攻擊，以後來自這個ip地址的包將被丟棄。

　　對抗DDOS的網絡設備能夠串聯或者並聯在網絡出口處。當攻擊流量超過了網絡設備，甚至帶寬的最大負荷時，網絡仍將癱瘓。

　　

2、應用層DDOS

　　應用層DDOS,不一樣於網絡層，因爲發生在應用層，所以TCP三次握手已經完成，鏈接已經創建，因此發起攻擊的ip地址也都是真實的。

　　那麼應用層DDOS究竟是怎麼回事呢？這就要從「cc攻擊」提及了。

2.1  CC攻擊

　　CC攻擊的原理很是簡單，就是對一些消耗資源較大的應用頁面不斷髮起正常的請求，以達到消耗服務端資源的目的。

　　應用層DDOS攻擊還能夠經過如下方式完成:   在黑客入侵了一個流量很大的網站後，經過篡改頁面，將巨大的用戶流量分流到目標網站。

　　好比，在大流量網站siteA上插入一段代碼：

　　　　<iframe src="http://target" height=0 width=0> </iframe>

　　那麼全部訪問該頁面的siteA用戶，都將對此target發起一次http get請求，這可能直接致使target拒絕服務。

　　應用層DDOS攻擊是針對服務器性能的一種攻擊，那麼許多優化服務器性能的方法，都或多或少地能緩解此種攻擊。好比將使用頻率高的數據放在memcache（分佈式的告訴緩存系統）中，相對於查詢數據庫所消耗的資源來講，查詢memcache所消耗的資源能夠忽略不計。可是不少性能優化的方案並不是是爲了對抗應用層DDOS攻擊而設計的，所以攻擊者想要找到一個資源消耗大的頁面並不困難。好比當memcache查詢沒有命中時，服務器必然會查詢數據庫，從而增大服務器資源的消耗，攻擊者只須要找到這樣的頁面便可。同時攻擊者處理觸發「讀」數據操做外，還能夠觸發「寫」數據操做，「寫」數據操做的行爲通常都會致使服務器操做數據庫。

2.2   防護措施

　　一、最多見的針對應用層DDOS攻擊的防護措施，是在應用層中針對每一個「客戶端」作一個請求頻率的限制。思路很簡單，經過IP地址與Cookie定位一個客戶端，若是客戶端的請求在必定時間內過於頻繁，則對於以後來自該客戶端的全部請求都重定位到一個出錯頁面。

　　然而這種防護方式並不完美，由於它在客戶端的判斷依據上並非永遠可靠的。若是IP地址和Cookie同時都發生了變化，那麼久沒法再定位到同一個客戶端了。那麼如何讓IP地址發生變化呢？使用「代理服務器」是一個常見的作法。在實際的攻擊中，大量使用代理服務器或傀儡機來隱藏攻擊者的真實ip地址，已經成爲一種成熟的攻擊模式。攻擊者使用這些方法可不斷地變化Ip地址，就能夠繞過服務器對單個ip地址請求頻率的限制了

　　應用層DDOS攻擊並不是是一個沒法解決的難題，通常來講，咱們能夠從如下幾個方面着手。

　　　　（1）應用代碼要作好性能優化。合理地使用memcache就是一個很好的優化方案。

　　    　（2）在網絡架構上作好優化。善於利用負載均衡分流，避免用戶流量集中在單臺服務器上。同時能夠充分利用好CDN和鏡像站點的分流做用，緩解主站壓力。

　　　　（3）實現一些對抗手段，好比限制每一個IP地址的請求頻率。

　　二、驗證碼

　　驗證碼是互聯網中經常使用的技術之一，它的英文簡稱是CAPTCHA（全自動區分計算機和人類的圖靈測試）。在不少時候，若是能夠忽略對用戶體驗的影響，那麼引入驗證碼這一手段可以有效地阻止自動化的重放行爲。驗證碼發明的初衷是爲了識別人與機器。

　　三、一種比較可靠的方法是讓客戶端解析一段Javascript,並給很出正確的運行結果。。可是這種方法並非萬能的，有的自動化腳本是內嵌在瀏覽器中的「內掛」，就沒法檢測出來了。

　　四、除了人機識別外，還能夠在Web  Server這一層作些防護，其好處是請求還沒有到達後端的應用程序裏，所以能夠起到一個保護做用。Yahoo爲咱們提供了一個解決思路。由於發起應用層DDOS攻擊的IP地址都是真實的，因此在實際狀況中，攻擊者的IP地址其實也不可能無限制增加。假設攻擊者有1000個IP地址發起攻擊，若果請求了10000次，則平均每一個IP地址請求同一頁面達到10次，攻擊若是持續下去，單個IP地址的請求也將變多，但不管如何變化，都是在這1000個IP地址的範圍內作輪詢。爲此Yahoo實現了一套算法，根據IP地址和Cookie等信息，能夠計算客戶端的請求頻率並進行攔截。Yahoo設計的這套系統也是爲WEB server 開發的一個模塊，但在總體架構上會有一臺master服務器集中計算全部ip地址的請求頻率，並同步策略到每臺web server上。

 

3、資源耗盡攻擊

　　除了cc攻擊外，攻擊者還可能利用一些web server 的漏洞或設計缺陷，直接形成拒絕服務。下面看幾個典型的例子，並由此分析此類（分佈式）拒絕服務攻擊的本質。

3.1 slowloris攻擊

　　slowloris是在09年由著名的web安全專家RSnake提出的一種攻擊方法，其原理是以極低的速度往服務器發送HTTP請求。因爲web server 對於併發的鏈接數都有必定的上限，所以如果惡意地佔用住這些鏈接不釋放，那麼web server的全部鏈接都將被惡意鏈接佔用，從而沒法接受新的請求，致使拒絕服務攻擊。

　　要保持住這個鏈接，RSnake構造了一個畸形的HTTP請求，準備地說，是一個不完整的HTTP請求。以下：

　　　　GET / HTTP/1.1  \r\n

　　　　Host : host \r\n

　　　　.........

　　在正常的HTTP包頭中，是以兩個CLRF表示HTTP Headers部分結束。如：

　　　　content-length: 42 \r\n\r\n

　　因爲web server只收到了一個\r\n,所以將認爲HTTP Headers部分沒有結束，並保持此鏈接不釋放，繼續等待完整的請求。此時客戶端再發送任意HTTP頭，保持住鏈接便可。當構造多個鏈接後，服務器的鏈接數很快就會達到上限。

　　此類拒絕服務攻擊的本質，其實是對有限資源的無限濫用。

　　「有限」的資源是指web server 的鏈接數，這是一個有上限的值，好比apache中這個值由MaxClients定義。若是惡意客戶端能夠無限制地將鏈接數佔滿，就完成了對有限資源的惡意消耗，致使拒絕服務。

3.2   HTTP POST DOS

　　其原理是在發送HTTP POST包時，指定一個很是大的Content-Length值，而後以很低的速度發包，好比10-100s發一個字節，保持住這個鏈接不斷開。這樣當客戶端鏈接數多了之後，佔用住了web server 的全部可用鏈接，從而致使DOS。

　　由此可知，這種攻擊的本質也是針對Apache的MaxClients限制的。

　　要解決此類問題，可使用web應用防火牆，或者一個定製的web  server安全模塊。

　　由以上兩個例子咱們很天然地聯想到，凡是資源有「限制」的地方，均可能發生資源濫用，從而致使拒絕服務，也就是 一種「資源耗盡型攻擊」

　　出於可用性和物理條件的限制，內存、進程數、存儲空間等資源都不可能無限制地增加，所以若是未對不可信任的資源使用者進行配額的限制，就有可能形成拒絕服務。內存泄漏是程序員常常須要解決的一種BUG，而在安全領域中，內存泄漏則被認爲是一種可以形成拒絕服務攻擊的方式。

 

3.3 server limit dos　　

　　Cookie也能形成一種拒絕服務。

　　web server 對http包頭都有長度限制，以Apache舉例，默認是8192字節。也就是說apache能接受的最大HTTP包頭大小爲8192字節。若是客戶端發送的HTTP包頭超過這個大小，服務器就會返回一個4xx錯誤。

　　假設攻擊者經過XSS攻擊，惡意地往客戶端寫入一個超長的Cookie,則該客戶端再清空Cookie以前，將沒法再訪問該Cookie所在域的任何頁面。這是由於Cookie也是放在http包頭裏發送的，而web server 默認會認爲這是一個超長的非正常請求，從而致使「客戶端」的拒絕服務。

　　要解決此問題，須要調整Apache配置參數LimitRequestFieldSize,這個參數設置爲0時，對HTTP包頭的大小沒有限制。

 

4、一個正則引起的血案：ReDOS

　　與前面提到的資源耗盡攻擊略有不一樣的是，ReDos是一種代碼實現上的缺陷。正則表達式是一個狀態機，每一個狀態和輸入符號均可能有許多不一樣的下一個狀態。正則解析引擎將遍歷全部可能的路徑直到最後。因爲每一個狀態都有若干個「下一個狀態」，所以決策算法將逐個嘗試每一個「下一個狀態」，所以決策算法將逐個嘗試每一個「下一個狀態」，直到找到一個匹配的。

　　好比這個正則表達式：

　　　　^(a+)+$

　　當輸入 aaaaX時，它有16種可能的路徑，引擎很快能遍歷完。可是當輸入aaaaaaaaaaaaaaX時，就會變成幾千條可能的路徑，此後每增長一個「a」,路徑的數量都會翻倍。

　　這極大地增長了正則引擎解析數據時的消耗。當用戶惡意構造輸入時，這些有缺陷的正則表達式就會消耗大量的系統資源（好比CPU和內存），從而致使整臺服務器性能降低，表現的結果是系統速度很慢，有進程或服務失去響應，與拒絕服務的後果是同樣的。

　　在檢查應用安全時，必定不能忽略ReDos可能形成的影響。在本節中提到的幾種存在缺陷的正則表達式和測試用例，能夠加入安全評估的流程中。