from:http://securityintelligence.com/analyzing-queries-on-a-honeypot-name-server-for-better-dns-log-quality/
“蜜罐”是統計“網絡雜訊”的一種常用方法，并且這種方法也比較簡單。你對“網絡雜訊”了解的程度越高，那么你就能更好地做安全分析。 我好奇的是，在公有云上，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地址的應答。
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
第一組統計數字表示的是從日志文件中發現的原始數據。
如果我們根據這些數據映射查詢，我們就會發現，在1月15日和1月20日、1月末和2月初，查詢量猛增。
通過進一步的調查，我們發現這些查詢都是由一個IP地址引起的；這個IP地址屬于德國波鴻魯爾大學。在波鴻魯爾大學的校網站上解釋說明了一個“DDos放大攻擊追蹤者項目 （Amplification DDoS Tracker Project）”。這個網站通過獲取掃描數據，提醒網絡所有者可能出現的問題。我們發現有兩個IP地址進行了這些掃描：其中一個屬于德國波鴻魯爾大學，另一個屬于德國薩爾大學。
我們之后還發現，是由于open resolver項目查詢了蜜罐DNS，所以才造成了大量查詢。
我提取出了日志中的IP地址，然后使用Team Cymru 公司的ASN，獲取了這些IP的對應國家。自治系統（AS）可以告訴我們IP地址所屬的網絡區段。在Github 網站上也可以找到這個腳本。
掃描主要來自德國，美國和中國這三個國家。其中，DFN（德國）和湖南Chinanet這兩個AS的查詢較多。有超過半數的查詢來自歐洲（RIPE）。考慮到這中間有大量的請求來自德國魯爾大學，出現這樣的結果也就不足為奇了。
多數查詢都是為了獲得域名的A記錄，18%以上的查詢是為了獲得域名的ANY記錄。TXT請求主要是為了獲取DNS服務器的版本。
這些查詢是為了獲取Google和Shadowsever的IP地址，或者是Bind NS的版本。不出意外，最普遍的TLD 是.com和.org。在你創辦企業時，要謹慎選擇域名 和TLD。這份數據中，最有趣的部分是.ru和.cn這兩個TLD所占的比例。
如上文所述，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）在他的論文《掃描漏洞：這是合法的嗎？》 中解釋了某些法律問題。
在過濾了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/>
大約半數的請求是“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放大攻擊的可能性。在此前的攻擊中發現了這些域名：
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等）。
如果一個隨機的DNS服務器快速接受了大量針對開放解析器測試的請求，那么這些網絡雜訊就會污染日志；這樣你就很難檢測到DNS服務器上的攻擊。
你可以使用DNS服務器“蜜罐”，捕捉這些網絡雜訊。
僅僅使用幾個腳本，你就可以根據“蜜罐”數據集提供的信息，輕松地過濾掉主要的掃描者。然后，你就可以使用這個白名單，把他們從真正的DNS日志中去除，使你的日志監控或SIEM解決方案更具價值。但是，如果你想要阻止某些高級黑客入侵你的白名單，手動設置白名單認證還是很有必要的。