反射放大型DDoS 攻擊的預(yù)防策略研究

郝 帥，白翼銘，李致成，包正晶

(華北計算機(jī)系統(tǒng)工程研究所，北京102200)

0 引言

據(jù)CERNET 2014 年10 月的月報統(tǒng)計，其38 個主節(jié)點(diǎn)中有超過一半檢測到來自國內(nèi)次數(shù)超過2 200次、總流量超過16 TB 的NTP 反射放大攻擊[1]；2016年10 月美國Dyn 公司的DNS 服務(wù)器遭受DNS 反射放大攻擊與SYN 洪水攻擊，導(dǎo)致美國大范圍斷網(wǎng)；2017 年11 月13 日到2017 年11 月15 日 期 間，ZoomEye 網(wǎng)絡(luò)空間探測引擎探測到一個活動頻繁的攻擊——CLDAP DDoS 反射放大攻擊，隨后對DDoS反射放大攻擊進(jìn)行了第三輪的探測，發(fā)布出《DDoS反射放大攻擊全球探測分析-第三版》；2018 年3月CCERT 公布Memcached 反射放大攻擊流量占比有大幅增長[2]。

ZoomEye 的四次網(wǎng)絡(luò)空間探測結(jié)果顯示全球依舊存在著大量會被利用來反射放大的主機(jī)。例如全球2 千萬臺UDP 53 端口相關(guān)的主機(jī)，約18.1%存在著放大倍率，1 千萬臺UDP 161 端口相關(guān)的主機(jī)，約14.36%(167 萬臺)存在著放大倍率，其中放大倍數(shù)在10 倍以上的主機(jī)占存在放大倍率總數(shù)的36.84%，尤其值得注意的是我國所占主機(jī)量上升到了第二位[3]。

顯然，成本較低、放大效果顯著、追溯困難等特點(diǎn)使得反射放大型DDoS 備受不法分子青睞[4]。 為了提高網(wǎng)絡(luò)中IP 資源的防御能力，本文將結(jié)合反射放大型DDoS 攻擊原理對預(yù)防策略給出一個詳細(xì)的分析。

1 反射放大型DDoS

反射放大型DDoS 利用的是網(wǎng)絡(luò)中存在配置漏洞的設(shè)備或服務(wù)器，向其發(fā)送特定構(gòu)造的請求數(shù)據(jù)包，將數(shù)據(jù)包的源IP 替換為受害者IP，使得服務(wù)端將應(yīng)答數(shù)據(jù)包返回給受害者主機(jī)，從而消耗受害者的網(wǎng)絡(luò)資源[5]，原理見圖1。由于通過中間設(shè)備或服務(wù)器發(fā)送正常請求使其向受害者回包，因此更加難被追蹤溯源。 結(jié)合反射型DDoS 與僵尸網(wǎng)絡(luò)可以同時達(dá)到產(chǎn)生大量應(yīng)答數(shù)據(jù)包和隱藏攻擊者的效果，使攻擊效率和隱蔽性大幅提升。

圖1 僵尸網(wǎng)絡(luò)+反射放大型DDoS 原理圖

2 基于各協(xié)議的反射放大型DDoS 原理及其仿真研究

反射放大型DDoS 分為反射和放大兩部分，反射指攻擊者偽造被攻擊目標(biāo)的IP 地址向互聯(lián)網(wǎng)上某些有開放特殊服務(wù)的服務(wù)器發(fā)送構(gòu)造的請求報文，服務(wù)器將應(yīng)答報文回復(fù)到被攻擊目標(biāo)；放大是指服務(wù)器應(yīng)答報文數(shù)倍于攻擊者發(fā)送的請求報文，對受害者間接形成DDoS 攻擊[6]。

本文將介紹基于Memcached、DNS、NTP、SNMP、SSDP、CLDAP 六種協(xié)議的反射放大型DDoS 的漏洞所在、payload 構(gòu)造原理及預(yù)防點(diǎn)，利用Python 的交互式數(shù)據(jù)包操作程序增加UDP 數(shù)據(jù)報文頭和IP 數(shù)據(jù)報文頭，添加目的端口、源IP 和目的IP 地址等參數(shù)，構(gòu)造出完整的請求數(shù)據(jù)包。 仿真攻擊關(guān)鍵步驟見圖2，收到該數(shù)據(jù)包的服務(wù)器就會將應(yīng)答數(shù)據(jù)包回復(fù)給受害者， 從而模擬出多種協(xié)議的反射放大型DDoS。

圖2 仿真攻擊實(shí)驗(yàn)關(guān)鍵步驟圖

2.1 Memcached

2.1.1 漏洞分析

Memcached 是一種高性能的開源分布式key-value(鍵值對) 內(nèi)存對象緩存系統(tǒng)，使用者通過set 或add 命令向Memcached 服務(wù)器中添加要存儲的鍵值對， 通過get 或gets 命令向服務(wù)器發(fā)送key 以獲取服務(wù)器端存儲的value。 key 值與value 值相差多倍，因此set/get 功能可被利用來構(gòu)造大流量的Memcached 反射放大型DDoS[7]。 此外，Memcached 服務(wù)器可以接受stats 請求以返回服務(wù)器的當(dāng)前狀態(tài)，stats 信息同樣遠(yuǎn)大于請求數(shù)據(jù)。

2.1.2 構(gòu)造payload

被利用的Memcached 服務(wù)器存在UDP 的11211端口開放、未設(shè)置訪問控制規(guī)則、使用root 權(quán)限運(yùn)行等漏洞，如：Memcached-p 11211-U 11211-u root(根用戶名)，并且未啟用認(rèn)證功能。 這類Memcached服務(wù)器允許任何用戶存入或請求該服務(wù)器中已存在的鍵值對，選擇合適的key-value，即可構(gòu)造對應(yīng)的payload。

本文仿真實(shí)驗(yàn)中存儲鍵值對時使用的set 命令設(shè)置相應(yīng)值格式如下：

set key flags exptime bytes

value

其中，flags 表示可以包括鍵值對的整型參數(shù)，客戶機(jī)使用它存儲關(guān)于鍵值對的額外信息；exptime 表示此鍵值對在服務(wù)器中保存的時間(0 表示永久保存)；bytes 表示value 的大小。 觸發(fā)Memcached 回應(yīng)的請求報文最小為15 B，包含為8 B+3 B(get)+1 B(空格)+最小為1 B(鍵的名稱)+2 B( )。

構(gòu)造get 查詢請求或stats 查詢請求命令如下：

"x00x00x00x00x00x01x00x00get"+key+" "

通過分析，可見Memcached 服務(wù)器的漏洞預(yù)防點(diǎn)是可選擇的傳輸層協(xié)議以及訪問控制規(guī)則、運(yùn)行權(quán)限等。

2.2 DNS

2.2.1 漏洞分析

DNS(Domain Name System)協(xié)議為互聯(lián)網(wǎng)提供域名和IP 地址對應(yīng)的相互映射查詢服務(wù)，理論上ISP的DNS 服務(wù)器只會響應(yīng)來自它自己客戶IP 的DNS Query 響應(yīng)，然而由于互聯(lián)網(wǎng)中大量DNS 服務(wù)默認(rèn)配置缺失，導(dǎo)致其會響應(yīng)任何DNS Query 請求。

這類DNS 服務(wù)器接收到一個域名查詢請求時，如果該服務(wù)器未緩存對應(yīng)域名，其會向更高一級的DNS 服務(wù)器請求查詢域名對應(yīng)的IP 信息，當(dāng)請求一個復(fù)雜的或不存在的域名時，DNS 服務(wù)器會經(jīng)過多層迭代查詢，這樣不論是否查詢到結(jié)果，都會產(chǎn)生一個數(shù)倍于請求包的DNS 應(yīng)答包。 同時EDNS(Extension Mechanisms for DNS)支持請求更多字段內(nèi)容(如A 記錄、CNAME 記錄、TXT 等)，使得應(yīng)答包最大可至4 096 B[8]。

2.2.2 構(gòu)造payload

被利用的DNS 服務(wù)器在配置中未關(guān)閉迭代查詢，并且注釋掉listen-address。 DNS 請求數(shù)據(jù)包qd字段包含域名信息qname， 選定特定的域名或者偽造虛假域名進(jìn)行查詢請求的DNS 數(shù)據(jù)包使得DNS服務(wù)器可以進(jìn)行更多次數(shù)的遞歸請求，以更大程度地增大應(yīng)答包。 由于DNS 單個應(yīng)答包超過512 B 會被截斷，因此改用TCP 協(xié)議進(jìn)行請求傳輸，本文仿真實(shí)驗(yàn)中進(jìn)行如下設(shè)計：

將arcount 的值改為1，并在請求包頭添加dns.ar=DNSRROPT(type=′OPT′，rclass=4096)形成EDNS 請求包，此時應(yīng)答包最大可達(dá)到rclass 值的大小。 EDNS應(yīng)答包中additional records 額外增加type 為OPT 字段，同時可以修改qtype 的值，如將其改為255，使其查詢所有內(nèi)容并返回。

通過分析，可見DNS 服務(wù)器的漏洞預(yù)防點(diǎn)是查詢請求中域名的選擇、是否開放EDNS 服務(wù)以及可響應(yīng)的qtype。

2.3 NTP

2.3.1 漏洞分析

NTP(Network Time Protocol)協(xié)議使計算機(jī)與時鐘源進(jìn)行同步化并且提供高精準(zhǔn)度的時間校正，各客戶端由從時間服務(wù)器經(jīng)主服務(wù)器獲得時間同步。 在CVE-2013-5211 漏洞中指出，NTPD4.2.7p26 之前的版本，對于特定配置信息的NTP 服務(wù)器，存在monlist命令請求服務(wù)，會去響應(yīng)NTP 中的mode7“monlist”請求，返回進(jìn)行時間同步的最近多個客戶端的IP 地址及其他信息[9]，遠(yuǎn)大于請求數(shù)據(jù)包的應(yīng)答包會被利用來構(gòu)造大流量NTP 反射放大型DDoS。

2.3.2 構(gòu)造payload

NTP 協(xié)議基于UDP 協(xié)議的123 端口進(jìn)行通信，本文仿真實(shí)驗(yàn)中進(jìn)行如下設(shè)計：

對可利用的NTP 服務(wù)器構(gòu)造請求數(shù)據(jù)包模擬受害者發(fā)送monlist 請求。NTP 數(shù)據(jù)包的flags 字段共有四條信息，分別如下：

信息一：第1 個bit 表示請求(0)還是應(yīng)答(1)；

信息二：第2 個bit 表示是否閏秒，通過這個bit對時間進(jìn)行一次校正；

信息三：第3、4 個bit 合在一起表示版本；

信息四：第5～7 個bit 合在一起表示模式：0 表示未定義，1 表示主動對等體模式，2 表示被動對等體模式，3 表示客戶模式，4 表示服務(wù)器模式，5 表示廣播模式或組播模式，6 表示此報文為NTP 控制報文，7 表示預(yù)留給內(nèi)部使用，monlist 請求即表示為010。

通過分析，可見NTP 服務(wù)器的漏洞預(yù)防點(diǎn)是服務(wù)器版本和配置漏洞。

2.4 SNMP

2.4.1 漏洞分析

SNMP 協(xié)議(Simple Network Management Protocol)專門設(shè)計用于在IP 網(wǎng)絡(luò)管理網(wǎng)絡(luò)節(jié)點(diǎn)(服務(wù)器、工作站、路由器、交換機(jī)及HUBS 等)。 常用的版本有1、2c 和3 三個，其中2c 版本最為通用。

根據(jù)RFC1441-RFC1452 文檔說明，在SNMP2c 版本中引入了getbulk 命令來實(shí)現(xiàn)單個請求中獲取大量的管理數(shù)據(jù)，snmpbulkget 命令則允許client 端反復(fù)請求getbulk 的內(nèi)容。 同時，如果網(wǎng)絡(luò)實(shí)體在處理請求數(shù)據(jù)包時出錯，將返回錯誤數(shù)據(jù)包幫助查明請求格式錯誤的原因。

2.4.2 構(gòu)造payload

SNMP 協(xié)議基于UDP 協(xié)議的161 端口進(jìn)行通信，本文仿真實(shí)驗(yàn)中進(jìn)行如下設(shè)計：

community=′public′

max_repetitions=200

b.varbindlist=[SNMPvarbind(oid=ASN1_OID(′1.3.6.1.2.1.1′))，SNMPvarbind(oid=ASN1_OID(′1.3.6.1.2.1.19.1.3′))]

其中community 字段對應(yīng)命令行訪問時指定的密碼。 max_repetitions 字段會指定重復(fù)變量上的最大迭代次數(shù)。 ASN1(Abstract Syntax Notation One，抽象語法定義)定義SNMP 的協(xié)議數(shù)據(jù)單元PDU 和管理對象MIB 的格式。 OID 意味對象標(biāo)識符，是獲取SNMP 具體信息內(nèi)容的一個標(biāo)識，SNMP 中存的信息是一個樹狀的信息結(jié)構(gòu)，每一個節(jié)點(diǎn)都由一個OID進(jìn)行唯一標(biāo)識，如1.3.6.1.2.1.1 表示系統(tǒng)信息。

通過分析，可見SNMP 服務(wù)器的漏洞預(yù)防點(diǎn)是SNMP協(xié)議的版本以及snmpbulkget 請求的支持與否。

2.5 SSDP

2.5.1 漏洞分析

互聯(lián)網(wǎng)中的智能設(shè)備普遍采用UPnP(即插即用)協(xié)議作為網(wǎng)絡(luò)通信協(xié)議，而UPnP 設(shè)備的發(fā)現(xiàn)是通過源端口為1900 的SSDP(Simple Service Discovery Protocol)進(jìn)行相互感知。

當(dāng)新設(shè)備被添加到網(wǎng)絡(luò)時，SSDP 協(xié)議不會檢驗(yàn)查詢方是否與設(shè)備在同一網(wǎng)絡(luò)中，直接通過特定地址和端口(239.255.255.250：1900)使用M-SEARCH 方法通過廣播的方式搜索具有目標(biāo)設(shè)備或目標(biāo)服務(wù)的類型、標(biāo)識符等數(shù)據(jù)以及目標(biāo)的其他相關(guān)消息。 SSDP支持兩種“通用”ST 查詢類型：搜索根設(shè)備(upnp：rootdevice)和搜索所有UPnP 設(shè)備和服務(wù)(ssdp：all)，監(jiān)聽多播地址并支持這種特定ST(搜索目標(biāo))多屏幕類型的其他設(shè)備使用單播的方式響應(yīng)[10]，因此這種“組播請求，單播響應(yīng)”的特點(diǎn)會使得請求包與應(yīng)答包大小懸殊。

2.5.2 構(gòu)造payload

SSDP 協(xié)議基于UDP 協(xié)議的1900 端口進(jìn)行通信，本文仿真實(shí)驗(yàn)中進(jìn)行如下設(shè)計：

構(gòu)造特定IP 的ssdp：all 查詢請求的SSDP 數(shù)據(jù)包，flags 字段四條信息如下：

M-SEARCH * HTTP/1.1

HOST：239.255.255.250：1900

MAN："ssdp：discover"

MX：1

ST：ssdp：all

第一個字段表示發(fā)送了HTTP 請求；第二個字段HOST 表示該請求發(fā)送到組播IP 地址；第三個字段表示這是一個查詢請求；第四個字段MX 表示最長等待時間；第五個字段ST 表示查詢目標(biāo)，upnp：rootdevice 為僅搜索網(wǎng)絡(luò)中的根設(shè)備，ssdp：all 為搜索所有UPnP 設(shè)備和服務(wù)。

通過分析，可見SSDP 協(xié)議的漏洞預(yù)防點(diǎn)是ST字段的可查詢目標(biāo)以及組內(nèi)設(shè)備的應(yīng)答規(guī)則。

2.6 CLDAP

2.6.1 漏洞分析

CLDAP(C Lightweight Directory Access Protocol)是面向無連接的輕量目錄訪問協(xié)議， 在不提供身份驗(yàn)證功能的情況下進(jìn)行數(shù)據(jù)傳輸。 目前開源軟件openLDAP不再支持UDP 協(xié)議的請求，只有利用Windows 服務(wù)器的活動目錄服務(wù)Active Directory(AD)。 通常AD 域服務(wù)會在UDP 端口389 上使用CLDAP 協(xié)議來等待執(zhí)行rootDSE 的搜索操作， 客戶端使用UDP 數(shù)據(jù)包向389 端口發(fā)起searchRequest 服務(wù)， 一般情況下該操作會得到遠(yuǎn)大于請求數(shù)據(jù)包的應(yīng)答包[11]。

2.6.2 構(gòu)造payload

通過CLDAP 協(xié)議存在的漏洞分析，本文仿真實(shí)驗(yàn)中進(jìn)行如下設(shè)計：

基于RFC2251 文檔可知searchRequest 操作共有8 個字段，其中接收自定義字符輸入的字段只有baseObject、filter、attributes 三 個，baseObject 值 設(shè) 為 空，filter 字段值設(shè)為objectclass，attributes 設(shè)為空[12]，進(jìn)一步將searchRequest 操作轉(zhuǎn)化為十六進(jìn)制payload。

通過分析，可見CLDAP 協(xié)議的漏洞預(yù)防點(diǎn)是Windows 服務(wù)器活動目錄服務(wù)Active Directory 的開啟與否。

3 反射放大效果驗(yàn)證

3.1 實(shí)驗(yàn)環(huán)境搭建

實(shí)驗(yàn)環(huán)境為：Linux 系統(tǒng)(Ubuntu 16.04，kali)、Python3、wireshark。

3.2 仿真環(huán)境下反射放大payload 效果驗(yàn)證

服務(wù)器端1 開啟NTP 服務(wù)和SNMPD 服務(wù)，服務(wù)器端2 開啟DNS 服務(wù)查詢和Memcached 服務(wù)，Windows Server 2008 開啟CLDAP 服務(wù)，客戶端和受害客戶端開啟wireshark 抓包服務(wù)，客戶端發(fā)送payload 數(shù)據(jù)包至服務(wù)器端，觀察到客戶端未收到回應(yīng)數(shù)據(jù)包，受害客戶端接收到各服務(wù)器端的大量回應(yīng)數(shù)據(jù)包，證明可實(shí)現(xiàn)IP 欺騙和放大效果。

3.3 真實(shí)環(huán)境下反射放大payload 效果驗(yàn)證

通過ZoomEye 獲取真實(shí)網(wǎng)絡(luò)環(huán)境中一定數(shù)量的六種協(xié)議服務(wù)器IP 列表，利用上述的客戶端向這些IP 發(fā)送payload 數(shù)據(jù)包，打開wireshark 監(jiān)控服務(wù)器回包和帶寬變化，利用監(jiān)聽函數(shù)對回包IP 和放大倍數(shù)進(jìn)行統(tǒng)計，根據(jù)常見的反射放大型DDoS 評判方法，選取payload 字節(jié)數(shù)、理論放大倍數(shù)[13]、最大放大倍數(shù)和流量峰值作為實(shí)驗(yàn)評判標(biāo)準(zhǔn)，詳細(xì)結(jié)果見表1。

表1 實(shí)驗(yàn)結(jié)果統(tǒng)計表

通過觀察流量變化可以發(fā)現(xiàn)應(yīng)答包字節(jié)數(shù)遠(yuǎn)大于payload 數(shù)據(jù)包，網(wǎng)絡(luò)返回帶寬最大可達(dá)到28 Mb/s，其中Memcached、SSDP、SNMP 和NTP 請求應(yīng)答數(shù)據(jù)變化如圖3 ～圖6 所示，CLDAP 客戶端帶寬變化如圖7 所示。

其中最大放大倍數(shù)計算方式如下：

圖3 Memcached 客戶端請求應(yīng)答數(shù)據(jù)圖

圖4 SSDP 客戶端請求應(yīng)答數(shù)據(jù)圖

圖5 SNMP 客戶端請求應(yīng)答數(shù)據(jù)圖

圖6 NTP 客戶端請求應(yīng)答數(shù)據(jù)圖

圖7 CLDAP 客戶端帶寬變化圖

探測開啟一段時間后，客戶端的流量峰值最大可達(dá)到28 Mb/s，各個協(xié)議的平均流量峰值都超過5 Mb/s，說明實(shí)驗(yàn)結(jié)果很好地測試了真實(shí)環(huán)境下payload 的放大效果，同時可以發(fā)現(xiàn)六種常見協(xié)議的最大放大倍數(shù)都非常可觀。

4 防范反射放大型DDoS

反射放大型DDoS 危害大、成本低、溯源難，為不法分子和黑色產(chǎn)業(yè)等從業(yè)者所熱愛，查看ZoomEye公布的全球各協(xié)議可利用主機(jī)探測結(jié)果，全球范圍內(nèi)可利用主機(jī)數(shù)量相當(dāng)可觀，我國作為重災(zāi)區(qū)，很容易被人利用來實(shí)現(xiàn)反射和放大，因此重視防范是非常必要的。 通常來說反射放大型DDoS 的防范方法可分為用于放大的服務(wù)器上的防范和用于受害者用戶上的防范[14]。

4.1 服務(wù)器角度的防范措施

對于文中所列協(xié)議，在服務(wù)器管理員角度，根據(jù)反射放大型DDoS 預(yù)防點(diǎn)應(yīng)盡量做到如下配置：

(1)Memcached 服務(wù)可在配置服務(wù)器時禁止UDP傳輸；

(2)DNS 服務(wù)可在配置時關(guān)閉遞歸查詢功能；

(3)NTP 服務(wù)器可升級到4.2.7p26 或者更高的版本，或關(guān)閉當(dāng)前NTP 服務(wù)器的monlist 功能[15]；

(4)SNMP 服務(wù)器可以禁用snmpbulkget 請求命令；

(5)對于不需要使用UPnP 服務(wù)的設(shè)備關(guān)閉SSDP 服務(wù)；

(6)在非必要的情況下，關(guān)閉AD 域服務(wù)器的root-DSE 功能；

(7)在服務(wù)器上通過變更服務(wù)端口或限制請求IP 來進(jìn)行防范。

4.2 受害者角度的防范

對于可能成為受害者的目標(biāo)用戶來說，可以通過采用下列方法降低遭受反射放大型DDoS 的風(fēng)險并減少損失：

(1)在路由器或防火墻上配置ACL 以限制可通過的協(xié)議和IP，或限制對外部請求所返回的響應(yīng)包的大小，對超過閾值的包進(jìn)行丟棄。

(2)在路由器或防火墻處安裝流量清洗設(shè)備。在檢測到可能發(fā)生反射放大型DDoS 時，將所有流量引入清洗集群，使多對一的攻擊變?yōu)槎鄬Χ?，并通過特征、基線、回復(fù)確認(rèn)等方式對攻擊流量進(jìn)行識別與清洗，之后將經(jīng)過清洗之后的正常訪問流量注入到原有網(wǎng)絡(luò)中，訪問目的IP。 此時在用戶來看，并不存在DDoS 攻擊，服務(wù)保持正常[16]。

(3)使用高防IP，在多個IP 上通過負(fù)載均衡模式進(jìn)行輪詢，將DDoS 攻擊流量均攤到多個IP 地址上，將大攻擊變?yōu)槎鄠€小攻擊。

(4)采用CDN 技術(shù)，利用具有一定DDoS 保護(hù)能力的CDN 節(jié)點(diǎn)來實(shí)現(xiàn)DDoS 保護(hù)。在使用CDN 的情況下，攻擊者獲得的目標(biāo)IP 為CDN 節(jié)點(diǎn)的地址，而不是服務(wù)器地址，因此攻擊者攻擊的是一個CDN節(jié)點(diǎn)，其他節(jié)點(diǎn)仍可以使用，不影響對服務(wù)器內(nèi)容的正常訪問[17]。

(5)采用雙機(jī)或多機(jī)熱備，搭建備用服務(wù)器，在主用服務(wù)器遭受DDoS 宕機(jī)時啟用備用設(shè)備以保持服務(wù)。

5 結(jié)論

反射放大型DDoS 攻擊頻頻出現(xiàn)，對個體、公司甚至國家造成不可預(yù)估的危害。 本文針對常見的DNS、SNMP、SSDP、NTP、Memcached 和 CLDAP 六 種協(xié)議存在的安全漏洞進(jìn)行分析，利用Python 庫設(shè)計DDoS payload，搭建仿真環(huán)境驗(yàn)證反射放大效果，并測試真實(shí)環(huán)境放大效果，進(jìn)一步突出反射放大型DDoS 的危害。 本研究希望幫助安全人員優(yōu)化完善服務(wù)器配置信息，防御反射放大型DDoS，從而盡可能地減小受害幾率，同時幫助更多的人認(rèn)識和規(guī)防反射放大型DDoS。