DNS的RPZ安全防護系統(tǒng)的構建、配置與驗證①

戴云偉,沈春苗

1(江蘇省未來網絡創(chuàng)新研究院,南京 211111)

2(南京師范大學 商學院,南京 210023)

1 引言

DNS[1,2]是互聯(lián)網最重要、最基本的服務之一,提供了方便記憶的域名與復雜的IP 地址的相互映射.萬維網發(fā)展得如此迅速,離不開DNS 系統(tǒng)的廣泛應用.然而,隨著互聯(lián)網技術的不斷發(fā)展,DNS 因其協(xié)議設計的脆弱性,成為違法分子發(fā)動網絡攻擊的跳板,使互聯(lián)網在可用性、安全性及完整性等方面受到嚴重威脅.如何提供DNS 防護成為ISP (Internet service provider)及監(jiān)管機構的重要關切.

根據(jù)EfficientIP和IDC 共同研究發(fā)布的“IDC 2020 Global DNS Threat Report”顯示,2019年有79%的組織受到DNS 攻擊[3].DNS 不僅僅是黑客的攻擊的目標,同時也是其實施攻擊的重要手段.最常見的DNS 攻擊類型包括[4]:

(1) DNS hijacking,域名劫持.此類攻擊手段有多種,如攻擊者通過攻擊域名注冊系統(tǒng),獲得修改域名對應記錄的權限.一旦域名被劫持,攻擊者就可以通過篡改記錄,將用戶引導至病毒網址、釣魚網站等,從而獲得用戶的敏感數(shù)據(jù).2010年百度境外的DNS 服務器被攻擊,攻擊者修改了解析記錄,導致長達11 小時的服務中斷[5,6].

(2)DNS flood attack,泛洪攻擊.這是最基本的DNS攻擊類型之一,在這種分布式拒絕服務(DDoS)中,攻擊者將攻擊DNS 服務器.其主要目的為造成服務器過載,使其無法繼續(xù)為正常的DNS 請求提供服務[7,8].

(3)Distributed reflection denial of service,分布反射式拒絕服務(DRDos).DDoS 中的一種,此類攻擊最終目的就是使用大量數(shù)據(jù)包或者大量占用帶寬的請求使設備或者網絡過載,實現(xiàn)拒絕服務的目的.DRDos相較于DDoS的攻擊更為致命,該類攻擊將請求發(fā)送至正常的DNS 服務器,但是源地址為被攻擊者的,如此,被攻擊者將收到大量的無效響應報文,從而資源被耗盡[9,10].

(4)Cache poisoning,緩存投毒攻擊,最常見的DNS攻擊之一,一般利用系統(tǒng)漏洞,攻擊者嘗試向DNS 服務器的緩存中注入惡意數(shù)據(jù),以達到其將用戶重定向到另一個遠程服務器的目的[11,12].

(5)DNS tunneling,DNS 隧道攻擊,這是一種網絡攻擊,通過在DNS 響應和請求中包含惡意的應用數(shù)據(jù),當與DNS 服務器建立鏈接以后,攻擊者向服務器傳遞惡意數(shù)據(jù),以獲得控制權限[13,14].

針對DNS的攻擊,不少相關文獻進行了研究,如王文通等提到的從協(xié)議增強、系統(tǒng)增強、檢測監(jiān)控和去中心化的域名系統(tǒng)4 個方面來應對[15].郝帥等針對反射放大型DDoS 攻擊,同時對DNS、SNMP、SSDP、NTP、Memcache和CLDAP 這6 種協(xié)議存在的安全漏洞進行分析,從受害者和服務器兩個角度給出防范策略[16].Cooney 推薦使用CISA (cybersecurity and infrastructure security agency) 安全措施以緩解受到攻擊的威脅[17]等.

2017年5月,WannaCry 蠕蟲通過MS17-010 漏洞在全球范圍內感染了大量設備,該蠕蟲感染計算機后會向設備中植入勒索病毒,導致設備中大量文件被加密.受害者設備被黑客鎖定后,需要支付的一定價值的比特幣才可解鎖[18].而這一病毒有個關于域名的隱藏開關,通過RPZ 技術對特定域名的訪問進行干預,即可遏制病毒的進一步大規(guī)模傳播.

現(xiàn)今,無法通過某一種技術手段解決所有攻擊類型,結合RPZ 技術設計的防護系統(tǒng)在一定程度上可以防范和化解域名劫持、以及不法分子試圖通過DNS系統(tǒng),將用戶引至惡意站點.除此之外,系統(tǒng)還可以輔助ISP 控制未備案等不合法的站點被訪問.

2 防護系統(tǒng)需求分析

目前,多數(shù)ISP 或者銀行、電力等大型企業(yè)組織并沒有部署通過干預域名解析來提升DNS 安全的系統(tǒng),少數(shù)可能部署了域名黑名單解析功能.但是基本上都沒有部署自動化的解析干預系統(tǒng),結合運營商或者大型組織的實際情況,整個安全防護系統(tǒng)需要滿足以下必要功能.

(1)DNS 遞歸解析功能,最核心的功能,需要滿足ISP 用戶或者大型組織內部遞歸解析請求,該功能一般需要從13 個DNS 根服務器開始,遞歸訪問至授權服務器,獲取DNS 響應結果,并進行短時間的緩存.

(2)DNS 緩存功能,業(yè)內常見做法是將緩存與遞歸分開,該模塊直接接受用戶請求,優(yōu)先查找本模塊內部緩存,以響應用戶.無緩存的情況下,會將請求轉發(fā)給DNS 遞歸服務器.一般情況下,多臺緩存設備會轉發(fā)至一臺遞歸設備.

(3)DNS 安全防護功能,當系統(tǒng)檢測到有惡意的域名請求時,或者DNS 響應報文中含有惡意的IP 地址時.需要能夠根據(jù)用戶的設定返回特定結果,如返回NXDOMAIN,或者返回特定的IP 地址,將用戶重定向至警告頁面.

(4)綜合管理平臺,常規(guī)功能包含設備性能監(jiān)控、告警監(jiān)控等.核心功能要求協(xié)調所有設備之間的信息交互,進行統(tǒng)一管理,如數(shù)據(jù)收集、控制指令下發(fā)、控制指令反饋等.

3 DNS RPZ 技術原理

與傳統(tǒng)的提供DNS 解析功能的系統(tǒng)相比,構建RPZ 安全防護系統(tǒng),極大提高整個系統(tǒng)攔截惡意域名或者IP 地址的效率.

RPZ 由Paul Vixie 主導的ISC (internet systems consortium)機構于2010年提出,目前是IETF (Internet engineering task force)的互聯(lián)網草案[19].是一種針對DNS的網絡安全解決方案,可以防止互聯(lián)網用戶和系統(tǒng)訪問到已知的惡意域名或者IP,可以有效地預防威脅發(fā)生,通過阻止訪問受感染或者惡意的站點,進而阻斷進一步的安全威脅.能夠主動檢測到已被感染的用戶,并且防止病毒進一步擴散.圖1為用戶通過常用的通訊軟件收到包含惡意信息的鏈接場景下,RPZ 參與的工作過程.

圖1 DNS RPZ 工作原理圖

(1)不法分子通過電子郵件或即時通訊軟件,將包含惡意軟件或者域名的鏈接發(fā)送給用戶.

(2)用戶點擊收到的鏈接,終端設備首先要做的就是進行DNS 解析.將DNS 請求發(fā)送至DNS 解析服務器.

(3)具有RPZ 功能的DNS 解析服務器,向其他系統(tǒng)同步RPZ 規(guī)則,判斷當前請求解析的域名是否為惡意域名,或者解析到的IP是否為惡意IP,若是,則會進行干預,干預的結果則是由用戶下發(fā)的規(guī)則決定的.

(4)在RPZ的防護下,DNS 請求無法獲得正常結果,或者獲得由ISP 提供的警告頁面結果,從而成功阻止了用戶訪問惡意站點.

圖1中RPZ 規(guī)則下發(fā)階段的數(shù)據(jù),一般由ISP 通過多種方式進行收集,包括但不限于惡意域名檢測系統(tǒng)、被舉報的賭博網站、色情網站、釣魚網站以及其他被監(jiān)管機構禁止的站點.

4 防護系統(tǒng)構建

整個系統(tǒng)涉及多種類型設備,核心DNS 解析功能需要滿足負載均衡設計.系統(tǒng)總體結構如圖2所示,系統(tǒng)最基本組成部分共包含6 個子系統(tǒng),以及各子系統(tǒng)所需最小組成模塊.根據(jù)實際情況,可添加其他輔助系統(tǒng),如防火墻、入侵檢測系統(tǒng)等.子系統(tǒng)之間數(shù)據(jù)傳遞、控制指令下發(fā)都是通過局域網完成,只有緩存系統(tǒng)和遞歸系統(tǒng)需要接入互聯(lián)網.

圖2 系統(tǒng)總體架構圖

4.1 緩存系統(tǒng)

負責解析用戶的DNS 請求并完成響應,當接受到請求后,會首先查找本地系統(tǒng)是否已緩存過相應記錄且TTL 尚未過期,對于無法利用已有緩存完成響應的情況下,將請求轉發(fā)至遞歸服務器.

4.2 遞歸系統(tǒng)

一般只接受特定緩存服務器的請求,不直接對終端用戶開放,可以具備一定的緩存能力,但是緩存時間不宜過長.正常情況下,會從根服務器開始進行遞歸處理,直至到達授權服務器,獲取到用戶所需數(shù)據(jù).RPZ 模塊就是工作在該系統(tǒng)中.

4.3 日志系統(tǒng)

負責接收來自遞歸系統(tǒng)的DNS 請求響應日志,進行歸檔以便后續(xù)審計,同時負責將日志發(fā)送至其他系統(tǒng).

4.4 惡意站點檢測系統(tǒng)

該系統(tǒng)接受到DNS日志后,需要進行分析,當前針對惡意域名的檢測有不少相關論文,也有部分公司有償提供檢測到的惡意域名或者設備的地址,如DissectCyber 提供的RPZone.us 服務.

4.5 RPZ 系統(tǒng)

負責存儲所有規(guī)則,提供接口供其他系統(tǒng)動態(tài)更新規(guī)則,更新后,系統(tǒng)會通知遞歸系統(tǒng)獲取最新的規(guī)則數(shù)據(jù).遞歸系統(tǒng)本身也會定期查詢是否有規(guī)則數(shù)據(jù)變更.

4.6 綜合管理系統(tǒng)

負責所有系統(tǒng)的運行配置、監(jiān)控、規(guī)則下發(fā),向其他外部系統(tǒng)提供接口等.典型的應用就包括,惡意站點檢測系統(tǒng)一旦檢測到惡意域名或者IP,會向該系統(tǒng)提供的接口上報,由管理系統(tǒng)向RPZ 系統(tǒng)下發(fā)規(guī)則.

5 核心信息交互

RPZ的規(guī)則可以在請求到來之前進行預置,也可以通過前序的日志進行分析檢測得出.針對第一種預置的情況,當請求到達時,在遞歸系統(tǒng)就會被成功攔截.第二種場景下,前序請求會拿到惡意域名結果,但是后續(xù)請求會被攔截.

圖3為系統(tǒng)工作時,某特定場景下信息交互的時序圖示例.實際工作時,因系統(tǒng)分布式部署,可能存在的網絡數(shù)據(jù)丟失,導致接口調用超時,接口需要提供重試、異常處理的能力.

圖3 工作時序圖

6 配置及實驗驗證

實驗所使用的系統(tǒng)為Linux 系統(tǒng)(CentOS Linux release 7.8.2003),使用NSD 4.3.6 作為RPZ 系統(tǒng)的核心軟件,使用Unbound 1.13.1 作為緩存系統(tǒng)和遞歸系統(tǒng)的核心軟件.所使用的網絡拓撲圖,如圖4.

圖4 實驗網絡拓撲圖

6.1 系統(tǒng)配置

遞歸服務器內網地址配置為172.171.1.16/24.RPZ 服務器內網地址配置172.171.1.16/24.硬件CPU為Intel(R) Xeon(R) CPU E3-1225 v3 @ 3.20 GHz.內存為16 GB.

6.1.1 遞歸服務器的配置

Unbound 配置位于/etc/unbound/unbound.conf 中,部分核心內容如下:

01 server:02 interface:0.0.0.0@53 03 access-control:0.0.0.0/0 allow 04 logfile:"/etc/unbound/unbound.log"05 module-confi g:"respip validator iterator"06 rpz:07 name:rpz.test 08 master:172.171.1.15 09 allow-notify:172.171.1.15 10 zonefile:/etc/unbound/rpz.test.zone

第2 行表示在所有地址上監(jiān)聽端口53.第3 行表示不對源地址訪問控制.第4 行指示日志存儲位置.第5 行中的配置了rpz 所需要的respip 模塊.第6 行為rpz 模塊配置起始位置.第7 行表示rpz的zone 名稱為rpz.test.第8 行指示RPZ 系統(tǒng)的地址.第9 行表示允許RPZ 系統(tǒng)主動通知規(guī)則變更.第10 行表示同步到的規(guī)則文件會存儲在rpz.test.zone 文件中.

6.1.2 RPZ 服務器的配置

NSD 配置位于/etc/nsd/nsd.conf 中,部分核心內容如下:

?

第2 行表示日志文件位置,第3 行表示進程號文件存放位置.第4 行指示規(guī)則同步過程中,狀態(tài)文件的位置,該文件由軟件自動生成和維護.第6 行表示RPZ的zone 名稱為rpz.test,該名稱需要與遞歸系統(tǒng)中一致.第7 行指示規(guī)則文件存放位置.第8 行表示若規(guī)則變更時,會通知notify 配置的IP,可配置多行.第9 行用于進行同步控制,只有允許的遞歸服務器才能夠進行RPZ 規(guī)則同步.

6.2 攔截效果驗證

假設example.com 域名的子域名都為惡意域名.針對該域名進行多種常見場景的測試驗證.

6.2.1 RPZ 規(guī)則配置

/etc/nsd/rpz.test.zone 規(guī)則文件的配置如下,其中第11-13 行通過分號被注釋,修改此文件后,第4 行的序列號也需要修改,否則不會同步至遞歸系統(tǒng).

01 $ORIGIN rpz.test.02 $TTL 3600 03 @ IN SOA ns admin (04 2021042102;serial 05 3600;refresh (1 hours)06 600;retry (10 minutes)07 604800;expire (1 week)08 600;minimum (1 day)09)10 *.example.com CNAME.11;*.example.com CNAME *.12;*.example.com A 127.0.0.1 13;32.34.216.184.93.rpz-ip A 127.0.0.2

6.2.2 攔截域名,返回NXDOMAIN

啟用第6.2.1 節(jié)配置文件中的第10 行,注釋11-13 行.使用dig www.example.com @172.171.1.16 命令測試結果如圖5.

圖5 攔截域名,返回NXDOMAIN的測試結果

根據(jù)dig 顯示的結果表明驗證通過,終端得到的響應為NXDOMAIN.

6.2.3 攔截域名,返回NODATA

啟用第6.2.1 節(jié)配置文件中的第11 行,注釋10和12-13 行.使用dig 命令測試結果如圖6.

圖6 攔截域名,返回NODATA的測試結果

根據(jù)dig 顯示的結果表明驗證通過,終端得到的響應為NODATA.

6.2.4 重定向域名至特定IP

啟用第6.2.1 節(jié)配置文件中的第12 行,注釋10-11和13 行.使用dig 命令測試結果如圖7.

圖7 重定向域名至特定IP的測試結果

根據(jù)dig 顯示的結果表明驗證通過,終端得到的響應為127.0.0.1.

6.2.5 重定向惡意IP 至特定IP

啟用第6.2.1 節(jié)配置文件中的第13 行,注釋10-12 行.配置文件的中32.34.216.184.93.rpz-ip,其中,第1 個數(shù)字32 表示掩碼,34.216.184.93是www.example.com 真實解析IP 地址反序,其真實地址為93.184.216.34.rpz-ip為固定字段.第14 行的含義就是當遞歸響應結果中的地址為93.184.216.34/32 時,就被替換成127.0.0.2.使用dig 命令測試結果如圖8.

圖8 重定向惡意IP 至特定IP的測試結果

實驗結果符合預期,另外針對IP的NXDOMAIN和NODATA的實驗與第6.2.2 節(jié)和第6.2.3 節(jié)相似.

7 結論與展望

本文構建的DNS的RPZ 安全防護系統(tǒng),采用NSD和Unbound 等相關核心軟件,進行配置與實踐.驗證結果表明,系統(tǒng)對于防護用戶訪問到惡意域名或IP 效果較為明顯.具有良好的實際應用意義與技術參考價值.

系統(tǒng)所采用的檢測子系統(tǒng)是基于較常用的關鍵字識別.一個良好的規(guī)則庫,對于整個防護系統(tǒng)具有重要意義.現(xiàn)有不少組織已經開始有償提供規(guī)則庫,如何快速、有效地通過各種手段構建規(guī)則庫將是下一步的研究重點.