Chargen反射DDoS攻擊檢測

文 /趙煜 夏震 楊望 丁偉

分布式拒絕服務(Distributed Denial of Service，DDoS)攻擊是指在傳統的拒絕服務（Denial of Service，DoS）攻擊基礎上產生的分布式大規模攻擊方式。

UDP數據風暴（UDP Storm）是DDoS攻擊手段的一種。攻擊者通過向被攻擊主機發送大量帶有無用數據的UDP報文，使信道資源的利用率下降，從而達到拒絕服務的目的。UDP Storm攻擊的實現手法可分為直接攻擊和反射攻擊。在直接攻擊方式下，攻擊者控制僵尸主機上通過后門等非法手段安裝的僵尸進程向被攻擊服務器發送UDP報文；而反射攻擊則是攻擊者通過偽造被攻擊主機地址向大量有漏洞的主機發送某些基于UDP服務的特殊請求報文，這些請求的回復會被放大數倍后發送到被攻擊主機從而達到攻擊目的。反射式DDoS攻擊不需要控制僵尸進程，實現起來更方便且不容易被追蹤，因此它已經成了一種最近非常活躍的DDoS攻擊手段。一些較常見的被用于反射攻擊的服務有Chargen服務、NTP服務和DNS服務等。

Chargen反射DDoS攻擊

Chargen字符發生器協議（Character Generator Protocol）是一種簡單網絡協議，設計的目的是用來調試TCP或UDP協議程序、測量連接的帶寬或進行QoS的微調等。它的默認端口為19，分為基于TCP和UDP兩種方式，TCP方式下建立連接后，服務器會不斷傳送任意字符到客戶端，直到客戶端關閉連接。UDP方式下每當服務器收到客戶端的一個UDP數據包后向客戶端返回一個數據包，長度為0~512字節之間隨機值，數據包的負載可以是任意字符。

Chargen協議的設計初衷是為了網絡測試，并沒有嚴格的訪問控制和流量控制機制，在UDP模式下任何人都可以向開放該服務的主機請求服務，這種簡單的請求-回復模式便為DDoS攻擊者提供了便利。圖1給出了這個攻擊的示意。圖中攻擊者的地址是IP A，三元組(src=0:S,dst=1:19,proto=UDP )表示A偽造被攻擊對象地址IP 0和端口S，向被利用主機IP1的19端口發送的Chargen請求報文，對應被利用主機放大后的回復報文流向了被攻擊主機IP 0。這個漏洞早在1996年就被發現（CVE-1999-0103），該漏洞被利用最主要的原因是實現過程沒有設計必要的訪問控制。

雖然RFC 864對Chargen協議標準作出了說明，但不同操作系統在實現上并不一致，許多系統的UDP回復報文超過了512字節的字符，這種機制恰恰滿足DDoS攻擊對于流量放大的需求。流量放大程度在不同的操作系統上有所不同，有些可以達到幾十倍。為此我們進行了簡單的實驗，在Linux系統下，對于64字節的無負載UDP Chargen請求，系統回復一個1066字節的UDP應答報文，而在Windows系統下使用同樣的請求，回復的UDP應答報文長度達3259字節，并產生了分片，流量被放大了50倍。

圖1 Chargen反射攻擊模式

基于流記錄的檢測方法

檢測算法

由于Chargen不是常用協議，因此對于這類DDoS可以使用基于端口匹配的方法進行檢測。這種檢測方法適用于部署在網絡邊界，用于對網內主機參與Chargen攻擊的情況進行監測，即只有當攻擊流量穿越網絡邊界，即被攻擊者位于網外時能被檢測到，無法感知攻擊和受害主機都在網絡內部的情況。

算法實現

我們將上述Chargen攻擊檢測算法成功地實現在NBOS系統平臺上，完成了對CERNET網內參與Chargen攻擊的主機的檢測。

NBOS（Network Behavior Observation System）是CERNET華東北地區網絡中心在國家科技支撐計劃課題“新一代可信任互聯網安全和網絡服務”支持下開發的用于監控和管理CERNET網絡服務質量和網絡安全狀態的新型網絡管理系統，它基于流記錄工作，以不同的時空尺度提供網絡的基礎運行數據。2013年8月，NBOS完成了在CERNET全國38個主節點的部署，并穩定運行到現在。

在實現過程中，為了不影響NBOS的正常運行我們只選擇檢測了向國外主機發起Chargen攻擊的流量，因為只需要檢測到一次攻擊行為就可以定位發起Chargen攻擊主機，因此這個方法不會影響對事件主機的查準率。

檢測結果

實際檢測時算法使用的閥值是在一個5分鐘的NBOS時間粒度中，UDP:19平均流量超過1Mbps。圖2給出了檢測結果的實例，從2個角度進行了展示。(a)給出了一個CERNET主節點所管理的網絡在某個時間段參與過Chargen攻擊的主機列表；(b)是某個主節點參與一次特定Chargen攻擊的主機列表。

在CERNET的38個主節點中，NBOS目前可以獲取完整分析源數據（流記錄）的主節點有28個，還有2個主節點只能獲得部分分析源數據。根據上述檢測程序在這些主節點上的運行觀測發現2013年這些主節點的被管網絡中普遍存在著Chargen反射式UDP Storm攻擊，大量校園網主機被用作攻擊主機，到2014年的情況沒有明顯改善，仍有超過500臺主機存在這個漏洞并有持續參與攻擊的行為發生。有關結果在圖3中給出，其中(a)為2014年3月10日~23日這14天中按天統計的全網Chargen攻擊活躍主機情況，(b)為該時間段內CERNET各節點平均主機和事件數的分布情況，圖中節點1-2為獲取部分分析源數據的節點，3-30為28個獲取全部分析源數據的節點。

圖2 CERNET上的Chargen攻擊檢測結果

圖3 (a)2014年3月中旬Chargen攻擊活躍主機數

圖3 (b) CERNET全網2014年Chargen攻擊活躍主機數及事件數分布

圖4 2014年1月12日14:03~14:13時段某攻擊主機通信的流量

數據源缺陷分析

Chargen反射攻擊理論上應該是純凈的19端口的UDP流量，然而在實際的檢測結果中卻發現攻擊流量里伴隨著大量固定高端端口流量，這個現象在所有主節點的檢測結果中普遍存在。為此，我們在江蘇省網邊界與流記錄同一接口位置上采集了面向有Chargen反射行為主機的全部原始報文與同一時間段獲取的流記錄進行對比分析，發現這是由于NBOS所使用的由某個品牌路由器提供的流記錄未能正確處理UDP分片報文導致的，流記錄將Chargen反射中的分片報文作為普通報文進行處理。

圖4給出了一個具體的實例來說明這個問題。圖中(a)是路由器給出的原始流記錄數據，顯示源IP為202.*.200.91的地址使用30070端口與185.*.104.70的30464端口通信，而在同一時間段采集的原始報文序列中沒有發現任何202.*.200.91使用30070端口與185.*.104.70通信的報文，但報文序列中該地址發送過大量的UDP分片報文，這些分片報文是202.*.200.91的19端口回應Chargen請求產生的。進一步分析其中的一個分片報文的內容(圖4(b))發現，若以普通UDP報文結構來解析，在UDP分片報文源端口號位置的數據是0x7576，而這個16進制數所對應的十進制值就是30070。用相似方法對其他分片報文進行解析可以獲得另外幾個端口。這個實驗的結果說明為NBOS提供流記錄的路由器，在流記錄的輸出過程中，把UDP分片報文錯誤地處理成了正常的UDP報文。

由于只有Windows系統的UDP Chargen回復會產生報文分片，因此利用數據源的這個缺陷，我們可以判定參與Chargen攻擊主機的操作系統類型。

本文分析了一個在NBOS平臺上實現的Chargen反射DDoS檢測算法，并用其對CERNET中的Chargen攻擊現象進行了觀測和統計。從實際的觀測結果來看，這類攻擊在CERNET中相對多發。網絡上的服務器對類似Chargen協議管理松懈是這個現象的主要原因。實際上，對這個攻擊的防范還是比較簡單的，只要關閉19端口就可以了。即使這個服務一定要開放，至少應該增加一個訪問控制機制。

本文的另一個貢獻是發現了某品牌路由器的流記錄對UDP報文分片的處理存在缺陷。