Chargen反射DDoS攻擊檢測

文 /趙煜 夏震 楊望 丁偉

分布式拒絕服務(wù)(Distributed Denial of Service，DDoS)攻擊是指在傳統(tǒng)的拒絕服務(wù)（Denial of Service，DoS）攻擊基礎(chǔ)上產(chǎn)生的分布式大規(guī)模攻擊方式。

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

Chargen反射DDoS攻擊

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

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

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

圖1 Chargen反射攻擊模式

基于流記錄的檢測方法

檢測算法

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

算法實現(xiàn)

我們將上述Chargen攻擊檢測算法成功地實現(xiàn)在NBOS系統(tǒng)平臺上，完成了對CERNET網(wǎng)內(nèi)參與Chargen攻擊的主機的檢測。

NBOS（Network Behavior Observation System）是CERNET華東北地區(qū)網(wǎng)絡(luò)中心在國家科技支撐計劃課題“新一代可信任互聯(lián)網(wǎng)安全和網(wǎng)絡(luò)服務(wù)”支持下開發(fā)的用于監(jiān)控和管理CERNET網(wǎng)絡(luò)服務(wù)質(zhì)量和網(wǎng)絡(luò)安全狀態(tài)的新型網(wǎng)絡(luò)管理系統(tǒng)，它基于流記錄工作，以不同的時空尺度提供網(wǎng)絡(luò)的基礎(chǔ)運行數(shù)據(jù)。2013年8月，NBOS完成了在CERNET全國38個主節(jié)點的部署，并穩(wěn)定運行到現(xiàn)在。

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

檢測結(jié)果

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

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

圖2 CERNET上的Chargen攻擊檢測結(jié)果

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

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

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

數(shù)據(jù)源缺陷分析

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

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

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

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

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