# 分析“蜜罐NS”上的查询，提升DNS日志的质量
Author: 乌云历史资料库 (@wooyun_archive)
Published: 2015-03-25T03:23:00Z
Canonical: https://wepostx.com/topics/763
> 乌云历史资料归档
>
> **原始作者：** virustracker
> **原始编号：** superkieran-wooyundrops:516
> **原始发布时间：** 2015-03-25 11:23
> **声明：内容仅用于技术研究和个人使用，版权归 wooyun.org。**
---
from:http://securityintelligence.com/analyzing-queries-on-a-honeypot-name-server-for-better-dns-log-quality/
# 0x00 网络杂讯
“蜜罐”是统计“网络杂讯”的一种常用方法，并且这种方法也比较简单。你对“网络杂讯”了解的程度越高，那么你就能[更好地做安全分析](http://securityintelligence.com/five-steps-for-better-security-analytics-in-2015/)。 我好奇的是，在公有云上，NS蜜罐能接收哪些流量；我的研究如下：
# 0x01 设置NS蜜罐
这个服务器的系统是默认设置下的Ubuntu 14.04.1 LTS，由法兰克福亚马逊弹性计算云（Frankfurt EC Amazon cloud）托管，并且服务器配置了一个IPv4地址（我没有查看IPv6数据）。因为公共渠道上并没有公布服务器的IP地址和DNS（域名服务器）服务，所以，任何进入这个服务器的请求都可被视作可疑请求。目前，我还没有调查云提供商[重复使用IP地址](http://arxiv.org/pdf/1204.0764.pdf) 对此造成的影响。
这个服务器还安装了下面这些“蜜罐”： [dionaea](http://dionaea.carnivore.it/) 、[Glastopf](http://glastopf.org/) 、[Conpot](http://conpot.org/) 、SNMP、NTP和[Kippo](https://github.com/desaster/kippo)。 Kippo是一个SSH蜜罐，用于吸引黑客的注意并提升安全性。在[Github](https://github.com/cudeso/cudeso-honeypot/tree/master/elk) 网站上的一个存储库中，可以获取Kippo的相关设置和数据收集（通过ELK）。
我曾经使用过最热门的一个[NS软件](http://en.wikipedia.org/wiki/Comparison_of_DNS_server_software) -[BIND](https://www.isc.org/downloads/bind/)。 其中多数设置都是默认设置。我禁用了递归，IPv6和转发器（forwarder），启用了日志，还自定义了服务器的版本号，在该服务器中含有一个zone file。Zone file包含了IP地址和域名的映射关系，以及可用的子域。Zone file中包含一条记录，这条记录指向着同一个主机。所以，任何人只要查询这个NS蜜罐（“a.b.c.d”），就会得到一条包含蜜罐服务器IP地址的应答。
# 0x02 Bind配置
```text
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; };};
```
```text
$TTL 10
@ IN SOA localhost. root.localhost. (
1 ; Serial
10 ; Refresh
10 ; Retry
10 ; Expire
10 ) ; Negative Cache TTL
;
IN NS localhost
* IN A a.b.c.d
```
# 0x03 统计数据
第一组统计数字表示的是从日志文件中发现的原始数据。
# 0x04 时间范围
如果我们根据这些数据映射查询，我们就会发现，在1月15日和1月20日、1月末和2月初，查询量猛增。
通过进一步的调查，我们发现这些查询都是由一个IP地址引起的；这个IP地址属于德国波鸿鲁尔大学。在波鸿鲁尔大学的校网站上解释说明了一个“[DDos放大攻击追踪者项目](http://scanresearch.syssec.ruhr-uni-bochum.de/) （Amplification DDoS Tracker Project）”。这个网站通过获取扫描数据，提醒网络所有者可能出现的问题。我们发现有两个IP地址进行了这些扫描：其中一个属于德国波鸿鲁尔大学，另一个属于德国萨尔大学。
我们之后还发现，是由于open resolver项目查询了蜜罐DNS，所以才造成了大量查询。
# 0x05 这些查询来自何方？
我提取出了日志中的IP地址，然后使用[Team Cymru](http://asn.cymru.com/) 公司的ASN，获取了这些IP的对应国家。自治系统（AS）可以告诉我们IP地址所属的网络区段。在[Github](https://github.com/cudeso/cudeso-honeypot/tree/master/elk) 网站上也可以找到这个脚本。
扫描主要来自德国，美国和中国这三个国家。其中，DFN（德国）和湖南Chinanet这两个AS的查询较多。有超过半数的查询来自欧洲（RIPE）。考虑到这中间有大量的请求来自德国鲁尔大学，出现这样的结果也就不足为奇了。
# 0x06 他们在找什么？
多数查询都是为了获得域名的A记录，18%以上的查询是为了获得域名的ANY记录。TXT请求主要是为了获取DNS服务器的版本。
这些查询是为了获取Google和Shadowsever的IP地址，或者是Bind NS的版本。不出意外，最普遍的[TLD](http://en.wikipedia.org/wiki/Top-level_domain) 是.com和.org。在你创办企业时，[要谨慎选择域名](http://securityintelligence.com/malicious-domains-can-give-you-the-biz/) 和TLD。这份数据中，最有趣的部分是.ru和.cn这两个TLD所占的比例。
# 0x07 open resolver扫描
如上文所述，open resolver项目导致了大量的请求。事实上，大约56%的查询都是来自一些参与open resolver的组织。
虽然，这类查询的数量很大，但是在日志中可以很容易地辨别。
```text
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)
```
这类查询很令人反感，数量也很庞大。如果你不在日志监控系统中过滤掉这些，就很难发现真正的恶意请求。如果你想时刻关注DNS服务器，你必须要做的就是应用合适的过滤程序，在处理日志前，首先去除网络杂讯，拦截这类请求，或者是要求他们停止扫描你。这样还能增多你从日志监控或[SIEM](http://securityintelligence.com/gartner-2014-magic-quadrant-siem-security/) 解决方案中获得的结果。
这类扫描还可能涉及法律问题。虽然，多数open resolver项目的请求通常都不是恶意的，但是也不难想象，有些不熟悉这些组织的人会认为这些扫描是恶意的。安德鲁·柯麦科（Andrew Cormack）在他的论文《[扫描漏洞：这是合法的吗？](https://www.terena.org/activities/tf-csirt/meeting43/Scanning%20for%20Vulnerabilities.pdf)》 中解释了某些法律问题。
# 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记录：
```text
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)
```
俄罗斯主机只定期查询com：
```text
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)
```
# 0x09 'ANY'请求出了什么问题？
大约半数的请求是“ANY”请求、
```text
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放大攻击观察者](http://dnsamplificationattacks.blogspot.be/) 掌握了攻击中使用的域名，并且还能提供一个[IP表单规则集](https://github.com/smurfmonitor/dns-iptables-rules/blob/master/domain-blacklist-string.txt)，使用“黑名单”拦截这些域名。
但是，为什么还会有人使用这些请求呢？用正常的网络行为无法解释发送这些请求的原因。然而，如果你看一看某些请求返回的应答，情况就会一目了然。你可以使用下列命令测试：
```text
dig -t ANY @8.8.8.8 mydomain
```
某些应答的大小超过了6,000字节。
```text
;; MSG SIZE rcvd: 6800;; MSG SIZE rcvd: 6584
```
对于常规用途而言（区域传送除外），DNS使用端口53上的UDP协议传输数据包。这种方法要求DNS数据包的大小相对较小（512字节，不考虑不同的表头）。需要注意的是，DNSSEC通常要求体积更大的数据包。DNS使用[EDNS0](http://en.wikipedia.org/wiki/Extension_mechanisms_for_DNS) ，就可以处理体积更大的数据包。然而，使用EDNS0还是对数据包的大小有限制（可能是服务器不支持EDNS0），所以，又重新使用TCP协议处理这些大数据包的DNS请求。输出显示：
```text
;; Truncated, retrying in TCP mode.
```
总之，就是一个通过简单协议传输，占用资源较少的小型请求，变成了一个通过复杂协议传输，占用大量资源的大型应答。
UDP协议和TCP协议的区别在于，UDP没有“握手过程”。你发送了请求，也就结束了；这是一个“无状态”协议。而TCP协议则具有“握手过程”，它需要更多的资源。此外，这种协议下，还可以很轻松的假冒IP地址的来源。
综合上述两点，放大攻击就有了很好的攻击向量。
[OpenDNS](https://labs.opendns.com/2014/03/17/dns-amplification-attacks/) 的同仁们描述了这些DNS攻击是如何运作的。[CloudFlare](https://blog.cloudflare.com/deep-inside-a-dns-amplification-ddos-attack/) 公司也观察到了相同的模式。
为了防御这种类型的攻击，需要需要在多个层面上努力。DNS管理员需要通过限制列表上可以执行递归查询的客户端，确保他们的递归NS不是开放的解析器。对于授权的NS，管理员应该设置[应答频率限制](https://deepthought.isc.org/article/AA-00994/0/Using-the-Response-Rate-Limiting-Feature-in-BIND-9.10.html)（RRL）。 网络管理员则可以只允许已知的网络前缀离开他们的网络（执行[BCP 38](http://tools.ietf.org/html/bcp38)。)这样可以防御所有基于UDP协议的DDoS放大攻击（DNS、SNMP、NTP等）。
# 0x10 结论
如果一个随机的DNS服务器快速接受了大量针对开放解析器测试的请求，那么这些网络杂讯就会污染日志；这样你就很难检测到DNS服务器上的攻击。
你可以使用DNS服务器“蜜罐”，捕捉这些网络杂讯。
仅仅使用几个脚本，你就可以根据“蜜罐”数据集提供的信息，轻松地过滤掉主要的扫描者。然后，你就可以使用这个白名单，把他们从真正的DNS日志中去除，使你的日志监控或SIEM解决方案更具价值。但是，如果你想要阻止某些高级黑客入侵你的白名单，手动设置白名单认证还是很有必要的。
## Replies