基于PKI的DNS安全防護研究

章 強, 彭 飛

(揚州職業大學, 江蘇 揚州 225009)

域名系統(以下簡稱DNS)是互聯網的核心基礎設施,它是一個分布式的分層數據庫,存儲A、MX、AAAA、CNAME等資源記錄。整個DNS被分為三層:根、頂級域名(TLD)和各級權威DNS服務器。DNS因此成為互聯網重要的基礎設施之一。也正是這個原因,DNS服務器一直是互聯網被攻擊的主要目標,攻擊方法如放大攻擊、緩存中毒攻擊、DDoS攻擊、DNS劫持等[1-2]。

DNS協議被認為是一種安全的通信協議,連接到互聯網的每臺計算機都信任從其所查詢DNS權威服務器收到的名稱解析結果。但是,DNS數據都是通過明文發送的,在一個遞歸名稱解析過程中,DNS查詢中的每次迭代引用都容易受到惡意攻擊。比如網絡攻擊者可以通過中間人攻擊等手段竊取DNS請求,用惡意記錄和正確的ID字段構建一個惡意的響應數據包,并在合法響應數據到達之前競相發送惡意響應,如果惡意記錄的生存響應延遲(TTL)再被設置為一個非常高的數值,那么受害者將在很長一段響應時間內緩存這些惡意域名解析記錄,導致終端客戶被引導訪問惡意網站。一個典型的案例是DNS Kaminsky攻擊[3],它實際上是利用截獲DNS消息中的查詢ID,采用中間人攻擊手段,使DNS解析器接受偽裝的DNS響應。

為了有效解決DNS安全防護的問題,互聯網工程任務組(IETF)開發了DNS安全擴展(以下簡稱DNSSEC)協議[4],DNSSEC采用非對稱加密機制來驗證記錄完整性和真實性。為實現DNS有效防護,每個區域必須至少提供下列三種記錄類型:(1)DNSKEY記錄。該記錄是公鑰,每個Zone區用相應的私鑰簽署DNS記錄,解析器使用DNSKEY來驗證這些簽名。Zone區通常創建兩個DNSKEY記錄(KSK和ZSK)來簽署DNS記錄:KSK的私鑰用于簽署DNSKEY記錄,ZSK的私鑰用于簽署所有其他記錄;(2)RRSIG(資源記錄簽名)記錄。它是使用DNSKEY對應私鑰簽署其他記錄的加密簽名;(3)DS記錄。它是由域名注冊商上傳到父區的DNSKEY的哈希值。為了確保完整性,DS記錄也需要由父區簽署(在DS記錄的RRSIG中)。

因此,只有當從根區到葉區都有有效的DS記錄時,DNSSEC才能正常運行,從而建立起一個信任鏈。圖1是一個三層信任鏈的模型(子區、父區和根區各擁有一個ZSK和一個KSK)。

圖1 基于信任鏈的DNS來源與完整性認證

因此,如果一個解析器被配置了像信任密鑰一樣的根區的KSK,它將能夠通過建立圖1這樣的信任鏈來檢查子區域的信息,實現DNS數據的來源、完整性驗證,確保了DNS消息來源的權威性和可靠性。

1 DNSSEC方案實際部署存在的問題

盡管DNSSEC設計了理論上近乎完美的DNS保護機制,它從1995年就開始發展,第一個DNSSEC已經被開發和標準化了二十多年,但其在互聯網上的實際部署率卻不理想,只有47%的ccTLDs(國家代碼頂級域)簽署了DNSSEC。[5]經過分析,筆者認為主要存在以下四個方面的問題:

1.1 各級權威區域服務器上密鑰管理成本高

在DNSSEC中,DNS響應的完整性是通過使用公鑰加密技術和數字簽名來保證的,因此權威服務器必須定期正確地維護(更換)私鑰和公鑰對。數量龐大的各層級權威服務器顯然需要高昂的維護成本。

1.2 DNS遞歸解析器DNSSEC驗證的計算負荷高

在一般情況下,DNSSEC驗證是在DNS全解析器上進行的,以便實際使用其緩存功能,因此DNSSEC驗證過程中復雜的密鑰計算也將大大增加DNS全解析器的工作負荷,從而導致域名解析性能的下降。

1.3 終端客戶沒有被DNSSEC覆蓋

由于DNSSEC驗證主要是在DNS全解析器上完成的,所以終端用戶電腦上的存根解析器并沒有被DNSSEC的安全名稱解析所覆蓋。在許多網絡環境的主機中,因為終端用戶操作系統的存根DNS解析器不支持DNSSEC,所以終端用戶不能使用DNSSEC,存在安全短板。

1.4 DNSSEC部署的存儲容量和帶寬成本上升

由于采用簽名認證機制,每個記錄都要有一個簽名記錄RRSIG記錄, DNSSEC需要傳輸這些非標準的DNS數據包,DNSKEY 和 RRSIG 記錄實際響應包長度均比標準 UDP 的DNS數據包(通常小于512 B)大很多。根據統計,Zone區數據一般要擴大10倍以上(具體實際數值與采用的密鑰長度關聯),相應的網絡流量肯定也要相應放大,過強的流量放大效應將更容易造成針對DNS的大規模DDoS 攻擊[3]。

2 基于CA證書的ProxyDNS的設計

針對DNSSEC部署存在的上述缺陷,如果嘗試在解析器之間使用一個不同的、外部的信任源(比如PKI),是否有可能在不依靠驗證證書鏈的情況下保證DNS域名解析服務事實上的安全性?筆者嘗試采用基于PKI 的外部CA證書的思路來解決DNS信任鏈的問題。

2.1 CA證書

公鑰基礎設施(PKI)是一個管理數字證書和公鑰加密的系統,PKI基于數字證書,它由證書機構(CA)頒發[6]。例如在PKI中最常用的X.509證書包括代表域名的通用名稱,一個公鑰。CA有它的根證書,根證書簽署次級證書。用戶可以用父級證書驗證子級證書,也同樣可以建立一個信任鏈[7]。

超文本安全協議(HTTPS)就是使用數字證書進行安全數據傳輸的一個例子。由一個特定的CA頒發的證書將給定的域名與證書受讓人、申請該證書的實體、證書有效期等信息結合起來,CA用于向瀏覽器證明網絡服務器代表了客戶所要求的域名,在成功認證后,瀏覽器和網絡服務器之間會建立一個TLS連接。隨著TLS連接的建立,瀏覽器和網絡服務器之間的通信將被加密,并防止任何第三方的竊聽。通過HTTPS,網絡服務器使用數字證書來加密他們與客戶之間的所有通信。根據谷歌統計[7],目前全世界大約96%的網頁都是通過HTTPS加載的。與DNSSEC相比,數字證書的部署率非常高。

2.2 基于CA證書的ProxyDNS設計思想

由于DNSSEC的層次結構,在父域部署DNSSEC之前,子域無法部署DNSSEC。此外,其上傳DS記錄的過程中,一些子域名服務器忘記上傳DS記錄或上傳錯誤,大約30%的簽名域名在其父區沒有DS記錄。而本文所提出解決方案的關鍵思路是驗證記錄而不是上傳DS記錄,ProxyDNS使用基于PKI的CA數字證書,而不是信任鏈。在DNSSEC中,名稱服務器中的記錄是由ZSK簽署的。這些ZSK再由KSK簽署。KSK以DS記錄的形式上傳到父域。這就形成了一個從記錄到根KSK的信任鏈。

而在ProxyDNS中,名稱服務器用他們自己的證書簽署記錄,這些證書由基于PKI的CA頒發。ProxyDNS不需要向父區上傳任何記錄。

筆者使用CA證書來驗證數據的完整性,而不是使用DS記錄。每個權威名稱服務器用CA頒發給它的數字證書來簽署他們的記錄。每個記錄的信任錨移到他們的CA上,消除了DNSSEC中父域、子域之間的依賴性。在這個場景中,記錄驗證過程如下:(1)權威名稱服務器擁有由CA頒發的數字證書,并用證書的私鑰生成記錄的簽名;(2)當ProxyDNS代理(或解析器)收到查詢時,代理客戶請求DNS查詢記錄、生成簽名和證書。在證書鏈被驗證后,公鑰被從證書中提取出來并被緩存,如果驗證有效,則將記錄發送給客戶。

2.3 ProxyDNS程序工作過程

ProxyDNS作為一個代理程序在終端用戶機器上運行?？蛻舳瞬恢涝摯淼拇嬖?并像往常一樣向DNS解析器發送請求。代理程序會截獲該查詢請求,并將其發送給DNS解析器。ProxyDNS代理驗證了這些記錄,然后將查詢的答案再發送給終端用戶?？蛻舳舜淼膶崿F也滿足了向后的兼容性,保證了端到端的DNS安全性。

由CA頒發給權威名稱服務器的證書被用于DNS記錄驗證,由于簽名是通過使用證書的私鑰產生的,代理通過使用配對的公鑰來驗證DNS記錄,為了讓代理接觸到證書,該證書必須作為記錄存儲在權威名稱服務器中。根據RFC4398,數字證書可以被儲存為一條記錄,這里取名為CERT記錄,其結構主要包括:主機名、記錄類型、證書類型、密鑰標簽、用于生成證書的算法類型、TTL、以及用Base64編碼的證書。

在生成簽名的情況下,使用TXT記錄。在ProxyDNS中,為每個RRset生成簽名,類似于DNSSEC的RRSIG簽名[7]。例如,為A記錄RRset創建一個簽名,首先使用SHA256函數創建一個摘要。如果有多條A記錄,每條記錄被連接成一個字符串,中間用冒號分隔,然后生成一個摘要。有了這個摘要,采用OpenSSL證書的私鑰為A記錄創建一個簽名。最后,簽名用Base64進行編碼,作為TXT記錄上傳。由于TXT記錄有255個字符的限制[4],簽名被分成200個字節,并與包含簽名所屬記錄信息的頭部一并存貯。

當收到來自客戶端的查詢時,代理按圖2順序操作。

圖2 ProxyDNS記錄驗證的流程

第一步:創建一個查詢,獲取記錄(這里是TXT記錄)的簽名。在獲取TXT記錄后,代理找到帶有ProxyDNS頭的字符串,然后解析TXT記錄并重建簽名,最后代理得到了記錄的簽名;第二步:檢查緩存。如果記錄的公鑰被緩存了,代理就會加載緩存的公鑰,如果沒有緩存,則創建一個CERT記錄的查詢來獲取CERT記錄。當CERT記錄被獲取時,它的證書鏈被驗證,并且公鑰被從CERT記錄的證書中提取,公鑰被緩存在代理處。第三步:驗證該記錄。利用重建的簽名和證書中的公鑰,對記錄進行驗證。

3 ProxyDNS的實現

按照這個ProxyDNS代理的設計思路,筆者使用C語言開發了一個原型程序,搭建了一個仿真測試環境。

3.1 ProxyDNS原型系統實現

假設驗證“www. yzpc-dns-test.com”的A記錄?？蛻舳讼裢Ｒ粯影l送DNS查詢?？蛻舳诉\行“dig www. yzpc-dns-test.com/A”命令。這個請求被轉發給代理,代理向本地解析器請求一個相應的A記錄。然后返回“www. yzpc-dns-test.com”包含其 IP 地址的 A 記錄。

在獲取A記錄后,對TXT記錄的查詢被發送到解析器。檢查已經收到的TXT記錄,找到帶有ProxyDNS頭的字符串。例如,A記錄的頭部看起來像 “ProxyDNS-Base64-A-1”“ProxyDNS-Base64-A-2”“ProxyDNS-Base64-A-n”等。對頭文件進行解析,重建簽名,并通過Base64進行解碼,最后,使用SHA256算法生成IP地址的摘要。

在重構簽名后,檢查緩存。由于最初沒有任何緩存,緩存沒有命中,相應記錄的CERT記錄被ProxyDNS查詢到,該證書位于該記錄的權威DNS服務器上。如果“www. yzpc-dns-test.com”的權威名稱服務器是“ns. yzpc-dns-test.com”,就會向“ns. yzpc-dns-test.com”生成新的CERT記錄查詢。當從本地解析器獲取“ns. yzpc-dns-test.com”的CERT記錄時,首先對證書鏈進行驗證。假設根證書和中間證書都存儲在客戶端,證書鏈將使用OpenSSL進行驗證。當證書鏈被確認后,ProxyDNS檢查證書的公共名稱是否為“ns. yzpc-dns-test.com”。這是因為需要檢查該證書是否是用于記錄驗證的正確證書。當證書的驗證完成后,使用OpenSSL從證書中提取公鑰并進行緩存,公鑰被緩存為一個文件。

有了摘要、公鑰和簽名,記錄就可以用OpenSSL進行驗證。當驗證完成后,返回客戶端的響應。

3.2 ProxyDNS仿真環境搭建

在數據中心私有云上安裝一個DNS解析器虛擬機,使用Bind9來刷新緩存。從域名服務商注冊“yzpc-dns-test.com”域名用于權威服務器的記錄管理?！皔zpc-dns-test.com”區的權威名稱服務器也使用Bind9安裝在數據中心私有云虛擬機上。

4 ProxyDNS與DNSSEC的對比分析

從響應延遲、存儲消耗開銷的角度對ProxyDNS和DNSSEC進行比較。

4.1 響應時間

為了比較DNSSEC和ProxyDNS的響應延遲開銷,使用“dig”命令測量解析響應延遲,客戶端收到查詢響應的響應延遲。使用“dig”命令發送了對A記錄的查詢,在正常情況下,它是在關閉ProxyDNS和DNSSEC功能的情況下測量的。在開啟DNSSEC的場景下,它是在關閉ProxyDNS功能的場景下設置了DNSSEC后測量的。在啟用ProxyDNS的場景下,它是在關閉DNSSEC并只使用ProxyDNS的功能時測量的。響應延遲數據分別是三種場景各測量20次的結果平均值(見表1)。

表1 DNS、DNSSEC和ProxyDNS響應時間比較 單位:s

在沒有任何安全擴展的情況下,A記錄的解析響應延遲約為0.21s。當部署了DNSSEC后,解析響應延遲增加到約0.46s,幾乎慢了2倍多。在采用ProxyDNS的情況下,解析響應延遲約為0.28s,幾乎比DNSSEC快40%。

4.2 存儲消耗

為了比較DNSSEC和ProxyDNS中父區的存儲消耗開銷,可查看每個系統中使用的記錄(見表2)。RRSIG和TXT記錄的比較被排除在外,因為DNSSEC和ProxyDNS都是用相同的方法來生成和管理簽名。

表2 DNSSEC和ProxyDNS存儲消耗比較

當使用DNSSEC時,會生成一個DNSKEY記錄,并以DS記錄的形式上傳到父域。在一個權威服務器中,DNSKEY的開銷不大,但在必須存儲DS記錄的父域(如TLD)中,存儲消耗開銷很大。根據statdns[8],在“.com”域中大約有440萬條DS記錄被上傳。假設所有這些DS記錄都是用SHA-256算法上傳的,計算下來相當于300MiB左右。而在ProxyDNS中,上傳DS記錄的過程是不需要的,所有的DS記錄都可以用一個CERT記錄代替。一個CERT記錄僅占2KiB,與使用DS記錄相比,可以將存儲消耗開銷降低到DNSSEC方案的0.0008%。

5 結語

文章分析了目前作為DNS防護主要解決方案DNSSEC部署率過低的原因,研究得出DNSSEC的分層結構中證書鏈驗證開銷過大是DNSSEC部署率偏低的一個主要因素。提出了通過減少證書鏈簽名驗證的數量,將大部分的計算、帶寬、存儲開銷成本盡可能降低的思路來克服DNSSEC目前實際部署存在的困難。筆者開發的基于PKI的ProxyDNS原型程序,在沒有分層證書驗證的情況下提供了DNS查詢數據的完整性和真實性驗證,使用PKI公鑰基礎設施中的CA數字證書進行數據驗證,由于不需要向上層域上傳記錄,因此可以消除證書鏈的層次結構。最后測量ProxyDNS響應延遲和數據存儲開銷。仿真測試結果表明:與DNSSEC方案相比,可以用很少的額外開銷來維持DNSSEC幾乎同等的DNS安全水平,特別在性能方面比DNSSEC有明顯的提升,可以作為實現DNS安全的一個輕量化解決方案。