DNS软件可选较多,常见的有BIND、PowerDNS、Dnsmasq、Microsoft DNS、互联网DNS提供商提供的云DNS服务、硬件DNS产品等^[11].Windows下的域名系统服务器可基于图形界面管理或者采用脚本管理,自动化程度较低,配置文件不如文本配置直观.云DNS服务使用较为简单,成本较低,但是对于DNS记录的变更控制力较弱.硬件DNS产品完整性较高,功能较多,使用也较为方便.然而硬件存在价格成本,产品化较高导致自定义功能较弱,同时软件的安全更新频率也较低.所以本文中选择当前互联网最为广泛使用的BIND9 DNS软件.

首先将权威服务器和缓存服务器分开部署:权威服务器只负责面对互联网的缓存服务器查询厦门大学域名使用,又分为主服务器和从服务器.缓存服务器提供给本校师生使用,可安装任意多个.分开部署使得其中任何一个服务器即使遭受攻击也不会影响其他服务器,也有利于日志收集时对查询日志进行分类.

服务器可采用虚拟机和实体机混合,操作系统采用Windows和Linux混合、多个操作系统版本混合,并使用多个DNS软件,分布在不同的物理位置以提高多样性.

图1中的权威服务器为主从2台服务器,为了更为安全,可横向扩展为3台服务器:1台主服务器,2台从服务器,DNS记录在主服务器更新,主服务器在互联网隐藏起来,只允许管理员登陆,2台从服务器对外提供授权域名查询.

缓存服务器一般安装2台,并公布IP地址给师生使用.同时也可增加多台特殊用途的缓存服务器或转发服务器,比如图1中充当简单蜜罐角色的服务器.由于互联网的攻击存在无目的性,攻击前一般会扫描整个网段的DNS服务器,所以蜜罐缓存服务器对外不公布IP地址,如果蜜罐缓存服务器有任何查询则将查询方IP记录下来,作为可能的攻击源分析.

图1中多台DNS的更新机制为:在主权威服务器变更DNS记录后重新加载配置文件后,通过DNS notify机制通知从权威服务器立即更新主服务器变更的记录,并立即使用命令rndc flushtree远程通知缓存服务器刷新主权威服务器的Zone域.为了使得DNS记录变更能尽快传递到整个互联网,应根据需求动态调整不同DNS记录的存留时间(time to live,TTL).

对安全和高可用性要求更高的,可使用开源软件LVS(Linux virtual server)、Keepalived或者商业硬件产品在前端做负载均衡.

服务器需要最小化安装,剔除任何不需要的功能.BIND软件安装应当从包管理器安装,不建议自行编译源代码以防止安全更新较为困难.服务器应当配置防火墙,DNS集群内各个角色服务器的防火墙的配置可参考表1.

表1 服务器的防火墙配置策略
Tab.1 Firewall Configuration Strategy

为了使得配置文件可读性更高,可使用$INCLUDE关键字拆封DNS配置文件,对于有相同功能的DNS记录,应放入同一个文件,与其他业务整合而自动生成的DNS记录也应放入同一个文件,通过$INCLUDE进入主配置文件,隔离各个不同功能的DNS记录,也为DNS记录版本控制带来好处.

BIND较为重要的几个配置项解析如下:

1)recursion:配置是否接受递归查询,权威服务器应当设置为否.

2)allow-recursion:接受哪些客户端的递归查询,一般设置为校内IP.

3)allow-transfer:AXFR重要配置,限制哪些IP可下载整个域信息.

4)max-cache-size:控制DNS服务器使用缓存内存的大小.

5)rate-limit:防止发射放大攻击.

6)recursive-clients:控制DNS服务器对外并发查询的数量,默认限制1 000.观察本数值可判断DNS查询的繁忙程度和是否正在被攻击.

如果需要部署智能DNS,即对于同一个域名,根据查询客户端的源地址提供离它最近的服务器IP,可参考多view的配置方法^[12].

DNS软件安装完成后,为检测配置是否正确,可使用以下开源工具检查:

1)named-checkconf:用于在每次修改DNS配置后检查语法错误.

2)rndc:named的命令行管理工具,可用于DNS配置变更后刷新配置,收集BIND服务器状态,导出缓存数据分析等.

3)dig:DNS客户端工具,可用来检查本机和上下游DNS服务器的配置.DNS整体体系结构类似树形,对于高校来说,校内权威服务器的认定是由edu.cn DNS服务器授权的,所以可使用dig检查edu.cn对于本校DNS服务器配置的正确性.具体操作为可运行命令dig edu.cn得到edu.cn的所有权威服务器,再运行命令dig @dns.edu.cn xmu.edu.cn对每个权威服务器检索即可检查正确性.

4)tcpdump:实时截取DNS服务器网络中传输的数据包分析,并提供逻辑语句过滤出系统管理员想要分析的数据包,可在攻击时协助定位攻击源.配合dig,可检查服务器解析DNS记录是否正常.

5)Nagios:开源监控软件,可监控DNS服务器是否存活和服务器状态是否正常.

6)Fail2ban:Fail2ban可分析DNS查询日志,通过自定义规则,限制某些IP对DNS服务器的请求; 可以控制DNS客户端对服务器查询的频次,可部分抵挡恶意机器的攻击扫描.

7)grep,awk,sort,cut等命令行工具:可组合这些工具编写自定义脚本对DNS配置文件的序列号进行自动化增长,也可对DNS Log进行简单分析,为大规模日志分析做准备.

8)bindgraph:简单的开源可视化DNS日志分析工具.适合单服务器,可作为集群DNS日志分析的一种补充.

对于DNS管理员,应当熟练掌握以上工具的使用方法.DNS的攻击形式多样,新方法层出不穷,应当可通过组合以上工具分析DNS运行状态和排错,有识别攻击源或类型的能力.

DNS单服务器的监控使用开源Nagios监控,通过插件check_ping监控服务器是否存活,通过check_tcp监控TCP53端口是否开放,通过check_udp监控UDP53端口是否开放,通过check_dns监控DNS请求是否正常.通过安装代理上报服务器的CPU、Load、内存占用、硬盘空间等数据.在系统状态出现异常情况下第一时间发送邮件报警到管理员邮箱.

通过开源软件Topbeat收集DNS服务器的CPU、内存、硬盘、进程数,进入Elasticsearch,可在事后追朔服务器的运行状态.

查询日志分析子系统采用在DNS服务器安装开源软件Filebeat收集日志,对于采集工具的选择,需要对被采集服务器影响较小,Filebeat只需要一条命令即可安装,通过配置DNS日志保存目录,即可自动收集.收集完的日志通过网络传送给Logstash分析.

由于DNS日志较大,从Filebeat到Logstash到Elasticsearch,可能存在吞吐量问题,如果下一个步骤来不及处理数据会被简单丢弃.解决的方法是根据各个应用自身的日志信息,收集吞吐量和出错信息,横向扩展多台Logstash或者Elasticsearch,或者在中间加入队列服务器异步化处理.

Logstash的主要作用是对日志进行分析,预处理,分拆成不同字段,根据后期查询的要求提供数据源.DNS查询日志格式为:

09-Feb-2016 03:38:25.786 queries:client 127.0.0.1#9527(dog.xmu.edu.cn):query:dog.xmu.edu.cn IN A+(192.168.0.10)

如果整条记录不加处理直接存入Elasticsearch,Elasticsearch会对记录进行分词索引,查询速度虽然较快,但不利于分字段分析.所以我们需要把查询日志拆封,把各个字段分析出来,分别存入Elasticsearch.以上的查询日志,通过正则表达式,可以拆封得到查询时间、客户端IP地址、所查询的域名、查询的类型等信息.

为了更加精细化分析,对于IP地址,通过开源IP地理信息数据库,获得IP对应的国家、省份、城市和具体位置.而对于校内的IP地址,则不使用开源IP地理信息数据库,而是替换成校内自定义的片区楼宇数据库,在查询时即可根据片区楼宇来统计查询量.

对于查询的域名,可以根据域名使用点号进行分级的特点,通过正则表达式,拆封域名,得到二级、三级域名和主机名.

拆封的Logstash关键代码如下:

grok {

match=> {"message"=> "%{DATA:querydate} queries:client%{IP:clientip}#%{INT} \(%{DATA:queryhost}\):query:%{DATA} IN%{WORD:rrname} [+-]%{WORD}* \(%{IP}\)"}

}

#对DNS客户端进行地理信息定位,对权威服务器的查询使用开源IP地理信息数据库,而对于缓存服务器的查询应使用校内自定义的片区楼宇数据库

geoip {

source=> ["clientip"]

}

#由于已经将message全部拆封成字段保存到Elasticsearch,所以原始message已无必要保存,此举可节省近一半硬盘空间.

mutate {

remove_field=> ["message"]

}

if([queryhost]=～"＾[＾.]+\.[＾.]+$"){

grok {

match=> {"queryhost"=> "＾(?<domainname2>[＾.]+)\.(?<domainname1>[＾.]+)$"}

}

}

if([queryhost]=～"＾[＾.]+\.[＾.]+\.[＾.]+$"){

grok {

match=> {"queryhost"=> "＾(?<domainname3>[＾.]+)\.(?<domainname2>[＾.]+)\.(?<domainname1>[＾.]+)$"}

}

}

if([queryhost]=～"＾.*?[＾.]+\.[＾.]+\.[＾.]+\.[＾.]+$"){

grok {

match=> {"queryhost"=> "＾.*?(?<domainname4>[＾.]+)\.(?<domainname3>[＾.]+)\.(?<domainname2>[＾.]+)\.(?<domainname1>[＾.]+)$"}

}

}

Logstash预处理后的字段提交到Elasticsearch保存,由于日志量较大,而且由于查询日志保存了用户的上网记录,所以需要定期清理Elasticsearch数据库空间,本子系统的规则是自动清理60 d前的记录,清理使用curator脚本,放入crontab每日定期运行,运行命令为

/usr/local/bin/curator --host 127.0.0.1 delete indices --older-than 60 --time-unit days --timestring%Y.%m.%d --prefix dnslog

由于查询日志大小的不确定性,有可能某日攻击会导致生成非常大量的查询日志,所以管理员必须经常性观察Elasticsearch集群占用磁盘的情况.

日志存储到Elasticsearch后,通过Kibana实现对日志的可视化查询,建立基于Lucene查询命令,对于需要经常性分析的,可保存以待随时调用查询.而对于需要可视化展示的,则构建相应的图表.

以创建校内用户对互联网ICP访问的排名情况的图2旭日图为例,具体步骤为:新建一个可视化图表,选择饼状图,使用新的搜索,饼状图的聚合度量metrics使用Count函数,buckets桶字段分别采用domainname1、domainname2、domainname3字段依次切片,为顶级域名、二级域名和三级域名.为了使结果更精确,通过搜索排除查询量较大的疑似攻击日志.

图2 对互联网ICP访问的排名情况的旭日图
Fig.2 Sunburst chart of ICP access count ranking

图2旭日图中最内层的圆表示校内用户对互联网诸如.com、.cn、.net、.org等顶级域名的总访问量对比,内层圆外的第1个圆环体现对应的顶级域名下的二级域名诸如qq.com、baidu.com、360.cn等的访问量对比.由于国内高校的域名一般为.edu.cn结尾,所以校内用户对国内其他高校的访问量对比体现在第2个圆环内.

通过以上方法,建立多个旭日图、折线图、柱形图、表格、地图等可视化图表,并放入Kibana的Dashboard,即可实现在一个页面查看服务器总的查询量、分服务器查询量、校内域名查询量排名、查询量最大的客户端排名、DNS查询请求类型、校内用户对互联网访问情况、查询客户端地理信息分布情况等各类统计分析信息.