基于SDN的UDP反射攻擊響應(yīng)方案

丁 偉,張千風(fēng),周文烽

(東南大學(xué) a.網(wǎng)絡(luò)空間安全學(xué)院; b.計(jì)算機(jī)科學(xué)與工程學(xué)院,南京 211189)

0 概述

用戶數(shù)據(jù)報(bào)協(xié)議(User Datagram Protocol,UDP)是開(kāi)放式系統(tǒng)互聯(lián)(Open System Interconnection,OSI)參考模型中一種無(wú)連接的傳輸層協(xié)議,提供面向事務(wù)的簡(jiǎn)單不可靠信息傳送服務(wù)。2013年3月,世界反垃圾郵件組織Spamhaus遭受了峰值達(dá)到300 Gb/s的反射型DDoS攻擊[1],攻擊者向互聯(lián)網(wǎng)上開(kāi)放的域名系統(tǒng)(Domain Name System,DNS)服務(wù)器發(fā)送了對(duì)ripe.net域名的ANY型解析請(qǐng)求,并將請(qǐng)求的源IP偽造成Spamhaus的IP地址。在此次攻擊中,DNS請(qǐng)求數(shù)據(jù)的長(zhǎng)度為36 Byte,而響應(yīng)數(shù)據(jù)的平均長(zhǎng)度為3 000 Byte,攻擊者將攻擊流量放大了近100倍。

2018年1月,NETSOUT A發(fā)布了《13th Annual Worldwide Infrastructure Security Report》[2],內(nèi)容顯示DDoS攻擊對(duì)于互聯(lián)網(wǎng)來(lái)說(shuō)仍是主要的威脅。在2017年的所有攻擊中,DDoS占了87%,其中大部分是UDP反射攻擊[3],并且DNS和網(wǎng)絡(luò)時(shí)鐘協(xié)議(Network Time Protocol,NTP)是被使用最多的協(xié)議。

UDP反射攻擊利用了UDP協(xié)議的無(wú)連接特性和服務(wù)協(xié)議自身的請(qǐng)求與響應(yīng)之間數(shù)據(jù)量不對(duì)稱的特性。攻擊者通過(guò)偽造被攻擊者地址請(qǐng)求這些使用UDP協(xié)議支持傳輸?shù)姆?wù),產(chǎn)生放大數(shù)倍的響應(yīng)流量,從而達(dá)到攻擊的目的[4]。那些提供UDP服務(wù)的主機(jī)通常被稱為放大器,導(dǎo)致放大器發(fā)出反射攻擊流量的報(bào)文通常被稱為請(qǐng)求報(bào)文。本文針對(duì)UDP反射攻擊放大器,提出基于入侵檢測(cè)系統(tǒng)(Intrusion Detection System,IDS)的UDP反射攻擊響應(yīng)方案。

1 UDP反射攻擊的檢測(cè)與響應(yīng)

由于UDP反射攻擊的流量特征明顯且放大器使用真實(shí)地址,因此UDP反射攻擊的檢測(cè)在主干鏈路上比較容易實(shí)現(xiàn),同時(shí)可以定位發(fā)出攻擊流量的放大器。文獻(xiàn)[5]給出一個(gè)以主干網(wǎng)邊界流記錄為數(shù)據(jù)源的檢測(cè)算法,其核心思路是在網(wǎng)絡(luò)邊界路由器(檢測(cè)點(diǎn))使用端口和流量強(qiáng)度閾值約束并檢出攻擊流量。根據(jù)檢測(cè)點(diǎn)提供的流記錄,對(duì)基于UDP協(xié)議傳輸?shù)臄?shù)據(jù)源端口使用UDP反射攻擊協(xié)議的端口匹配,對(duì)匹配到的流量再使用宿地址作為鍵對(duì)流量進(jìn)行整合,強(qiáng)度大于閾值的整合流量被判定為最終的攻擊流量。該算法實(shí)現(xiàn)簡(jiǎn)單,基于一個(gè)面向流記錄的精細(xì)化網(wǎng)管平臺(tái)(NBOS)[6],其被部署到中國(guó)教育和科研計(jì)算機(jī)網(wǎng)(China Education and Research Network,CERNET)38個(gè)主節(jié)點(diǎn)后運(yùn)行效果良好,在19、53、123、161和1900 5個(gè)端口檢測(cè)到了大量的反射攻擊實(shí)例,同時(shí)定位了CERNET中5個(gè)端口的放大器[5]。這5個(gè)端口對(duì)應(yīng)的服務(wù)是字符發(fā)生器協(xié)議(Character Generator Protocol,CharGen)、DNS、NTP、簡(jiǎn)單網(wǎng)絡(luò)管理協(xié)議(Simple Network Management Protocol,SNMP)、簡(jiǎn)單服務(wù)發(fā)現(xiàn)協(xié)議(Simple Serve Discovery Protocol,SSDP),根據(jù)NETSOUT A的報(bào)告[2],2017年全球范圍內(nèi)這5個(gè)端口的放大器占全部放大器的94.1%。

UDP反射攻擊的響應(yīng)主要包括對(duì)放大器的防護(hù)、過(guò)濾偽造源地址數(shù)據(jù)包和清洗攻擊流量3種方式[7]。放大器的防護(hù)是通過(guò)對(duì)放大器進(jìn)行相應(yīng)操作,使其無(wú)法成為UDP反射攻擊的放大器,這些操作指的是關(guān)閉放大器上導(dǎo)致UDP反射攻擊的服務(wù)或者對(duì)其版本進(jìn)行升級(jí)進(jìn)而使其不再支持該服務(wù),如NTP中的monlist服務(wù)。這種響應(yīng)方法需要有放大器的管理權(quán)限,而網(wǎng)絡(luò)管理者和互聯(lián)網(wǎng)服務(wù)提供商(Internet Service Provider,ISP)一般沒(méi)有該權(quán)限。

由于UDP反射攻擊中,攻擊請(qǐng)求數(shù)據(jù)包與正常數(shù)據(jù)包是無(wú)法區(qū)分的,因此過(guò)濾偽造源地址數(shù)據(jù)包響應(yīng)方法也不可行。清洗攻擊流量利用Anycast技術(shù)[8],將DDoS攻擊流量傳輸?shù)阶罱那逑粗行?使攻擊流量得到有效稀釋,從而對(duì)其進(jìn)行阻斷。該方法未針對(duì)反射攻擊的特征,而是將其看成是普通的DDoS攻擊進(jìn)行流量清洗,效率較低。

文獻(xiàn)[3]面向網(wǎng)絡(luò)中定位到的放大器,提出一種基于訪問(wèn)控制列表(Access Control Lists,ACL)的攔截方式,通過(guò)在網(wǎng)絡(luò)邊界設(shè)備上設(shè)置ACL規(guī)則,攔截網(wǎng)內(nèi)放大器特定漏洞服務(wù)協(xié)議端口上的相關(guān)報(bào)文,從而阻止UDP反射攻擊。雖然該方法具有較好的效果,但其無(wú)法對(duì)正常使用協(xié)議的攻擊報(bào)文進(jìn)行攔截,例如DNS協(xié)議,由于該方法會(huì)導(dǎo)致這些服務(wù)失效,同時(shí)ACL的配置需要人工干預(yù),因此不具備實(shí)際應(yīng)用價(jià)值。

本文研究工作主要圍繞反射攻擊響應(yīng)展開(kāi),從文獻(xiàn)[3]的研究思路出發(fā),提出反射攻擊響應(yīng)規(guī)則,在放大器已被定位的條件下,利用網(wǎng)絡(luò)邊界的軟件定義網(wǎng)絡(luò)(Software Defined Network,SDN)設(shè)備代替ACL,采用響應(yīng)規(guī)則對(duì)反射攻擊請(qǐng)求報(bào)文進(jìn)行過(guò)濾。在此基礎(chǔ)上,實(shí)現(xiàn)對(duì)響應(yīng)方案的整體流程設(shè)計(jì),重點(diǎn)分析主干網(wǎng)在用型協(xié)議的反射攻擊響應(yīng)方案,并在CERNET南京主節(jié)點(diǎn)網(wǎng)絡(luò)邊界進(jìn)行實(shí)現(xiàn)和測(cè)試。

2 基于SDN的反射攻擊響應(yīng)

2.1 SDN技術(shù)與反射攻擊響應(yīng)

SDN來(lái)源于斯坦福大學(xué)Clean Slate研究課題,本質(zhì)特點(diǎn)是控制平面和數(shù)據(jù)平面的分離以及開(kāi)放可編程性,優(yōu)勢(shì)在于可以對(duì)整個(gè)網(wǎng)絡(luò)狀態(tài)有所了解,為反射攻擊請(qǐng)求報(bào)文的過(guò)濾提供了全局統(tǒng)一控制能力。

SDN控制層中的控制器通過(guò)OpenFlow協(xié)議對(duì)OpenFlow交換機(jī)中的流表進(jìn)行控制來(lái)達(dá)到對(duì)流量進(jìn)行管理的目的[9]。OpenFlow[10]中的流表由一條條流表項(xiàng)組成,一條流表項(xiàng)由7個(gè)部分組成,分別是匹配字段(Match Fields)、優(yōu)先級(jí)(Priority)、計(jì)數(shù)(Counters)、指令集(Instructions)、超時(shí)時(shí)間(Timeouts)、備注(Cookie)以及標(biāo)識(shí)(Flags)。

SDN技術(shù)中流表項(xiàng)包含本文使用的十元組:

[src_ip,src_mask,src_port,dst_ip,dst_mask,

dst_port,ip_protocol,submit_time,hard_time,action]

(1)

其中,src_ip、src_mask、src_port、dst_ip、dst_mask、dst_port、ip_protocol、submit_time、hard_time、action分別對(duì)應(yīng)的語(yǔ)義是源地址、源地址掩碼長(zhǎng)度、源端口、目的地址、目的地址掩碼長(zhǎng)度、目的端口、協(xié)議號(hào)(17表示UDP,6表示TCP)、響應(yīng)規(guī)則提交時(shí)間、響應(yīng)規(guī)則執(zhí)行持續(xù)時(shí)間和執(zhí)行動(dòng)作,如“轉(zhuǎn)發(fā)”和“丟棄”。

SDN控制器可以根據(jù)接收到的響應(yīng)規(guī)則,自動(dòng)生成對(duì)應(yīng)的OpenFlow流表項(xiàng)。流表項(xiàng)中的匹配字段由響應(yīng)規(guī)則中前7項(xiàng)組成,決定了哪些報(bào)文將被該規(guī)則處理[11];指令集對(duì)應(yīng)響應(yīng)規(guī)則中的action,決定匹配成功的報(bào)文將被如何處理;超時(shí)時(shí)間對(duì)應(yīng)響應(yīng)規(guī)則中的submit_time和hard_time,決定了規(guī)則有效期;其他字段由SDN控制器自動(dòng)生成。

SDN對(duì)報(bào)文的控制能力超過(guò)普通路由器,所有ACL可實(shí)施的操作都可以在OpenFlow環(huán)境下完成,同時(shí)OpenFlow的轉(zhuǎn)發(fā)操作提供了進(jìn)一步的操作空間,本文在此基礎(chǔ)上支持反射攻擊響應(yīng)。

2.2 研究環(huán)境與條件

本文研究在文獻(xiàn)[3]的基礎(chǔ)上展開(kāi),文獻(xiàn)[3]通過(guò)在網(wǎng)絡(luò)邊界設(shè)備上設(shè)置ACL規(guī)則來(lái)攔截網(wǎng)內(nèi)已定位放大器特定漏洞服務(wù)協(xié)議端口上的相關(guān)報(bào)文,從而阻止UDP反射攻擊,但其無(wú)法對(duì)正常使用協(xié)議的攻擊報(bào)文進(jìn)行攔截,同時(shí)ACL的配置需要人工干預(yù),因此不具備較好的普遍性。本文嘗試?yán)镁W(wǎng)絡(luò)邊界的SDN設(shè)備代替ACL列表攔截發(fā)往放大器的攻擊請(qǐng)求報(bào)文。假設(shè)研究條件為:1)放大器已被定位,是一個(gè)二元組(amp_ip,amp_port),其中,amp_ip是放大器的ip地址,amp_port是放大器提供反射協(xié)議服務(wù)的端口號(hào);2)請(qǐng)求報(bào)文通過(guò)網(wǎng)絡(luò)邊界,這需要放大器與攻擊者位于網(wǎng)絡(luò)兩側(cè),而與被攻擊者的位置無(wú)關(guān)。在攻擊者、放大器和被攻擊者與網(wǎng)絡(luò)邊界構(gòu)成的8種關(guān)系模型中(如圖1所示),只有其中4種關(guān)系模型的攻擊主機(jī)發(fā)往放大器的攻擊請(qǐng)求報(bào)文通過(guò)網(wǎng)絡(luò)邊界,這4個(gè)場(chǎng)景分別為場(chǎng)景a、場(chǎng)景c、場(chǎng)景e、場(chǎng)景f,其中,場(chǎng)景a與場(chǎng)景e是對(duì)稱的,場(chǎng)景c和場(chǎng)景f是對(duì)稱的,下文僅面向場(chǎng)景a和場(chǎng)景c進(jìn)行闡述。

圖1 攻擊者、放大器和被攻擊者與網(wǎng)絡(luò)邊界的關(guān)系模型

2.3 響應(yīng)方案

文獻(xiàn)[3]基于ACL規(guī)則能夠較好地對(duì)UDP反射攻擊進(jìn)行攔截,其攔截規(guī)則也相對(duì)簡(jiǎn)單,這些規(guī)則可以與OpenFlow流表直接匹配,對(duì)應(yīng)操作是“丟棄”。但該方案存在兩方面的問(wèn)題:1)這些攔截只能面向主干網(wǎng)不在用協(xié)議的攻擊請(qǐng)求報(bào)文,對(duì)于正常使用的協(xié)議攻擊請(qǐng)求報(bào)文不能做此類處理;2)ACL規(guī)則的調(diào)整制定需要人工干預(yù),如出現(xiàn)放大器集合變化此類情況時(shí),需人工在網(wǎng)絡(luò)邊界重新設(shè)置規(guī)則。

本文利用SDN技術(shù)對(duì)反射攻擊請(qǐng)求報(bào)文過(guò)濾提供的全局統(tǒng)一控制能力,基于Openflow流表設(shè)計(jì)一個(gè)自動(dòng)化響應(yīng)方案,其核心思想為:

1)對(duì)所有主干網(wǎng)不在用協(xié)議,采用文獻(xiàn)[3]的ACL攔截規(guī)則和“丟棄”操作生成流表項(xiàng)進(jìn)行響應(yīng),從流量中過(guò)濾反射攻擊請(qǐng)求報(bào)文。流表項(xiàng)對(duì)應(yīng)式(1)中的十元組為:

[any_ip,32,any_port,amp_ip,32,amp_port,17,

submit_time,0,“丟棄”]

(2)

其中,src_ip字段為any_ip,表示任意IP地址,src_port字段為any_port,表示任意端口號(hào),dst_ip字段為amp_ip,表示放大器IP地址,dst_port字段為amp_port,表示放大器提供的主干網(wǎng)不在用協(xié)議服務(wù)端口,ip_protocol=17表示使用UDP協(xié)議,hard_time=0表示響應(yīng)規(guī)則執(zhí)行沒(méi)有時(shí)間限制,該響應(yīng)規(guī)則對(duì)應(yīng)的流表項(xiàng)只能由用戶主動(dòng)撤銷。

2)對(duì)所有主干網(wǎng)在用協(xié)議,將所有向放大器發(fā)出請(qǐng)求的報(bào)文,利用OpenFlow交換機(jī)的轉(zhuǎn)發(fā)操作,將其發(fā)送給一個(gè)在后臺(tái)運(yùn)行的應(yīng)用程序,這個(gè)程序?qū)?bào)文負(fù)載進(jìn)行分析來(lái)確定是否為攻擊請(qǐng)求報(bào)文。如果不是,則將其“回注”到流量中。對(duì)應(yīng)的流表響應(yīng)規(guī)則為:

[any_ip,32,any_port,amp_ip,32,amp_port,17,

submit_time,0,“轉(zhuǎn)發(fā)”]

(3)

其中,dst_ip字段為amp_ip,表示放大器IP地址,dst_port字段為amp_port,表示放大器提供主干網(wǎng)在用協(xié)議服務(wù)的端口。當(dāng)符合轉(zhuǎn)發(fā)流表項(xiàng)的報(bào)文被轉(zhuǎn)發(fā)到后臺(tái)運(yùn)行的應(yīng)用程序后,后臺(tái)應(yīng)用程序會(huì)根據(jù)不同的反射協(xié)議對(duì)其應(yīng)用不同的過(guò)濾規(guī)則進(jìn)行“丟棄”或者“回注”操作。

3)根據(jù)放大器庫(kù)的更新周期,實(shí)時(shí)動(dòng)態(tài)調(diào)整面向流表的響應(yīng)規(guī)則。

整個(gè)響應(yīng)方案如圖2所示,具體流程為:

1)響應(yīng)規(guī)則生成與提交部分中的響應(yīng)規(guī)則生成程序從放大器庫(kù)中獲取放大器信息,根據(jù)放大器庫(kù)的更新,動(dòng)態(tài)更新響應(yīng)規(guī)則,并將可用或者待撤銷的響應(yīng)規(guī)則實(shí)時(shí)發(fā)送給基于SDN技術(shù)的流量管理系統(tǒng)。

2)基于SDN技術(shù)的流量管理系統(tǒng)中根據(jù)響應(yīng)規(guī)則對(duì)通過(guò)網(wǎng)絡(luò)邊界的放大器請(qǐng)求報(bào)文進(jìn)行轉(zhuǎn)發(fā)或者丟棄處理,基于SDN技術(shù)可解決靜態(tài)配置規(guī)則的問(wèn)題。

3)報(bào)文過(guò)濾部分中的應(yīng)用程序從報(bào)文過(guò)濾規(guī)則庫(kù)中獲取過(guò)濾規(guī)則,根據(jù)這些規(guī)則對(duì)接收到的轉(zhuǎn)發(fā)報(bào)文進(jìn)行“丟棄”或者“回注”操作。

圖2 響應(yīng)方案設(shè)計(jì)流程

2.4 報(bào)文過(guò)濾規(guī)則

本節(jié)討論應(yīng)用程序中的報(bào)文過(guò)濾規(guī)則。這些過(guò)濾規(guī)則面向報(bào)文,目的在于響應(yīng)主干網(wǎng)在用協(xié)議的反射攻擊,處理對(duì)象是發(fā)往放大器且符合式(3)響應(yīng)規(guī)則的報(bào)文,采用深度報(bào)文檢測(cè)(Deep Packet Inspection,DPI)方式完成,導(dǎo)致反射攻擊的服務(wù)協(xié)議彼此間沒(méi)有關(guān)聯(lián),而且原因各不相同,因此過(guò)濾規(guī)則只能面向不同的協(xié)議分別進(jìn)行討論。由于DNS和NTP是目前最常見(jiàn)的在用反射協(xié)議[12],因此本節(jié)分別對(duì)相應(yīng)的過(guò)濾規(guī)則進(jìn)行討論。這兩個(gè)服務(wù)對(duì)應(yīng)的端口分別為53和123。

對(duì)于NTP而言,根據(jù)文獻(xiàn)[7]導(dǎo)致反射攻擊發(fā)生的原因是協(xié)議中的monlist請(qǐng)求。NTP服務(wù)器響應(yīng)monlist指令后會(huì)返回與其進(jìn)行過(guò)時(shí)間同步的最近600個(gè)客戶端的IP地址。響應(yīng)包按照每6個(gè)IP進(jìn)行分割,最多一個(gè)NTP monlist請(qǐng)求會(huì)形成100個(gè)響應(yīng)包,實(shí)現(xiàn)較大的流量放大效果,因此基于NTP協(xié)議的UDP反射攻擊會(huì)向放大器發(fā)送monlist請(qǐng)求報(bào)文。應(yīng)用程序?qū)D(zhuǎn)發(fā)過(guò)來(lái)的NTP報(bào)文,只要分析其是否為monlist請(qǐng)求報(bào)文即可,即匹配報(bào)文中是否含有“monlist=1”,如果有,則該報(bào)文是UDP反射攻擊請(qǐng)求報(bào)文,對(duì)其進(jìn)行“丟棄”操作;否則對(duì)其進(jìn)行“回注”操作。該過(guò)濾規(guī)則可以寫(xiě)為:

monlist=1

(4)

對(duì)于DNS而言,根據(jù)相關(guān)研究,筆者認(rèn)為導(dǎo)致反射攻擊的報(bào)文應(yīng)具有以下特征:

1)domain∈DNSSEC,表示域名參數(shù)domain是支持DNSSEC的域名。DNSSEC在現(xiàn)有的DNS協(xié)議的基礎(chǔ)上,對(duì)資源記錄采用RSA加密算法,RSA在加密算法中的密鑰長(zhǎng)度為2 048 bit(256 Byte)。在DNS反射攻擊中,攻擊者對(duì)支持DNSSEC的域名進(jìn)行ANY查詢會(huì)額外返回上述4種資源記錄信息,從而擴(kuò)大回復(fù)報(bào)文的字節(jié)大小,起到流量放大的作用。對(duì)于普通的非加密域名的解析一般為一個(gè)IP地址,不會(huì)產(chǎn)生大的流量。該特征來(lái)源于文獻(xiàn)[13],該文獻(xiàn)對(duì)DNS協(xié)議被用于UDP反射攻擊的潛能性進(jìn)行詳細(xì)的實(shí)驗(yàn)分析和討論,結(jié)果表明DNSSEC對(duì)UDP反射攻擊是非常有利的,而對(duì)常規(guī)域名的解析放大效果不理想。

2)RR=ANY,表示查詢類型是ANY類型,即向DNS服務(wù)器請(qǐng)求獲取所有資源記錄,ANY查詢會(huì)返回查詢域名的所有類型資源記錄信息,該類查詢相比于其他查詢類型流量放大效果更好。該特征來(lái)源于文獻(xiàn)[14],該文獻(xiàn)根據(jù)US-CERT觀察到的UDP反射攻擊案例,發(fā)現(xiàn)絕大多數(shù)攻擊使用的都是ANY查詢。另外,文獻(xiàn)[15]的研究表明DNS協(xié)議中的ANY查詢用于調(diào)試和測(cè)試,并且應(yīng)用范圍不廣泛,目前已知的只有qmail應(yīng)用和版本為36.0到36.0.1的Firefox應(yīng)用會(huì)使用ANY查詢,當(dāng)qmail在對(duì)傳出消息的封裝進(jìn)行域規(guī)范化時(shí)會(huì)使用ANY查詢,但文獻(xiàn)[16]指出現(xiàn)代郵件傳輸代理(Mail Transfer Agent,MTA)不再用qmail進(jìn)行ANY查詢。無(wú)論是qmail還是Firefox目前均已更新至最新版本,在新的版本中均不使用RR=ANY這個(gè)查詢條件。因?yàn)闆](méi)有正常的應(yīng)用使用該條件,所以該特征可以作為過(guò)濾條件。

3)EDNS0=1,表示使用EDNS0協(xié)議,即擴(kuò)展后的DNS協(xié)議。在DNS反射攻擊中,攻擊者使用EDNS0設(shè)置能夠處理的最大UDP報(bào)文的大小。文獻(xiàn)[17]表明EDNS0擺脫了使用UDP傳輸?shù)腄NS回復(fù)報(bào)文的大小在512 Byte以內(nèi)的限制,這是放大效果最大化的反射攻擊請(qǐng)求必須滿足的條件。

4)RD=1,表示遞歸請(qǐng)求解析域名,在遞歸查詢模式下,DNS服務(wù)器接收到客戶機(jī)的請(qǐng)求,需使用一個(gè)準(zhǔn)確的查詢結(jié)果回復(fù)客戶機(jī)。文獻(xiàn)[18]表明如果DNS服務(wù)器本地沒(méi)有存儲(chǔ)查詢的DNS信息,那么該服務(wù)器會(huì)遞歸詢問(wèn)上層DNS服務(wù)器,并最終將返回的查詢結(jié)果提交至客戶機(jī)。與特征3一樣,遞歸查詢也是DNS反射攻擊中的DNS請(qǐng)求報(bào)文必須滿足的條件。

根據(jù)以上分析內(nèi)容可知,應(yīng)用程序?qū)NS協(xié)議轉(zhuǎn)發(fā)報(bào)文的過(guò)濾規(guī)則為:

domain∈DNSSEC & & RR=ANY & &

EDNS0=1 & & RD=1

(5)

3 響應(yīng)方案實(shí)現(xiàn)與實(shí)驗(yàn)結(jié)果

3.1 響應(yīng)方案實(shí)現(xiàn)

為驗(yàn)證響應(yīng)方案的有效性,本文實(shí)現(xiàn)了上述方案,并在CERNET南京主節(jié)點(diǎn)網(wǎng)絡(luò)邊界上進(jìn)行測(cè)試。在此次實(shí)施過(guò)程中,SDN功能由HYDRA系統(tǒng)支持,放大器由NBOS系統(tǒng)提供,它們同樣位于CERNET南京主節(jié)點(diǎn)網(wǎng)絡(luò)邊界。

3.1.1 HYDRA和NBOS系統(tǒng)

NBOS[3]可檢測(cè)到網(wǎng)內(nèi)的反射攻擊行為,并且定位到放大器位置。NBOS提供的放大器信息包括放大器IP地址、反射端口、首次檢出時(shí)間以及末次檢出時(shí)間等,信息的更新周期是5 min。

HYDRA系統(tǒng)目前還是一個(gè)原型系統(tǒng),只能在流入CERNET南京主節(jié)點(diǎn)網(wǎng)絡(luò)的方向上使用OpenFlow流表對(duì)鏡像流量進(jìn)行控制。該系統(tǒng)部署在CERNET南京主節(jié)點(diǎn)網(wǎng)絡(luò)邊界上,使用的SDN設(shè)備是H3C S6300交換機(jī),系統(tǒng)提供統(tǒng)一的響應(yīng)符合式(1)規(guī)范的規(guī)則接口(新增規(guī)則和刪除規(guī)則在不同位置),可以自動(dòng)將來(lái)自應(yīng)用系統(tǒng)的響應(yīng)規(guī)則轉(zhuǎn)換成流表項(xiàng)(每次一條)。目前流表支持的操作有“轉(zhuǎn)發(fā)”和“丟棄”。轉(zhuǎn)發(fā)后的報(bào)文以每5分鐘1個(gè)pcap文件的形式存儲(chǔ)在特定位置,應(yīng)用程序可以在此獲取這些轉(zhuǎn)發(fā)的報(bào)文。對(duì)每條操作為“丟棄”的流表項(xiàng),HYDRA系統(tǒng)統(tǒng)計(jì)丟棄報(bào)文數(shù)量。由于只對(duì)鏡像流量進(jìn)行模擬操作,因此HYDRA系統(tǒng)目前沒(méi)有流量回注功能。

由于NBOS系統(tǒng)能夠提供CharGen、DNS、NTP、SNMP、SSDP這5種類型的UDP反射攻擊協(xié)議的放大器信息,因此面向這5種協(xié)議進(jìn)行測(cè)試[19-20]。其中的NTP和DNS屬于主干網(wǎng)在用協(xié)議,采用式(4)和式(5)兩條規(guī)則進(jìn)行響應(yīng),另外3個(gè)屬于主干網(wǎng)不在用協(xié)議,使用規(guī)則式(2)進(jìn)行響應(yīng)。因此,需要提交給HYDRA系統(tǒng)的響應(yīng)規(guī)則分別為:

1)CharGen反射攻擊:

[0.0.0.0,32,-1,amp_ip,32,19,17,submit_time,0,“丟棄”]

2)SNMP反射攻擊:

[0.0.0.0,32,-1,amp_ip,32,161,17,submit_time,0,“丟棄”]

3)SSDP反射攻擊:

[0.0.0.0,32,-1,amp_ip,32,1900,17,submit_time,0,“丟棄”]

4)DNS反射攻擊:

[0.0.0.0,32,-1,amp_ip,32,53,17,submit_time,0,“轉(zhuǎn)發(fā)”]

5)NTP反射攻擊:

[0.0.0.0,32,-1,amp_ip,32,123,17,submit_time,0,“轉(zhuǎn)發(fā)”]

其中,0.0.0.0表示任意IP地址,amp_ip是反射器IP地址(NBOS提供),submit_time表示響應(yīng)規(guī)則提交時(shí)間,該字段由HYDRA系統(tǒng)根據(jù)響應(yīng)規(guī)則接收的時(shí)間自行設(shè)置。

3.1.2 基于NBOS與HYDRA平臺(tái)的實(shí)現(xiàn)

圖2響應(yīng)方案的實(shí)現(xiàn)基于現(xiàn)有的NBOS和HYDRA平臺(tái),其中放大器庫(kù)由NBOS提供,SDN控制器與網(wǎng)絡(luò)邊界設(shè)備由HYDRA提供。在此條件下,實(shí)現(xiàn)的響應(yīng)方案還需要完成響應(yīng)規(guī)則生成程序和處理轉(zhuǎn)發(fā)報(bào)文的應(yīng)用程序。在此次實(shí)現(xiàn)中,前者位于NBOS放大器庫(kù)所在硬件平臺(tái),以在內(nèi)存中維護(hù)一張放大器響應(yīng)規(guī)則表為核心數(shù)據(jù)結(jié)構(gòu)工作,程序基于NBOS放大器庫(kù),每天對(duì)這張表進(jìn)行一次維護(hù),然后將需要修改的響應(yīng)規(guī)則發(fā)送到HYDRA的規(guī)則接口。程序?qū)崿F(xiàn)流程如圖3所示。其中的失效規(guī)則指放大器響應(yīng)規(guī)則表中放大器活躍時(shí)間與當(dāng)前時(shí)間相差N天的表項(xiàng)對(duì)應(yīng)的響應(yīng)規(guī)則,N的缺省值為3。

圖3 響應(yīng)規(guī)則生成程序的實(shí)現(xiàn)流程

應(yīng)用程序目前是測(cè)試版,位于HYDRA系統(tǒng)中指定接收轉(zhuǎn)發(fā)報(bào)文的主機(jī)上,只對(duì)兩種主干網(wǎng)在用協(xié)議的轉(zhuǎn)發(fā)報(bào)文進(jìn)行分析,且已得出報(bào)文過(guò)濾規(guī)則,因此未考慮報(bào)文過(guò)濾規(guī)則的動(dòng)態(tài)生成和更新,而是直接將規(guī)則式(4)和式(5)寫(xiě)在應(yīng)用程序中。在此基礎(chǔ)上,接收轉(zhuǎn)發(fā)報(bào)文的主機(jī)將接收到的轉(zhuǎn)發(fā)報(bào)文以每5分鐘1個(gè)pcap文件的形式存儲(chǔ)在硬盤(pán)上,應(yīng)用程序從硬盤(pán)獲取轉(zhuǎn)發(fā)報(bào)文后,將符合規(guī)則式(4)和式(5)的報(bào)文放入丟棄報(bào)文庫(kù)中。其余報(bào)文放入回注報(bào)文庫(kù)中,由于HYDRA系統(tǒng)目前沒(méi)有流量回注功能,因此應(yīng)用程序未對(duì)回注報(bào)文作進(jìn)一步處理。

3.2 實(shí)驗(yàn)結(jié)果

將響應(yīng)規(guī)則生成程序和處理轉(zhuǎn)發(fā)報(bào)文的應(yīng)用程序在實(shí)際環(huán)境中進(jìn)行測(cè)試,其中使用“丟棄”規(guī)則的3個(gè)主干網(wǎng)不在用協(xié)議的測(cè)試時(shí)間為7×24 h,具體為2018-04-24 05:00至2018-05-01 05:00。

由于HYDRA系統(tǒng)資源有限,因此對(duì)DNS與NTP兩個(gè)主干網(wǎng)在用協(xié)議反射攻擊的響應(yīng)分別選擇5臺(tái)比較活躍的放大器進(jìn)行24 h的響應(yīng)實(shí)驗(yàn),其中,DNS反射攻擊響應(yīng)實(shí)施時(shí)間為2018年4月26日,NTP反射攻擊響應(yīng)實(shí)施時(shí)間為2018年4月27日。

實(shí)驗(yàn)結(jié)果為響應(yīng)規(guī)則生成程序針對(duì)3個(gè)主干網(wǎng)不在用協(xié)議共生成25條響應(yīng)規(guī)則,其中,19端口2條,1900端口5條,其余18條面向161端口。針對(duì)2個(gè)主干網(wǎng)在用協(xié)議共生成10條響應(yīng)規(guī)則,HYDRA對(duì)這35條響應(yīng)規(guī)則生成的SDN流表項(xiàng)的處理日志見(jiàn)圖4。其中,面向123端口和53端口的規(guī)則測(cè)試時(shí)間為24 h,另外15條規(guī)則的測(cè)試時(shí)間是7×24 h,packet_count表示HYDRA系統(tǒng)攔截或者轉(zhuǎn)發(fā)的報(bào)文數(shù)。

圖4 UDP反射攻擊響應(yīng)情況統(tǒng)計(jì)結(jié)果

對(duì)于CharGen、SNMP、SSDP這3種主干網(wǎng)不在用協(xié)議,當(dāng)其報(bào)文出現(xiàn)在主干網(wǎng)上時(shí),一定是反射攻擊請(qǐng)求報(bào)文,因此對(duì)實(shí)驗(yàn)結(jié)果中此類報(bào)文沒(méi)有誤判的可能性。對(duì)于DNS和NTP這兩種主干網(wǎng)在用協(xié)議,HYDRA對(duì)其報(bào)文進(jìn)行轉(zhuǎn)發(fā)操作,供應(yīng)用程序作進(jìn)一步分析。應(yīng)用程序?qū)D4中轉(zhuǎn)發(fā)報(bào)文的處理結(jié)果如表1和表2所示,其中第1列為放大器IP地址。

表1 DNS轉(zhuǎn)發(fā)報(bào)文的處理結(jié)果

表2 NTP轉(zhuǎn)發(fā)報(bào)文的處理結(jié)果

由表1和表2可知,DNS和NTP轉(zhuǎn)發(fā)報(bào)文的90%以上均是丟棄報(bào)文,即反射攻擊請(qǐng)求報(bào)文,其余為回注報(bào)文,DNS協(xié)議和NTP協(xié)議的丟棄報(bào)文分別符合規(guī)則式(4)和規(guī)則式(5),根據(jù)上文分析結(jié)果,符合這兩條規(guī)則的報(bào)文若出現(xiàn)在主干網(wǎng)上,則為反射攻擊請(qǐng)求報(bào)文,因此不存在誤判的可能性。

由于DNS的回注報(bào)文數(shù)偏多,遠(yuǎn)大于NTP的回注報(bào)文數(shù),且其報(bào)文過(guò)濾規(guī)則更復(fù)雜,因此本文任意選取一條DNS回注報(bào)文記錄來(lái)查看其報(bào)文特征,判斷是否為正常通信報(bào)文,具體情況如圖5所示。

圖5 DNS回注報(bào)文記錄

由圖5可知,該DNS回注報(bào)文是由IP為49.80.*.123的主機(jī)發(fā)往IP為210.29.*.194的DNS放大器請(qǐng)求報(bào)文,請(qǐng)求查詢域名www.baidu.com對(duì)應(yīng)的IP地址記錄,屬于DNS正常通信報(bào)文,可以回注至主干網(wǎng)中。本文未進(jìn)行性能方面的測(cè)試,這主要是因?yàn)镠ydra平臺(tái)除了UDP反射攻擊響應(yīng)系統(tǒng)外,還同時(shí)支持其他系統(tǒng)的工作。從本文實(shí)現(xiàn)系統(tǒng)的角度出發(fā),由于響應(yīng)原理是面向請(qǐng)求報(bào)文而不是攻擊流量,因此本身就具有性能方面的優(yōu)勢(shì),算法時(shí)間復(fù)雜度為O(m),其中m是發(fā)往網(wǎng)內(nèi)請(qǐng)求報(bào)文的數(shù)量。

4 結(jié)束語(yǔ)

本文提出一種UDP反射攻擊自動(dòng)響應(yīng)方案。該方案基于SDN設(shè)備在網(wǎng)絡(luò)邊界使用流表,對(duì)發(fā)往已定位放大器的控制命令進(jìn)行攔截,在CERNET南京主節(jié)點(diǎn)網(wǎng)絡(luò)進(jìn)行5種反射攻擊協(xié)議的測(cè)試驗(yàn)證了該方案的有效性和可操作性。目前互聯(lián)網(wǎng)中大多數(shù)反射攻擊均由CharGen、DNS、NTP、SNMP、SSDP這5種類型的UDP反射攻擊協(xié)議產(chǎn)生,因此該方案如果在實(shí)際網(wǎng)絡(luò)環(huán)境中進(jìn)行應(yīng)用,則可以有效控制UDP反射攻擊。下一步將對(duì)更多的在用UDP反射攻擊協(xié)議進(jìn)行研究,如C-LDAP、Memcached等,探究基于軟件定義網(wǎng)絡(luò)的響應(yīng)方案。