介绍
日志是安全性的基本组成部分。在我担任日志收集软件套件的供应商方面的传播者期间，我遇到的一个常见用例是DNS日志收集和集成。因此，作为关于日志收集的系列文章的第一部分，我决定分享我所知道的关于日志记录的知识，但重点是来自DNS(服务器和客户端)和其他日志源的日志，这些日志源包含有价值的IP、主机名和域元数据。
在本系列的第一篇文章中，我们将概览日志记录——日志收集的原因、行业指南、日志统计数据。后续的博客系列将介绍目标日志收集在防御中的作用，并指出研究和用例。我们还将关注集成日志源和SIEMs的相关人员，并将发布一系列关于Linux和Windows DNS服务器和客户端日志收集和部署，以及其他日志源(云、审计、邮件日志、网络防御日志等)的文章。
日志收集原因
收集日志的原因是什么?主要原因概述包括:
- 排除操作问题
- 维护事件完整性
- 审计和遵从性目的
- 构建集中式日志管理服务器
- 遵循最佳实践和安全指导方针。例如，能够回答这些问题:
- 需要监控的重要安全事件有哪些?
- 哪些值得注意的域和DNS事件需要监控?
- 向分析师提供调查、警报、报告等所需的数据。
- 查找MITM(中间人)欺骗或劫持DNS响应
- 寻找与CnC(指挥与控制)沟通的证据
- 寻找社会工程/网络钓鱼的证据(例如积极使用欺骗性域名)
理由和基本原理可能还不够，特别是如果您的任务是设计一个计划来说服公司开始或改进日志记录。乐动体育官网下载幸运的是，业界已经有了可用的指导，下一节将介绍。
来自行业的测井指南
我建议使用行业指南作为日志部署的起点，同时确保不仅可以捕获DNS日志，还可以捕获包含有价值元数据(如审计事件)的其他日志源，以及包含IP地址和主机名的日志元数据。
Palantir
Palantir的WEF (Windows事件转发)指南包括DNS客户端和服务器事件。看到他们的用于WEF的Github库和一个示例WEF订阅配置DNS。
国家安全局
NSA发布了“Windows事件监控指南”，其中包括Windows事件日志通道，如“Microsoft-Windows-DNS-Client”和“Microsoft-Windows-DNSServer”，以及相关的Windows事件跟踪(ETW)提供商的名称。看到他们的Github事件转发指南．
NSA事件监控指南中的配置示例:
<查询Id="0"路径="Microsoft-Windows-DNS-Client/Operational">*[EventData[Data[@Name="QueryOptions"]="140737488355328"]] *[EventData[Data[@Name="QueryResults"]=""]]
开放Web应用程序安全项目
OWASP 2020年十大安全漏洞包括日志记录和监控不足。他们在2017年的报告中也包括了这类漏洞。
从OWASP:
不充分的日志记录和监视，加上事件响应的缺失或无效集成，使攻击者能够进一步攻击系统、维护持久性、转向更多系统来篡改、提取或破坏数据。大多数漏洞研究表明，检测漏洞的时间超过200天，通常由外部方而不是内部流程或监控检测到。
SANS关键控制
SANS关键控制(CIS控制7.1)有子控制8.7(网络)，其中包括建议:“启用域名系统(DNS)查询日志记录以检测已知恶意C2域的主机名查找。”
开源
SwiftonSecurity Github Repo for Sysmonhttps://github.com/SwiftOnSecurity/sysmon-config
其他指导:一般日志收集指导
- CREST网络安全监控和日志指南
- 英国建设工作测井变得容易
- NIST SP800-81-2 DNS部署指南
- PCI在有效的每日日志监控
日志部署号:一个场景
为了满足分析ioc(危害指标)和其他威胁搜索活动的需求，以及完成SOC工作(如警报和分类)的操作需求，公司需要日志数据。还有成山的水。DNS和与域相关的遥测事件往往与其他日志数据源(如身份验证或审计日志)协同工作。
需要更多的信息和数据—一旦您通过日志知道了泄漏点(恶意域)，那么攻击者使用的入口点是什么?它也需要是具体的。这就是为什么，比如Equifax 2017年验尸报告表明攻击的早期信号之一是在目标服务器上运行whoami命令。
Splunk实例部署示例
下面是一个部署在Splunk实例。详情如下:
- 中央Splunk实例，容量为12TB
- 到2020年底有效容量达到20TB
- 50+ Splunk通用转发器在Windows上
- 到2020年底，预计将有300多个Splunk环球货运代理
- 实际数据量:200gb /天
- 预计到2020年底达到300+ GB/天
- 100源类型
- 650个独立日志源
值得注意的一件有趣的事情是，增加日志源暴露的趋势呈上升趋势，从而增加日志收集。
一个部署示例—潜在的日志统计
基于的数字300 + GB /天根据前面的示例，下面是一个势函数
- 7400 EPS(每秒事件数)
- 639,360,000环保署(每日活动数)
- 原始日志保留90天
- 90天的SIEM日志保留
- 1:1 SIEM存储压缩
- 298原始日志数据总量(GB/天)
- 893归一化日志数据总量(GB/天)
- 26,820 GB裸存储需求
- 80,370总SIEM存储需求
地点:
- 原始日志数据总量(GB/天)假设日志数据为500字节。
- 规范化日志数据总量(GB/天)假设每条记录存储1500字节。
的价值300 + GB /天用于将计算反向返回到这可能表示的日志事件的数量。使用SIEM存储计算器(BuzzCircuit SIEM存储计算器*)计算出若干每秒7400个日志事件，或者每天6.39亿个日志事件．请记住，这些是日志事件，而不是完整的遥测数据，因为并非所有源都被记录。这些日志还可能有额外的解析规则，例如删除重复日志或删除不重要元数据的规则。
*除了基线测试之外，这些计算器对于部署来说是一个有用的工具，可以计算出需要多少预算和基础设施来满足收集日志的能力。
当用户达到考虑额外帮助的阶段时，例如DomainTools集成或Iris Investigate，以帮助他们检测威胁和分析域，他们可能有这些类型的范围来处理。
如何查看DNS服务器日志统计信息?
您可能还想了解DNS服务器事件的日志生成编号。DNS服务器样本来自Solarwinds关于估计日志生成的论文指出，对他们来说，“2个Windows DNS服务器”为1000名员工可以生成每秒100 EPS或事件数(峰值，平均峰值)*．在我的计算中，这是每天高达8,640,000 EPD或事件(基于峰值)。
根据我的计算:
- 4GB/天总原始日志数据
- 12gb /day归一化日志数据总量
- 360gb裸存储需求
- 1080 SIEM总存储需求
*我只包括太阳风每秒的事件数大胆的)，因为其余的是我根据已知的峰值每股收益计算的近似数字。
要记住的一件事是，这些估计排除了其他日志源。其他来源也很有趣，也会提供有价值的元数据，例如:
- DNS Client事件
- 网络连接日志，如来自Windows防火墙的日志
- 代理日志中的FQDN元数据
- 来自消息跟踪日志的主机名(源和目标)
- DNS查询事件
关于这些日志源的更多信息(包括日志示例)将在以后的博客文章中介绍。
结论
防御者应该特别注意他们自己的DNS服务器的内部、来自客户端的DNS查询日志、网络边界活动、邮件日志、代理日志等。行业指南说明了收集这些信息(即DNS、IP、主机名、域日志)的重要性。正如日志部署统计数据所示，部署这样的任务对于企业来说不是一件容易的事。
在本系列的后续部分中，我们将展示日志源如何为防御提供支柱，提供部署示例，并展示如何将来自这些日志的相关元数据用于威胁搜索和分析。当收集到相关日志时，分析人员能够构建一个更全面的ioc描述——从通过欺骗性网络钓鱼门户的潜在未经授权的入侵，到网络之外的外部IP的恶意泄露，等等。
利用从源到SIEM(以及更多)的日志
充分利用您的环境和网络中已经存在的相关日志记录源。有了来自服务器、客户端和网络端点的正确元数据，您可以使用DomainTools Iris Detect、Iris Investigate和许多api来改进和加强防御。
额外的资源
使用api以编程方式丰富日志数据。的虹膜调查API和虹膜浓缩API，它处理与Iris调查UI相同的数据源，提供来自邻近和威胁配置文件算法的领域风险评分。看到API文档了解更多信息。除了api，还可以使用DomainTools集成在您的域元数据中查找威胁情报。