PDNS 系统设计实现之二:PDNS白画像

在上一篇《PDNS系统设计实现总结》中,简单记录了一下我们当前PDNS系统的结构关键点。但是,那篇里面主要提及的点,都是如何找出异常,对于PDNS系统而言,还有一个重要功能是对正常业务的刻画,今儿补上。

做安全分析,着眼点都是异常是什么,为什么要通过DNS来对业务做画像呢?其实这个道理和杀毒软件的演进思路大同小异,因为异常是多变的,难以完全描述,甚或有时候难以捕捉,因此直接做黑名单黑规则,总有漏网之鱼,且规则要紧跟异常,否则漏的就越来越多。而从白名单的角度,业务的稳定性远远高于异常,因此如果能较为精确的梳理出业务的白画像,那异常的捕捉就能变得更为简单。

直接上图。

数据流程图

上述数据流程图中,从最开始数据接入归一化,自上而下分三路:左路是一般数据处理入库,大部分流程在上一篇中已经提及,是上一篇的重点;右路是实时异常检测,在上一篇中略有提及;中路就是今天的主角,如何利用PDNS系统来形成对业务的精确画像(Profile)。而中路中,数据处理入库和左路没有太大区别,业务的白画像数据,和左路数据的最大的改进就是过滤掉所有黑数据,因此重点就是图中着重标出的 Dynamic Filter 部分。

先说一下睡在 Dynamic Filter 左边的兄弟 Static Filter。

  • 无效数据: 比如*.arpa等无意义数据
  • 无效纪录:比如SOA等无意义记录
  • Pairing 失败:一条有效的PDNS数据比如要query和response的有效pairing,否则数据可能是伪造的
  • 响应为error:数据无用
  • 请求域名无效:有些请求的域名是无效的,但是有些open resolver仍旧会回复有效数据,这些意外的数据也应该过滤掉
  • 请求域名有效,响应看似有效,但是实际无效:比如一个example.com CNAME 到 not.exist.bla,如果不仔细教研rdata部分,很容易就会混入很多无效数据
  • CDN第二跳域名: 有些CND的子域名不是固定的,变动特别频繁,这部分数据如果完全记录,那也将是数据灾难

上述之所以归为Static Filter,是因为这些过滤的条件是简单易判断可以写死的条件,无需其他过程的介入和交互。那 Dynamic Filter 要过滤哪些数据呢?

  • Abused DNS:spamhaus, dans tunnle CC指令,数据传送等等非正常DNS使用的
  • Disposable domain:两个关键 cloudfront greencompute
  • Sinkhole: 被sinkhole的数据只对安全分析有作用,绝对不可能是正常业务
  • DGA / FustFlux等黑产域名
  • DDNS动态域名: 这些域名数数count就好了
  • 黑帽SEO流量站以及站群带来的批量二级子域名
  • 子域名暴力破解 + 泛解析
  • 域名暴力破解 + gTLD泛解析
  • DNS benchmark
  • Chrome 随机域名探测
  • 随机前缀攻击
  • DNS反射放大之A纪录填充
  • 安全防护DNS流量引流, CNAMER到防护域名甚或无效域名,A到内网地址等
  • DNS suffix
  • DNS劫持结果,黑产+你熟悉的G/F/W
  • 各种异常:互联网是程序员写出来的,有程序员的地方就会有BUG,举个栗子:有些域名做防护,会将请求的域名CNAME到一个随机子域名,比如把example.com CNAME 到 aaaabbbbcccc.example.com,后续根据客户端有没有请求该子域名,来判断客户端是不是正常。如果有了该子域名的请求,则认为客户端是真实的,再将 aaaabbbbcccc.example.com CNAME 回真正的地址,实现正常请求。但是现实中,实现的方法以及判读逻辑可能有问题,导致子域名 aaaabbbbcccc.example.com 的请求过来,又一次被CNAME到更深层级的子域名,比如 ddddeeeeffff.aaaabbbbcccc.example.com, 又要进行一次判断,如此往复。因此,我们能看到一个 ping-pang 的DNS请求,请求的域名越来越长,包越来越大,直到超出 DNS 域名规范的限制。这个过程,防护设备不但没有起到防护的作用,甚或间接的造成了DDoS攻击,整个请求过程的域名都是我们要过滤掉的。

上面这一坨,每个点拿出来想做好,都可能是一项烦耗的工程。这些过滤,依赖于右路实时异常检测的结果,需要实时监测到这些异常,然后实时通知 Dynamic Filter过滤掉。这对实时异常检测的要求比较高。当然,这部分工作完全可以在最终入库前做,将入库时间延后,等各种异常汇集后再做,但是这样,对应的业务白画像的DB White也就不是实时可用的了,这个可以根据自己的需求权衡。

而且,实时异常检测的时候,不可避免会有漏判误判,最下方的 Off-Line Analysis 的产出是立足于黑白灰全局数据的安全分析,也是定期复盘,一要纠正数据,而要提供更多的模型及规则给实时异常检测,形成一个 检测-过滤-验证-检测 的环路,不断优化模型,精细梳理规则,以期实现一个精准度不断提高的PDNS白画像。