2017年5月15日 星期一

DNSSEC安全技術簡介

作者:游子興 / 臺灣大學計算機及資訊網路中心網路組約聘幹事

DNS 是一套已經廣泛使用的Internet 服務,但因先天的技術限制導致容易成為駭客攻擊的目標。本文主要在介紹DNSSEC 之緣起與技術背景,及其使用的加解密技術如何確保資料的完整性與來源可驗證性等,第二部分將介紹 DNSSEC 之實作與需特別注意之細節,將留待下回分解。
DNSSEC 之緣起與技術背景 DNS(Domain Name System)是所有人在 Internet 漫遊都會用到的技術,大部分的人都知道 google 的網址是 www.google.com , Yahoo 的網址是 www.yahoo.com。但應該沒有多少人知道 www.google.com 或 www.yahoo.com 的 IP 位址,若用指令查詢,會發現不止一個 IP 對應到 www.google.com
還好有了 DNS 的技術在背後幫忙將網址轉換為 IP 位址,因此大家才不需要記住這些個數字。
DNS 技術創立於 1980年代,在當時資訊安全並不是一項重要議題,因此存在許多先天的資安弱點。例如在 DNS 的查詢與回應中皆未加密,若有駭客在其中假造 DNS 封包,將使用者原先要連到的網址,回應錯誤的 IP而導向駭客的機器,其中可能因為網站內容看起來一模一樣,而騙到使用者之帳號密碼。
例如在 2011/09 土耳其的駭客組織 TurkGuvenligi 入侵 DNS 主機修改了超過 200個網站之 IP,許多知名網站如 UPS (ups.com), NGC (nationalgeographic.com) 還有國內的資訊大廠 Acer (acer.com)皆受其影響而直接導向駭客的機器,此種攻擊方式不論上述廠商投資了多少防火牆、資安設備等皆無法抵擋,因此該如何確保連上的網站就確實是該網站呢?

(圖片來源:http://www.ehackingnews.com/2011/09/theregistercouk-vodafone-daily.html )
DNSSEC 提供之資訊安全 此時就需要 DNSSEC (DNS security extension standard),DNSSEC 的優點在於可完全兼容於現行的 DNS,更額外提供三項資訊安全:
1.資料完整性 (data integrity)
2.來源可驗證性 (origin authentication of DNS data)
3.可驗證之不存在性 (authenticated denial of existence)
上述三項技術使用了雜湊函式(Hash Function)與公開金鑰加密(Public-key cryptography) 之技術。
雜湊函式是把資料壓縮成一組驗證值(Hash Value),使得資料量變小且固定。雜湊函式是多對一的(失真的)映射,故無法由其輸出值計算出原本的輸入訊息,因為是多對一的,故存在許多訊息其映射值是相同的。

(圖片來源: http://zh.wikipedia.org/wiki/Hash )
雜湊函式的特性是產生的值與輸入的資料息息相關,原資料些微的變動皆會導致極為不同的輸出結果,其演算法需確保有相同映射值,但訊息內容不同的機率極低,此機率一般是決定於映射值的長度,其位元數越多,可映射的範圍越大、重複的機率越低。常見的雜湊函式有:RSA公司的MD2、MD4、MD5及NIST的SHA。
公開金鑰加密又名非對稱式(asymmetric)加密,其特色是利用加密及解密時須使用兩組成對的鍵值(鑰匙),習慣上將其中的一組鍵值稱作私有鑰匙(Private Key),由個人妥善保管,而另一組稱為公眾鑰匙(Public Key),公佈給大眾可供下載。這樣作的好處是,當大眾中某人X欲傳送資料給某人A時,X可先將資料以A的公眾鑰匙加密之後再傳給A,A收到之後再以其私有鑰匙解密,因為A的公眾鑰匙眾所週知,故眾人皆可用它加密之後傳送給A,而僅A持有私有鑰匙,故任何第三者皆無法解讀A的資料。

(圖片來源:http://www.pgpi.org/doc/pgpintro/)
另一種常見的公私鑰匙加密的應用是數位簽章,例如某用戶A剛完成了一封電子信件,A根據該信件的內容使用雜湊函式產生一組驗證值(Hash Value),接著以自己的私有鑰匙對該驗證值加密、產生一組數位簽章,並將該簽名附於信末,之後寄出給B。
B收到信後先利用A的公眾鑰匙解開該信的數位簽章,若順利無誤,B即可確定該信的確是來自A,接著B使用同樣的雜湊函式計算該信的驗證值,若發現與先前公眾鑰匙解開的數位簽章內附的值相同,表示該信內容未遭竄改。上述的數位簽章的功能證明了三件事:
信件來源確實是A
信件內容沒有遭竄改
發信人A無法否認曾發過信

(圖片來源:http://sna.csie.ndhu.edu.tw/~cnyang/HA/sld001.htm)
在瞭解了雜湊函式(Hash Function)與公開金鑰加密(Public-key cryptography) 之技術後,接著回到 DNSSEC 提供之三項資訊安全技術:
1.資料完整性(data integrity): 
DNSSEC使用數位簽章的技術,將每筆 RR做簽章產生RRSIG (Resource Record Signature),而收到資料方可使用 Public Key + RRSIG來驗證是否為原本詢問之 RR 紀錄,以此來驗證中間是否有被竄改。這把 Public Key 在 DNSSEC 中又稱為 DNSKEY。
原始 Zone file 之內容:
使用 DNSSEC 將 Zone file 加上數位簽章後之內容:
可看到原本每筆 RR(Resource Record)之後多了一個新的 type: RRSIG (Resource Record Signature),如上圖紅色框框,就是使用 2048bit Key 數位簽章之結果。
2.來源可驗證性 (origin authentication of DNS data): 
在數位簽章的概念中,當資料完整性被驗證後,我們已經可以確認資料未被竄改,而且確實由負責該 Domain 之 DNS Server 提供,但我們該如何驗證該 Domain 之 DNS Server 確實是真實的而非駭客自行架設的 DNS Server。
在個人的數位簽章中,通常需將個人的 Public Key 交由公正的第三方加以驗證,也就是這把 Public Key 確實代表我個人。
而在 DNSSEC 中,所謂的公正的第三方就是上層的 Domain DNS Server,也就是 DNS Server 必須將自己的 Public Key (DNSKEY) 做一次數位簽章後放在 Parent Zone Server,這種新的 RR(Resource Record) types 稱為DS(Delegation Signer),因此由 Parent Zone 中的 DS 紀錄可驗證 Child Zone之 DNSKEY 確實是正確且未經竄改。
也就是當我們相信 Parent Zone 的機器時,就可以信任 Child Zone 所詢問而得到的 DNS 結果,而又該如何相信 Parent Zone 呢? 就是相信 Parent of Parent Zone,如此層層認證,最後僅要我們相信 root zone,整個 DNS 信賴鍊就可完整構成。root Zone 因有專人負責管理,理論上應該不易被駭客入侵。

(圖片來源:http://www.twisc.nctu.edu.tw/)
3.可驗證之不存在性(authenticated denial of existence)
當我們任意 ping 一個網址 www.abcdexyz.com ,系統回應 unknown host,我們該如何相信這個網址確實不存在,還是中間有駭客假造回應不存在之封包訊息,故意讓我們連不上此網頁。
針對此狀況,DNSSEC 也想出了一套解決辦法。也就是將所有 DNS 紀錄依照字母排序,而在每個網址間加上一筆 NSEC 紀錄並做電子簽章。

(圖片來源:http://www.twisc.nctu.edu.tw/)
也就是當查詢到不存在的網址時,DNSSEC 會回應 NSEC 紀錄,查詢者可比對NSEC 紀錄中前後對應的字母來確認是否真的不存在,這就是所謂的”可驗證之不存在性”。
DNSSEC之限制: 上述說明了 DNSSEC 所帶來的資訊安全優點,但DNSSEC 也不等於就是固若金湯而能阻擋所有攻擊,且由於相容於 DNS,而有兩項弱點:
(1)隱密性(Confidentiality)DNSSEC 傳遞的 RR & 及RRSIG 傳輸過程皆未加密,因此中間可能被sniffer 之設備或程式讀取。但被讀取不代表能假造,因為駭客並無 DNS Server 之 Private Key,因此無法假造出 RRSIG 的資料而不被發覺。
(2)服務可用性(Availability)
DNSSEC 僅是一項服務,若有駭客發動DDoS 攻擊,不斷的詢問成千上萬個網址,則 DNS Server 可能因負荷過重而無法正常運作。不過這項弱點應是所有 Internet 服務皆共有的現象,而不單是 DNSSEC 之弱點。
以上介紹了 DNSSEC 之運作原理,下一篇將介紹DNSSEC 之實作與需特別注意之細節,敬請期待。
 

How to use simple speedtest in RaspberryPi CLI

  pi@ChunchaiRPI2:/tmp $  wget -O speedtest-cli https://raw.githubusercontent.com/sivel/speedtest-cli/master/speedtest.py --2023-06-26 10:4...