欢迎阅读有关DNS和域日志的本系列文章的第4部分。这篇文章的目的是关注Linux和其他类unix平台上的日志收集。虽然现在的企业环境是混合的,而不是完全同质的,但我决定用这篇文章来关注另一个遥测事件标准——syslog守护进程(syslogd)和syslog消息日志记录。
本文将从一个具有Linux DNS服务器的日志收集部署示例开始,然后简要概述这些日志源示例的含义,然后以Linux审计结束。如果您正在使用Windows事件日志数据和Microsoft部署,请参见本系列的第3部分.
支持Linux/ unix类平台的DNS服务器列表:
下面是一个Linux DNS服务器部署示例,其中包含一个基础架构源- BIND 9 DNS服务器。
从BIND 9 DNS服务器开始,定义了两个主要的遥测源——审计日志记录规则和用于定义各种日志记录规则的DNS服务器配置文件。
这些定义了收集审计日志的规则,这些日志可以通知潜在的基础设施攻击,例如未经授权的DNS服务器配置更改。更改攻击配置文件的文件或文件夹权限、删除日志和禁用日志记录是其他形式的基础设施攻击。缺乏这些事件的可见性形成了源自DNS服务器和其他相关基础设施的横向移动攻击的滋生地。
DNS服务器配置文件的一部分涵盖了服务器日志记录标准,例如:
每个DNS服务器实现的实际日志记录标准和配置将有所不同。对于BIND 9,这里有一个这样的日志语句语法示例他们的用户手册:
日志记录{类别字符串{字符串;...};通道字符串{缓冲布尔值;文件quoted_string[版本(无限|整数)][大小大小][后缀(增量|时间戳)];零;print-category布尔;print-severity布尔;打印时间(iso8601 | iso8601-utc | local | Boolean);严重性log_severity; stderr; syslog [ syslog_facility ]; }; };
在BIND DNS配置文件中,可以指定将某些事件写入磁盘,或者通过TCP/UDP流直接发送到日志管理服务器。在BIND 9 DNS服务器中,这是在通道配置文件的一部分。这将通知为通道选择的消息的目的地—要么转到文件,要么转到特定的syslog设施,要么转到标准错误流(stderr),或零(丢弃)。此部署示例中的事件(仅为安全事件)被发送到Syslog流并写入磁盘(/var/log/security_events.log).
事件应该以标准格式编写。有多种方法可以写入和传输事件数据。对于Syslog,这些是BSD Syslog, IETF(先于BSD的实现)Syslog, CEF(或通用事件格式,ArcSight实现),LEEF(日志事件扩展格式,与IBM QRadar相关的专有格式),Snare Syslog。还有其他被接受的格式,比如JSON。
SIEM和日志采集器文档详细介绍了丰富和写入事件的适当方法。无论如何,根据部署需求,丰富是DNS服务器和日志集中服务器实例上日志收集过程的一部分。在SIEM上,如果没有正确地丰富事件,事件可能会被消耗并作为“原始”事件呈现。还可能存在路由这些日志的附加规则,因为并非所有日志都可能具有立即的安全值,例如用于调试的日志。
在SIEM方面,还需要做进一步的工作来丰富日志,以便进行分析、自动化规则等。例如,需要清楚存在域元数据的键值对,因为它构成了DomainTools App For Splunk的基础,并且无论平台源是什么,元数据源都应该是相关的。
BIND是一款广泛使用的DNS开源软件,目前由BIND 9维护互联网系统联盟.BIND软件包括一个域名解析器,它通过将这些通信到适当的服务器并响应服务器的回复来解析有关名称的查询。BIND域名授权服务器应答来自解析器的请求。下面是一个来自Resolver的例子。
BIND 9日志记录的配置文件包括如何、内容和位置。下面是一个将查询记录到文件中的示例。
日志{通道查询{文件"/var/log/queries.log";print-severity是的;打印时间是的;};类别查询{query};};
作为半结构化的日志消息,下面是来自example.com查询的测试环境的示例日志:
查询:信息:客户端@0x7f39604b8660 127.0.0.1#50587 (example.com):查询:example.com IN A +E(0)K (127.0.0.1)
虽然上面的内容是人类可读的,但它在SIEM中不一定是可消耗的,可能会作为原始日志显示,不能用于进一步处理。随着解析和充实的进行,非结构化消息被分解成这种类型的键值对:
事件时间:2020-05-30T11:11:11.533613+01:00类别:查询级别:info客户端:127.0.0.1#50587地址:127.0.0.1查询:example.com类型:A类:IN标志:+E(0)K
因此,驻留在重要字段中的元数据,例如查询字段,具有用于其他处理的值。例如,DomainTools集成之一围绕处理网络边界内出现的域的能力展开。在这种情况下,你需要每一个查询作为这项工作的一部分来处理,因为它毕竟是在周边发生的事件的一部分。此外,您可能会注意到事件时间戳已经被设置为登录高精度时间戳,不仅如此,EventTime采用ISO8601标准,在最后添加了毫秒和时区(UTC+01:00),以确保时间戳的一致性和准确性。
将审计日志记录应用到DNS服务器,以跟踪与安全相关的事件。应用审计日志规则可以跟踪更有针对性的安全事件。在设置审计日志规则和读取事件时,了解更多关于平台中的审计系统的信息是很有用的,下面是一个示例。
有关审计规则,请参阅您的平台文档(如果手头没有,可以参考关于Linux审计日志的RHEL文档).
看/etc/bind/用于修改并添加标签:
-w /etc/bind/named.conf -p wa -k conf-change-bind9
键值对(不是原始日志)格式的结果片段:
type: CONFIG_CHANGE UID: 0 comm: nano exe: /bin/nano Key: conf-change-bind9 EventTime: 2020-05-30T12:19:20.055718+01:00
一条值得注意的规则/etc/bind如果BIND 9服务器中named.conf文件有写权限,则添加该文件来创建日志。当观察到这种情况时,将记录带有标记的日志conf-change-bind9.
结果片段应该是人类可读的。的CONFIG_CHANGE所观察的审计记录类型。的uid代码,也就是0,表示它是一个超级用户命令修改配置文件的帐户纳米编辑器(并调用纳米命令)。
当为这些事件和其他事件设置了审计日志记录时,管理员可以参考自己的平台文档来阅读审计规则。还可以观察审计日志的跟踪;例如,他们可以看到使用了哪个实用程序来更改配置文件。
通过这篇文章,您已经了解了Linux/ unix类平台上BIND 9 DNS日志收集部署示例,其中有一个解析器事件示例和一个服务器配置更改的审计事件示例。请放心回到开头,检查您的部署是否涵盖了以下内容:
虽然深入研究实际部署细节(例如更多配置示例、DNSSEC日志记录等)超出了范围,但您可以检查平台和DNS服务器文档,以及您自己的收集器和SIEM文档,以查看需要应用哪些配置以及有哪些可用选项。
使用DomainTools集成和api进一步丰富DNS和域智能(域风险评分)的相关事件,以及使用Iris平台的域IOCs。除了有针对性的日志记录外,还可以使用DomainTools作为主动和被动防御的一部分。
订阅DomainTools每月通讯,接收创新,实用的建议,以改善他们的安全态势。我们的目标是帮助组织在其组织的日常防御中变得更高效、更有知识和更积极主动。