丁 偉,張千風,周文烽

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

0 概述

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

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

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

1 UDP反射攻擊的檢測與響應

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

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

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

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

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

2 基于SDN的反射攻擊響應

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

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

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

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

[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分別對應的語義是源地址、源地址掩碼長度、源端口、目的地址、目的地址掩碼長度、目的端口、協(xié)議號(17表示UDP,6表示TCP)、響應規(guī)則提交時間、響應規(guī)則執(zhí)行持續(xù)時間和執(zhí)行動作,如“轉(zhuǎn)發(fā)”和“丟棄”。

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

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

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

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

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

2.3 響應方案

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

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

1)對所有主干網(wǎng)不在用協(xié)議,采用文獻[3]的ACL攔截規(guī)則和“丟棄”操作生成流表項進行響應,從流量中過濾反射攻擊請求報文。流表項對應式(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,表示任意端口號,dst_ip字段為amp_ip,表示放大器IP地址,dst_port字段為amp_port,表示放大器提供的主干網(wǎng)不在用協(xié)議服務端口,ip_protocol=17表示使用UDP協(xié)議,hard_time=0表示響應規(guī)則執(zhí)行沒有時間限制,該響應規(guī)則對應的流表項只能由用戶主動撤銷。

2)對所有主干網(wǎng)在用協(xié)議,將所有向放大器發(fā)出請求的報文,利用OpenFlow交換機的轉(zhuǎn)發(fā)操作,將其發(fā)送給一個在后臺運行的應用程序,這個程序?qū)笪呢撦d進行分析來確定是否為攻擊請求報文。如果不是,則將其“回注”到流量中。對應的流表響應規(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é)議服務的端口。當符合轉(zhuǎn)發(fā)流表項的報文被轉(zhuǎn)發(fā)到后臺運行的應用程序后,后臺應用程序會根據(jù)不同的反射協(xié)議對其應用不同的過濾規(guī)則進行“丟棄”或者“回注”操作。

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

整個響應方案如圖2所示,具體流程為:

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

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

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

圖2 響應方案設(shè)計流程

2.4 報文過濾規(guī)則

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

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

monlist=1

(4)

對于DNS而言,根據(jù)相關(guān)研究,筆者認為導致反射攻擊的報文應具有以下特征:

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

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

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

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

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

domain∈DNSSEC & & RR=ANY & &

EDNS0=1 & & RD=1

(5)

3 響應方案實現(xiàn)與實驗結(jié)果

3.1 響應方案實現(xiàn)

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

3.1.1 HYDRA和NBOS系統(tǒng)

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

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

由于NBOS系統(tǒng)能夠提供CharGen、DNS、NTP、SNMP、SSDP這5種類型的UDP反射攻擊協(xié)議的放大器信息,因此面向這5種協(xié)議進行測試[19-20]。其中的NTP和DNS屬于主干網(wǎng)在用協(xié)議,采用式(4)和式(5)兩條規(guī)則進行響應,另外3個屬于主干網(wǎng)不在用協(xié)議,使用規(guī)則式(2)進行響應。因此,需要提交給HYDRA系統(tǒ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表示響應規(guī)則提交時間,該字段由HYDRA系統(tǒng)根據(jù)響應規(guī)則接收的時間自行設(shè)置。

3.1.2 基于NBOS與HYDRA平臺的實現(xiàn)

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

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

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

3.2 實驗結(jié)果

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

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

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

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

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

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

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

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

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

圖5 DNS回注報文記錄

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

4 結(jié)束語

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