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攻擊手段的一種。攻擊者通過向被攻擊主機(jī)發(fā)送大量帶有無用數(shù)據(jù)的UDP報文，使信道資源的利用率下降，從而達(dá)到拒絕服務(wù)的目的。UDP Storm攻擊的實(shí)現(xiàn)手法可分為直接攻擊和反射攻擊。在直接攻擊方式下，攻擊者控制僵尸主機(jī)上通過后門等非法手段安裝的僵尸進(jìn)程向被攻擊服務(wù)器發(fā)送UDP報文；而反射攻擊則是攻擊者通過偽造被攻擊主機(jī)地址向大量有漏洞的主機(jī)發(fā)送某些基于UDP服務(wù)的特殊請求報文，這些請求的回復(fù)會被放大數(shù)倍后發(fā)送到被攻擊主機(jī)從而達(dá)到攻擊目的。反射式DDoS攻擊不需要控制僵尸進(jìn)程，實(shí)現(xiàn)起來更方便且不容易被追蹤，因此它已經(jīng)成了一種最近非?；钴S的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é)議程序、測量連接的帶寬或進(jìn)行QoS的微調(diào)等。它的默認(rèn)端口為19，分為基于TCP和UDP兩種方式，TCP方式下建立連接后，服務(wù)器會不斷傳送任意字符到客戶端，直到客戶端關(guān)閉連接。UDP方式下每當(dāng)服務(wù)器收到客戶端的一個UDP數(shù)據(jù)包后向客戶端返回一個數(shù)據(jù)包，長度為0~512字節(jié)之間隨機(jī)值，數(shù)據(jù)包的負(fù)載可以是任意字符。

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

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

圖1 Chargen反射攻擊模式

基于流記錄的檢測方法

檢測算法

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

算法實(shí)現(xiàn)

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

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ǔ)運(yùn)行數(shù)據(jù)。2013年8月，NBOS完成了在CERNET全國38個主節(jié)點(diǎn)的部署，并穩(wěn)定運(yùn)行到現(xiàn)在。

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

檢測結(jié)果

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

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

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

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

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

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

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

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

圖4給出了一個具體的實(shí)例來說明這個問題。圖中(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)生的。進(jìn)一步分析其中的一個分片報文的內(nèi)容(圖4(b))發(fā)現(xiàn)，若以普通UDP報文結(jié)構(gòu)來解析，在UDP分片報文源端口號位置的數(shù)據(jù)是0x7576，而這個16進(jìn)制數(shù)所對應(yīng)的十進(jìn)制值就是30070。用相似方法對其他分片報文進(jìn)行解析可以獲得另外幾個端口。這個實(shí)驗(yàn)的結(jié)果說明為NBOS提供流記錄的路由器，在流記錄的輸出過程中，把UDP分片報文錯誤地處理成了正常的UDP報文。

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

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

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