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

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

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

0 引言

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

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

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

1 反射放大型DDoS

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

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

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

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

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

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

2.1 Memcached

2.1.1 漏洞分析

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

2.1.2 構(gòu)造payload

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

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

set key flags exptime bytes

value

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

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

"x00x00x00x00x00x01x00x00get"+key+" "

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

2.2 DNS

2.2.1 漏洞分析

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

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

2.2.2 構(gòu)造payload

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

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

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

2.3 NTP

2.3.1 漏洞分析

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

2.3.2 構(gòu)造payload

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

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

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

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

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

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

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

2.4 SNMP

2.4.1 漏洞分析

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

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

2.4.2 構(gòu)造payload

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

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

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

2.5 SSDP

2.5.1 漏洞分析

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

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

2.5.2 構(gòu)造payload

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

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

M-SEARCH * HTTP/1.1

HOST：239.255.255.250：1900

MAN："ssdp：discover"

MX：1

ST：ssdp：all

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

通過(guò)分析，可見(jiàn)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)是面向無(wú)連接的輕量目錄訪問(wèn)協(xié)議， 在不提供身份驗(yàn)證功能的情況下進(jìn)行數(shù)據(jù)傳輸。 目前開(kāi)源軟件openLDAP不再支持UDP 協(xié)議的請(qǐng)求，只有利用Windows 服務(wù)器的活動(dòng)目錄服務(wù)Active Directory(AD)。 通常AD 域服務(wù)會(huì)在UDP 端口389 上使用CLDAP 協(xié)議來(lái)等待執(zhí)行rootDSE 的搜索操作， 客戶端使用UDP 數(shù)據(jù)包向389 端口發(fā)起searchRequest 服務(wù)， 一般情況下該操作會(huì)得到遠(yuǎn)大于請(qǐng)求數(shù)據(jù)包的應(yīng)答包[11]。

2.6.2 構(gòu)造payload

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

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

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

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 開(kāi)啟NTP 服務(wù)和SNMPD 服務(wù)，服務(wù)器端2 開(kāi)啟DNS 服務(wù)查詢和Memcached 服務(wù)，Windows Server 2008 開(kāi)啟CLDAP 服務(wù)，客戶端和受害客戶端開(kāi)啟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)證

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

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

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

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

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

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

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

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

圖7 CLDAP 客戶端帶寬變化圖

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

4 防范反射放大型DDoS

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

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

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

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

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

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

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

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

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

(7)在服務(wù)器上通過(guò)變更服務(wù)端口或限制請(qǐng)求IP 來(lái)進(jìn)行防范。

4.2 受害者角度的防范

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

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

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

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

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

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

5 結(jié)論

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