網絡安全防護之深入淺出談DDoS攻擊防御——攻擊篇

　　1. DDoS攻擊基礎

　　DDoS(Distributed Denial of Service，分布式拒絕服務)攻擊的主要目的是讓指定目標無法提供正常服務，甚至從互聯網上消失，是目前最強大、最難防御的攻擊之一。

　　按照發起的方式，DDoS可以簡單分為三類。

　　第一類以力取勝，海量數據包從互聯網的各個角落蜂擁而來，堵塞IDC入口，讓各種強大的硬件防御系統、快速高效的應急流程無用武之地。這種類型的攻擊典型代表是ICMP Flood和UDP Flood，現在已不常見。

　　第二類以巧取勝，靈動而難以察覺，每隔幾分鐘發一個包甚至只需要一個包，就可以讓豪華配置的服務器不再響應。這類攻擊主要是利用協議或者軟件的漏洞發起，例如Slowloris攻擊、Hash沖突攻擊等，需要特定環境機緣巧合下才能出現。

　　第三類是上述兩種的混合，輕靈渾厚兼而有之，既利用了協議、系統的缺陷，又具備了海量的流量，例如SYN Flood攻擊、DNS Query Flood攻擊，是當前的主流攻擊方式。

　　本文將一一描述這些最常見、最具代表性攻擊方式，并介紹它們的防御方案。

　　1.1. SYN Flood

　　SYN Flood是互聯網上最經典的DDoS攻擊方式之一，最早出現于1999年左右，雅虎是當時最著名的受害者。SYN Flood攻擊利用了TCP三次握手的缺陷，能夠以較小代價使目標服務器無法響應，且難以追查。

　　標準的TCP三次握手過程如下：

　　l 客戶端發送一個包含SYN標志的TCP報文，SYN即同步(Synchronize)，同步報文會指明客戶端使用的端口以及TCP連接的初始序號;

　　l 服務器在收到客戶端的SYN報文后，將返回一個SYN+ACK(即確認Acknowledgement)的報文，表示客戶端的請求被接受，同時TCP初始序號自動加1;

　　l 客戶端也返回一個確認報文ACK給服務器端，同樣TCP序列號被加1。

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

　　SYN Flood正是利用了上文中TCP協議的設定，達到攻擊的目的。攻擊者偽裝大量的IP地址給服務器發送SYN報文，由于偽造的IP地址幾乎不可能存在，也就幾乎沒有設備會給服務器返回任何應答了。因此，服務器將會維持一個龐大的等待列表，不停地重試發送SYN+ACK報文，同時占用著大量的資源無法釋放。更為關鍵的是，被攻擊服務器的SYN_RECV隊列被惡意的數據包占滿，不再接受新的SYN請求，合法用戶無法完成三次握手建立起TCP連接。也就是說，這個服務器被SYN Flood拒絕服務了。

　　對SYN Flood有興趣的可以看看http://www.icylife.net/yunshu/show.php?id=367，這是我2006年寫的代碼，后來做過幾次修改，修改了Bug，并降低了攻擊性，純做測試使用。

　　1.2. DNS Query Flood

　　作為互聯網最基礎、最核心的服務，DNS自然也是DDoS攻擊的重要目標之一。打垮DNS服務能夠間接打垮一家公司的全部業務，或者打垮一個地區的網絡服務。前些時候風頭正盛的黑客組織anonymous也曾經宣布要攻擊全球互聯網的13臺根DNS服務器，不過最終沒有得手。

　　UDP攻擊是最容易發起海量流量的攻擊手段，而且源IP隨機偽造難以追查。但過濾比較容易，因為大多數IP并不提供UDP服務，直接丟棄UDP流量即可。所以現在純粹的UDP流量攻擊比較少見了，取而代之的是UDP協議承載的DNS Query Flood攻擊。簡單地說，越上層協議上發動的DDoS攻擊越難以防御，因為協議越上層，與業務關聯越大，防御系統面臨的情況越復雜。

　　DNS Query Flood就是攻擊者操縱大量傀儡機器，對目標發起海量的域名查詢請求。為了防止基于ACL的過濾，必須提高數據包的隨機性。常用的做法是UDP層隨機偽造源IP地址、隨機偽造源端口等參數。在DNS協議層，隨機偽造查詢ID以及待解析域名。隨機偽造待解析域名除了防止過濾外，還可以降低命中DNS緩存的可能性，盡可能多地消耗DNS服務器的CPU資源。

原文轉自：http://blog.aliyun.com/243?spm=0.0.0.0.OS0war