from:http://securityintelligence.com/analyzing-queries-on-a-honeypot-name-server-for-better-dns-log-quality/

0x00 網路雜訊

---

“蜜罐”是統計“網路雜訊”的一種常用方法，並且這種方法也比較簡單。你對“網路雜訊”瞭解的程度越高，那麼你就能更好地做安全分析。 我好奇的是，在公有云上，NS蜜罐能接收哪些流量；我的研究如下：

0x01 設定NS蜜罐

---

這個伺服器的系統是預設設定下的Ubuntu 14.04.1 LTS，由法蘭克福亞馬遜彈性計算雲（Frankfurt EC Amazon cloud）託管，並且伺服器配置了一個IPv4地址（我沒有檢視IPv6資料）。因為公共渠道上並沒有公佈伺服器的IP地址和DNS（域名伺服器）服務，所以，任何進入這個伺服器的請求都可被視作可疑請求。目前，我還沒有調查雲提供商重複使用IP地址 對此造成的影響。

這個伺服器還安裝了下面這些“蜜罐”： dionaea 、Glastopf 、Conpot 、SNMP、NTP和Kippo。 Kippo是一個SSH蜜罐，用於吸引駭客的注意並提升安全性。在Github 網站上的一個儲存庫中，可以獲取Kippo的相關設定和資料收集（透過ELK）。

我曾經使用過最熱門的一個NS軟體 -BIND。 其中多數設定都是預設設定。我禁用了遞迴，IPv6和轉發器（forwarder），啟用了日誌，還自定義了伺服器的版本號，在該伺服器中含有一個zone file。Zone file包含了IP地址和域名的對映關係，以及可用的子域。Zone file中包含一條記錄，這條記錄指向著同一個主機。所以，任何人只要查詢這個NS蜜罐（“a.b.c.d”），就會得到一條包含蜜罐伺服器IP地址的應答。

0x02 Bind配置

---

options { directory "/var/cache/bind"; dnssec-validation auto; recursion no; allow-transfer { none; }; auth-nxdomain no; # conform to RFC1035 // listen-on-v6 { any; }; statistics-file "/var/log/named/named_stats.txt"; memstatistics-file "/var/log/named/named_mem_stats.txt"; version "9.9.1-P2";}; logging{ channel query_log { file "/var/log/named/query.log"; severity info; print-time yes; print-severity yes; print-category yes; }; category queries { query_log; };};

$TTL 10<br/>@ IN SOA localhost. root.localhost. (<br/> 1 ; Serial<br/> 10 ; Refresh<br/> 10 ; Retry<br/> 10 ; Expire<br/> 10 ) ; Negative Cache TTL<br/>;<br/><br/> IN NS localhost<br/>* IN A a.b.c.d

0x03 統計資料

---

第一組統計數字表示的是從日誌檔案中發現的原始資料。

0x04 時間範圍

---

如果我們根據這些資料對映查詢，我們就會發現，在1月15日和1月20日、1月末和2月初，查詢量猛增。

透過進一步的調查，我們發現這些查詢都是由一個IP地址引起的；這個IP地址屬於德國波鴻魯爾大學。在波鴻魯爾大學的校網站上解釋說明了一個“DDos放大攻擊追蹤者專案 （Amplification DDoS Tracker Project）”。這個網站透過獲取掃描資料，提醒網路所有者可能出現的問題。我們發現有兩個IP地址進行了這些掃描：其中一個屬於德國波鴻魯爾大學，另一個屬於德國薩爾大學。

我們之後還發現，是由於open resolver專案查詢了蜜罐DNS，所以才造成了大量查詢。

0x05 這些查詢來自何方？

---

我提取出了日誌中的IP地址，然後使用Team Cymru 公司的ASN，獲取了這些IP的對應國家。自治系統（AS）可以告訴我們IP地址所屬的網路區段。在Github 網站上也可以找到這個指令碼。

掃描主要來自德國，美國和中國這三個國家。其中，DFN（德國）和湖南Chinanet這兩個AS的查詢較多。有超過半數的查詢來自歐洲（RIPE）。考慮到這中間有大量的請求來自德國魯爾大學，出現這樣的結果也就不足為奇了。

0x06 他們在找什麼？

---

多數查詢都是為了獲得域名的A記錄，18%以上的查詢是為了獲得域名的ANY記錄。TXT請求主要是為了獲取DNS伺服器的版本。

這些查詢是為了獲取Google和Shadowsever的IP地址，或者是Bind NS的版本。不出意外，最普遍的TLD 是.com和.org。在你創辦企業時，要謹慎選擇域名 和TLD。這份資料中，最有趣的部分是.ru和.cn這兩個TLD所佔的比例。

0x07 open resolver掃描

---

如上文所述，open resolver專案導致了大量的請求。事實上，大約56%的查詢都是來自一些參與open resolver的組織。

雖然，這類查詢的數量很大，但是在日誌中可以很容易地辨別。

01-Feb-2015 04:57:49.352 queries: info: client x.x.x.x#34341 (dnsscan.shadowserver.org): query: dnsscan.shadowserver.org IN A + (x.x.x.x)02-Feb-2015 19:15:44.507 queries: info: client x.x.x.x#41248 (www.goOGLe.co.in): query: www.goOGLe.co.in IN A + (x.x.x.x)07-Jan-2015 06:36:04.149 queries: info: client x.x.x.x#33481 (7f14f6df.openresolvertest.net): query: 7f14f6df.openresolvertest.net IN A + (x.x.x.x)11-Jan-2015 14:54:03.692 queries: info: client x.x.x.x#43656 (openresolver.com): query: openresolver.com IN A +E (x.x.x.x)01-Feb-2015 06:42:54.797 queries: info: client x.x.x.x#46018 (7f14f6df.openresolverproject.org): query: 7f14f6df.openresolverproject.org IN A + (x.x.x.x)08-Feb-2015 04:12:45.562 queries: info: client x.x.x.x#28207 (9h2y.96bf5d36.wc.syssec-research.mmci.uni-saarland.de): query: 9h2y.96bf5d36.wc.syssec-research.mmci.uni-saarland.de IN A + (x.x.x.x)<br/>

這類查詢很令人反感，數量也很龐大。如果你不在日誌監控系統中過濾掉這些，就很難發現真正的惡意請求。如果你想時刻關注DNS伺服器，你必須要做的就是應用合適的過濾程式，在處理日誌前，首先去除網路雜訊，攔截這類請求，或者是要求他們停止掃描你。這樣還能增多你從日誌監控或SIEM 解決方案中獲得的結果。

這類掃描還可能涉及法律問題。雖然，多數open resolver專案的請求通常都不是惡意的，但是也不難想象，有些不熟悉這些組織的人會認為這些掃描是惡意的。安德魯·柯麥科（Andrew Cormack）在他的論文《掃描漏洞：這是合法的嗎？》 中解釋了某些法律問題。

0x08 過濾open resolver掃描後的結果

---

在過濾了open resolver查詢後，得到了下列結果：

在這些時間範圍中，並沒有顯著地突增。多數查詢都是來自美國和中國。RISs Ripe，Arin和Apnic之間的查詢分佈也都大致相當。

在這一類別中，請求型別不是A記錄查詢就是ANY資源查詢。多數都是谷歌域名查詢。

在剔除了open resolver的干擾後，資料集揭露了兩個特別主機的行為：一個來自中國(AS 63835)，另一個來自俄羅斯(AS 2848)。

中國主機只定期查詢Bind NS的版本，然後查詢www.google.it和www.google.com的A記錄：

05-Feb-2015 18:35:21.888 queries: info: client x.x.x.x#56334 (VERSION.BIND): query: VERSION.BIND CH TXT + (x.x.x.x)06-Feb-2015 01:19:13.674 queries: info: client x.x.x.x#39664 (www.google.it): query: www.google.it IN A + (x.x.x.x)06-Feb-2015 16:49:14.384 queries: info: client x.x.x.x#51102 (www.google.com): query: www.google.com IN A + (x.x.x.x)07-Feb-2015 01:57:22.995 queries: info: client x.x.x.x#45938 (VERSION.BIND): query: VERSION.BIND CH TXT + (x.x.x.x)07-Feb-2015 14:35:58.562 queries: info: client x.x.x.x#41664 (www.google.it): query: www.google.it IN A + (x.x.x.x)07-Feb-2015 23:00:43.537 queries: info: client x.x.x.x#49252 (www.google.com): query: www.google.com IN A + (x.x.x.x)08-Feb-2015 13:27:10.678 queries: info: client x.x.x.x#34047 (VERSION.BIND): query: VERSION.BIND CH TXT + (x.x.x.x)<br/>

俄羅斯主機只定期查詢com：

06-Feb-2015 08:45:17.256 queries: info: client x.x.x.x#42795 (com): query: com IN ANY +E (x.x.x.x)08-Feb-2015 15:44:01.787 queries: info: client x.x.x.x#33207 (com): query: com IN ANY +E (x.x.x.x)<br/>

0x09 'ANY'請求出了什麼問題？

---

大約半數的請求是“ANY”請求、

10-Feb-2015 07:48:38.565 queries: info: client x.x.x.x#32767 (isc.org): query: isc.org IN ANY +ED (x.x.x.x)

通常，這是使用虛假查詢 的DNS放大攻擊。 所有這些查詢都具有遞迴()設定標誌，說明這個查詢來自客戶端，或者是伺服器轉發的請求。只有極小數量的主機要求()在應答中支援DNSSEC。

除了Google和ISC域名，我們還發現了更多“外來的”域名；攻擊者利用這些域名，測試了DNS放大攻擊的可能性。在此前的攻擊中發現了這些域名：

• globe.gov
• ohhr.ru
• Egransy.com
• uzuzuu.ru
• sema.cz
• vlch.net

DNS放大攻擊觀察者 掌握了攻擊中使用的域名，並且還能提供一個IP表單規則集，使用“黑名單”攔截這些域名。

但是，為什麼還會有人使用這些請求呢？用正常的網路行為無法解釋傳送這些請求的原因。然而，如果你看一看某些請求返回的應答，情況就會一目瞭然。你可以使用下列命令測試：

dig -t ANY @8.8.8.8 mydomain

某些應答的大小超過了6,000位元組。

;; MSG SIZE rcvd: 6800;; MSG SIZE rcvd: 6584

對於常規用途而言（區域傳送除外），DNS使用埠53上的UDP協議傳輸資料包。這種方法要求DNS資料包的大小相對較小（512位元組，不考慮不同的表頭）。需要注意的是，DNSSEC通常要求體積更大的資料包。DNS使用EDNS0 ，就可以處理體積更大的資料包。然而，使用EDNS0還是對資料包的大小有限制（可能是伺服器不支援EDNS0），所以，又重新使用TCP協議處理這些大資料包的DNS請求。輸出顯示：

;; Truncated, retrying in TCP mode.

總之，就是一個透過簡單協議傳輸，佔用資源較少的小型請求，變成了一個透過複雜協議傳輸，佔用大量資源的大型應答。

UDP協議和TCP協議的區別在於，UDP沒有“握手過程”。你傳送了請求，也就結束了；這是一個“無狀態”協議。而TCP協議則具有“握手過程”，它需要更多的資源。此外，這種協議下，還可以很輕鬆的假冒IP地址的來源。

綜合上述兩點，放大攻擊就有了很好的攻擊向量。

OpenDNS 的同仁們描述了這些DNS攻擊是如何運作的。CloudFlare 公司也觀察到了相同的模式。

為了防禦這種型別的攻擊，需要需要在多個層面上努力。DNS管理員需要透過限制列表上可以執行遞迴查詢的客戶端，確保他們的遞迴NS不是開放的解析器。對於授權的NS，管理員應該設定應答頻率限制（RRL）。 網路管理員則可以只允許已知的網路字首離開他們的網路（執行BCP 38。)這樣可以防禦所有基於UDP協議的DDoS放大攻擊（DNS、SNMP、NTP等）。

0x10 結論

---

如果一個隨機的DNS伺服器快速接受了大量針對開放解析器測試的請求，那麼這些網路雜訊就會汙染日誌；這樣你就很難檢測到DNS伺服器上的攻擊。

你可以使用DNS伺服器“蜜罐”，捕捉這些網路雜訊。

僅僅使用幾個指令碼，你就可以根據“蜜罐”資料集提供的資訊，輕鬆地過濾掉主要的掃描者。然後，你就可以使用這個白名單，把他們從真正的DNS日誌中去除，使你的日誌監控或SIEM解決方案更具價值。但是，如果你想要阻止某些高階駭客入侵你的白名單，手動設定白名單認證還是很有必要的。