20210309 -
(本篇文章仅仅是对几篇文章的阅读感悟,非专业人士)
0.引言
360netlab的网站[1]上,有一个系统名字叫做networkscan mon,这个信息库做的非常好,虽然说仅仅是一些统计信息的展示。但是这个内部的原理挺让人好奇的,可能360能够拿到真实的流量,然后的确进行了这部分检测,但是个人感觉这个可能性不大;另外一种可能性就是利用自己的蜜罐或者少量的一些探针来进行监视,然后利用一定的流量估计方法,估计出全部的,以上仅仅是推测。而扫描流量的特征,可能就是从TCP包的角度,例如一些扫描器的设计,或者说从发包的统计特征角度来推导。
在其首页上,还有另外一个系统,DNSMon,但是这个系统并不能进入查询。不过,其博客部分也发表了一些利用这个系统进行威胁发现的简单案例。
本篇笔记,针对这三篇文章获取到的信息来简单总结下。
1. 技术分析
DNSMon的功能是对每日千亿级别的DNS流量进行系统的分析,产出威胁情报(域名IOC),并向最终用户提供安全防御的平台[2]。
1.1 概要分析
在文章[2]中提到,
我们相信DNS安全未来的一个方向是海量DNS基础数据结合其他多种维度数据进行关联整合,从而进入更深入精细的分析
那么可想而知,DNSMon本身如果仅仅监视域名信息,例如DGA这种,并不具备精准得到一些威胁信息的能力,而是说同时利用其它的一些关联信息。例如域名的whois,备案信息,以及可能的样本发出流量后。这些内容在文章[2]的后续阐述中也得到了验证。
其核心在于将海量的DNS数据与360所拥有安全相关数据(包括whois,web,沙箱,蜜罐,证书等等)交叉对比,并从中分析得出威胁情报IOC。
列出文章[2]中的一个图来展示:
上图中,从左到右的顺序分别是DNS域名、关联子域名、关联IP、关联URL、样本指纹。然后通过各个部分的独立分析,然后加上样本的逆向分析等,来推断一些恶意的DNS。
在他的文章中也提到了关联的好处,其中有一点说到,直接从样本出发,在获取样本之后直接就从样本上解释了为什么这个域名能够成为IOC;通过对样本进行逆向几乎可以解释一切行为。但是大规模逆向也面临着挑战。
前面的这句话,通过逆向可以解释一切行为这句话,之前在我关注的方向上也能够得到印证,那就是说,真实发生的事情,而且例如一个字符串也的确与其挂钩,自然让人信服。
1.2 技术细节
在几篇文章[2-4]中其所使用的技术基本上是一致的,但是一些细节部分挺令人疑惑的,这些信息可能也不会被公开,这里记录一下。
1.2.1 对未知域名的自动拦截
内置算法是什么,这个就不得而知了;可能说这些多源的关联算法已经能够直接推导出这些域名是恶意的。
1.2.2 关联过程
在关联过程中,虽然仅仅通过一系列所属关系能够得到某个域名与最终样本的联系,但是要推导出这个恶意的结果,从他行为的每个部分来看,利用的信息要多。例如url能够扩展出来一些shell样本或者elf样本。
那么可以大胆推测,在关联的过程中,同时使用了每个节点上的信息,例如这个域名,这个url,甚至最后关联到达了样本。
3. 总结
从三篇文章来看,如果平时的误报不高,而且真的能够实现绝大部分的自动化,那么这个系统真的太厉害了。也感叹他的数据获取手段比较好,同时能够再次基础上做关联。从这个角度来说,如果有数据,那么关联过程就是核心。但是这几篇文章中,也体现出来很大的手动操作来验证的过程;当然这种方法能够在有限数量中验证也很厉害。
从整体上来看,这是一个涉及多源信息的过程,而为了实现这种系统,要学习的东西有很多,要涉及的内容也有很多。其中重要的一点就是沙箱,这个之前的时候我也关注过,这个东西对于威胁情报来说,太重要了。
而且, 我觉得从行为上来看,很多都是研究人员的经验,例如某些域名可能是什么模式。如果将这种经验固化到系统并进行落地,这个过程肯定不仅仅是字符串的硬匹配,这个过程更为关键。
参考
[1]Netlab
[2]DNSMon: 用DNS数据进行威胁发现
[3]DNSMon: 用DNS数据进行威胁发现(2)
[4]DNSMon: 用DNS数据进行威胁发现(3)