分析“蜜罐NS”上的查询,提升DNS日志的质量

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地址 对此造成的影响。

这个服务器还安装了下面这些“蜜罐”: dionaeaGlastopfConpot 、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月初,查询量猛增。

enter image description here

通过进一步的调查,我们发现这些查询都是由一个IP地址引起的;这个IP地址属于德国波鸿鲁尔大学。在波鸿鲁尔大学的校网站上解释说明了一个“DDos放大攻击追踪者项目 (Amplification DDoS Tracker Project)”。这个网站通过获取扫描数据,提醒网络所有者可能出现的问题。我们发现有两个IP地址进行了这些扫描:其中一个属于德国波鸿鲁尔大学,另一个属于德国萨尔大学。

我们之后还发现,是由于open resolver项目查询了蜜罐DNS,所以才造成了大量查询。

0x05 这些查询来自何方?


我提取出了日志中的IP地址,然后使用Team Cymru 公司的ASN,获取了这些IP的对应国家。自治系统(AS)可以告诉我们IP地址所属的网络区段。在Github 网站上也可以找到这个脚本。

enter image description here

enter image description here

扫描主要来自德国,美国和中国这三个国家。其中,DFN(德国)和湖南Chinanet这两个AS的查询较多。有超过半数的查询来自欧洲(RIPE)。考虑到这中间有大量的请求来自德国鲁尔大学,出现这样的结果也就不足为奇了。

enter image description here

0x06 他们在找什么?


多数查询都是为了获得域名的A记录,18%以上的查询是为了获得域名的ANY记录。TXT请求主要是为了获取DNS服务器的版本。

enter image description here

这些查询是为了获取Google和Shadowsever的IP地址,或者是Bind NS的版本。不出意外,最普遍的TLD 是.com和.org。在你创办企业时,要谨慎选择域名 和TLD。这份数据中,最有趣的部分是.ru和.cn这两个TLD所占的比例。

enter image description here

enter image description here

0x07 open resolver扫描


如上文所述,open resolver项目导致了大量的请求。事实上,大约56%的查询都是来自一些参与open resolver的组织。

enter image description here

虽然,这类查询的数量很大,但是在日志中可以很容易地辨别。

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查询后,得到了下列结果:

enter image description here

在这些时间范围中,并没有显著地突增。多数查询都是来自美国和中国。RISs Ripe,Arin和Apnic之间的查询分布也都大致相当。

enter image description here

在这一类别中,请求类型不是A记录查询就是ANY资源查询。多数都是谷歌域名查询。

enter image description here

enter image description here

在剔除了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表单规则集,使用“黑名单”拦截这些域名。

但是,为什么还会有人使用这些请求呢?用正常的网络行为无法解释发送这些请求的原因。然而,如果你看一