從安全的角度看待DNS

Mysticbinary發表於2020-07-20
DNS

以前對DNS(Domain Name System)認識就大概的知道是一個提供域名解析服務，作為網際網路的基礎設施，任何一個IT人員都會或多或少都接觸到DNS，隨著我最近的接觸不斷提高，我發現DNS還是有很多細節技術需要認識和把握的，本文以一箇中型網際網路企業搭建域DNS伺服器架構為基礎，從安全的角度看待DNS進行描述，都是一些經驗之談，希望讀者能有所收穫。


DNS協議

DNS通過開放53埠，通過該埠來監聽請求並提供響應的服務，DNS 監聽 TCP 和 UDP 都是 53 埠。如果攻擊人員在掃描主機埠的時候發現一臺主機開放了53埠，那麼就可以判斷這是一臺DNS伺服器，並且對外了。對外開放53埠，也就意味著執行外部對這臺DNS伺服器進行安全掃描，如何進行安全掃描，DNS會有哪些安全問題，後面會說。

出於效能的考慮，DNS查詢請求用UDP協議互動並且每個請求的大小小於512位元組，但是如果返回的請求大小大於512位元組，互動雙方會協商使用TCP協議。


DNS查詢

說完DNS的埠，那就接著說DNS的服務，DNS提供出來的就是域名解析服務（將域名轉換為IP地址的過程），這個服務是怎麼實現域名解析服務的？我說一下大概查詢過程（如下兩張圖）

假設你想訪問 sspai.com 這個網站，那麼就如走這個流程

  • 先問 客戶端（本地主機）DNS伺服器
  • 再問 區域性（區域網）DNS域伺服器
  • 再去問 根域名
  • 最後問 頂級域名伺服器

如果使用類linux系統，可以使用 dig 命令來顯示整個分級查詢的過程，

➜  ~ dig +trace sspai.com

; <<>> DiG 9.10.6 <<>> +trace sspai.com
;; global options: +cmd


# 第一段列出根域名.的所有NS記錄，即所有根域名伺服器。
.			3600	IN	NS	d.root-servers.net.
.			3600	IN	NS	k.root-servers.net.
.			3600	IN	NS	j.root-servers.net.
.			3600	IN	NS	a.root-servers.net.
.			3600	IN	NS	b.root-servers.net.
.			3600	IN	NS	e.root-servers.net.
.			3600	IN	NS	f.root-servers.net.
.			3600	IN	NS	h.root-servers.net.
.			3600	IN	NS	c.root-servers.net.
.			3600	IN	NS	i.root-servers.net.
.			3600	IN	NS	g.root-servers.net.
.			3600	IN	NS	l.root-servers.net.
.			3600	IN	NS	m.root-servers.net.
;; Received 472 bytes from 10.249.150.1#53(10.249.150.1) in 1 ms


# 接著詢問sspai.com的頂級域 com.的NS記錄
com.			172800	IN	NS	b.gtld-servers.net.
com.			172800	IN	NS	f.gtld-servers.net.
com.			172800	IN	NS	l.gtld-servers.net.
com.			172800	IN	NS	c.gtld-servers.net.
com.			172800	IN	NS	d.gtld-servers.net.
com.			172800	IN	NS	j.gtld-servers.net.
com.			172800	IN	NS	a.gtld-servers.net.
com.			172800	IN	NS	e.gtld-servers.net.
com.			172800	IN	NS	h.gtld-servers.net.
com.			172800	IN	NS	g.gtld-servers.net.
com.			172800	IN	NS	i.gtld-servers.net.
com.			172800	IN	NS	k.gtld-servers.net.
com.			172800	IN	NS	m.gtld-servers.net.
com.			86400	IN	DS	30909 8 2 E2D3C916F6DEEAC73294E8268FB5885044A833FC5459588F4A9184CF C41A5766
com.			86400	IN	RRSIG	DS 8 1 86400 20200801170000 20200719160000 46594 . nl6GGtQwgNAf1YLcWFFcQyXZ1BE/E5dhOVVBIxTCl0QNtvt9sb+btQIM NOVpc6JovoxxfXvDxotRmCqVe9BJunaZvCqMGySy8JdFTcSo1kdVKXvU nI+b3mad5ROgvP2GaUZelhRIn7++FIQAjSUl40H/jdaQP2fxXDH1PQ4B oBhQwnlDo/rn3AJxhH+P2hx/23fadNwsmh/WY9truU1Gv4cf+uwAPkE9 QFSKDcDF7VgTF1bHN9A9nuURQXIjGQkZAGUHaR9bIrKtgYDa3szrmdOJ GejllYy4VyKoBxwZLkV+W7gt+ODYXxAz42UFk5VOGF560wfCIM11FSYR +XPqPg==
;; Received 1169 bytes from 192.36.148.17#53(i.root-servers.net) in 65 ms


# 詢問sspai.com的次級域名 NS記錄
sspai.com.		172800	IN	NS	dns17.hichina.com.
sspai.com.		172800	IN	NS	dns18.hichina.com.
CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 86400 IN NSEC3 1 1 0 - CK0Q1GIN43N1ARRC9OSM6QPQR81H5M9A  NS SOA RRSIG DNSKEY NSEC3PARAM
CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 86400 IN RRSIG NSEC3 8 2 86400 20200724044108 20200717033108 24966 com. Tf4OQOpeShS1V8R5W7+YWbLa+iIn/wJf3iDfMsHf4P7TJ1ZBm+1EC4FB bdE2Xcyi9wFIetecgTseEQGLYEKdwUBx6mqGmR3nHMaRDl+4Sm+hBufD UUR+2sGFNM/KMWC5zgm7nLc4wHBSrsq8T36nache8cXBhEWSEvR+MIGw o1fJdUNWhihU/maM05P4wrigqDw5igwIkDZZ1O3Fz5uwnQ==
M34OU778JRD89U2DUUTAAI48T6FEI7CV.com. 86400 IN NSEC3 1 1 0 - M34P2GDRCOK7PL50LT2A785I7P76KSGS  NS DS RRSIG
M34OU778JRD89U2DUUTAAI48T6FEI7CV.com. 86400 IN RRSIG NSEC3 8 2 86400 20200725051418 20200718040418 24966 com. Fis/2uVliOd9QYjFtzH0SVeSU4lAtekdPXOlqU5Zp+IxDXOovSM31wmL YD9zQRdfecDoiurSZi/yZceE2HxgWyWDc1epW7gTQYGOr99s7dxA08dm +gZZIExIIYNpc1MzSqktmLQuOg9yyUQwyf1YWCrQF8d+e3/fdPxFBunf j2psiF3BKzhPt5tlzfx98Gu8pckCBk9pV3xFXCAv5Vx0/A==
;; Received 947 bytes from 192.41.162.30#53(l.gtld-servers.net) in 177 ms


## 查詢到有一條A記錄，通過這個IP(119.23.141.248) 地址就可以訪問到這個網站
sspai.com.		600	IN	A	119.23.141.248
;; Received 54 bytes from 140.205.41.28#53(dns18.hichina.com) in 31 ms

而具體實現這個查詢過程的技術有

  • 遞迴查詢
  • 迭代查詢
  • 反向查詢

這裡的每種查詢技術都不簡單，迭代、遞迴查詢也是實現DNS服務的核心，但不是我這篇文章想講述的重點，所以忽略。想了解細節的可以自己查詢一下網路資料，反向查詢有挺多安全知識的，我就單獨寫成一篇文章了：https://www.cnblogs.com/mysticbinary/p/13344930.html

查詢的技術細節可以不用關心，但是常見的DNS記錄型別還是要關心的：

A：地址記錄（Address），返回域名指向的IP地址。
AAAA ：A 記錄處理 IPV4，AAAA 處理 IPV6。

SOA ：起始授權機構記錄，SOA 備註說明了眾多 NS（name server）記錄中誰是主名稱伺服器，不參與功能，但是不能缺少。
NS：域名伺服器記錄（Name Server），返回儲存下一級域名資訊的伺服器地址。該記錄只能設定為域名，不能設定為IP地址。

MX：郵件記錄（Mail eXchange），返回接收電子郵件的伺服器地址。

CNAME：規範名稱記錄（Canonical Name），返回另一個域名，即當前查詢的域名是另一個域名的跳轉（類似302跳轉）。

PTR：逆向查詢記錄（Pointer Record），只用於從IP地址查詢域名。

答應我！下次你在看到A、AAAA、SOA、NS、MX、CNAME、PTR一定要一秒之內想出他們是幹嘛的。因為太重要了。
答應我！下次你在看到A、AAAA、SOA、NS、MX、CNAME、PTR一定要一秒之內想出他們是幹嘛的。因為太重要了。
答應我！下次你在看到A、AAAA、SOA、NS、MX、CNAME、PTR一定要一秒之內想出他們是幹嘛的。因為太重要了。

從安全的角度上看，為了保證服務的安全可靠，至少應該有兩條NS記錄，而A記錄和MX記錄也可以有多條，這樣就提供了服務的冗餘性，防止出現單點失敗。


域維護

因為DNS服務就是一個類似分散式的服務，分散式就是分散的，如何保證各個分散的機器能及時的同步訊息呢？在主域名伺服器和從域名伺服器之間維護同一個zone檔案。可以簡單的理解為，DNS設定一個協議來在主域名伺服器和從域名伺服器之間維護同一個zone檔案。主要有以下兩種同步的手段有：

  • 全量傳輸 AXFR (full zone transfer)
    就是設定一個固定時間（比如2分鐘一次），就同步一次zone檔案
  • 增量傳輸 IXFR (incremental zone transfer)
    傳遞非常大的zone檔案是非常耗資源的（時間、頻寬等），尤其是隻有zone中的一個記錄改變的時候，沒有必要傳遞整個zone檔案，增量傳輸是允許主域名伺服器和從域名伺服器之間只傳輸那些改變的記錄。

ZONE檔案是DNS上儲存域名配置的檔案，一個域名對應一個ZONE檔案。

如果你的企業區域網只有一臺DNS伺服器，那麼就不需要AXFR、IXFR

如果你的企業區域網有多臺DNS伺服器，那麼就需要AXFR、IXFR

做DNS監控，就會用到ES技術，通過記錄，你會發現你記錄的DNS伺服器clientIp為127.0.0.1，並且在固定週期就會傳輸AXFR型別的Domain。


DNS安全

DNS本身的DNS服務漏洞、區域轉發配置錯誤、找真實IP繞過WAF等，都是常見的DNS安全，今天就到這把，後續有精力在寫了.....


參考

http://www.ruanyifeng.com/blog/2016/06/dns.html
https://www.cnblogs.com/cobbliu/archive/2013/03/24/2979521.html
https://www.cnblogs.com/bluestorm/p/10345334.html
https://www.cnblogs.com/Dy1an/p/11157152.html

相關文章