Office 365：DNS入侵检测 Secer's Blog - 记录互联网安全历程与个人成长经历

在Office 365中，我们致力于保护客户的数据。我们使用行业领先的安全防护，以确保数据安全。入侵检测也是一种这样的安全措施，可以确保我们通知我们的服务器或网络中的任何异常活动或行为。我们定期监控和查看来自入侵检测系统的警告，以了解我们服务的对手活动的迹象，目的是防止对手未经授权访问客户数据。

域名系统或DNS用于计算机网络中将域名转换为计算机使用的IP地址进行通信。几乎每个计算机网络都存在DNS; 它与外部网络进行通信，并且由于其被设计为开放协议而非常难以锁定。对手可能会发现DNS是一种有意思的机制，用于执行网络侦察，恶意软件下载或与命令控制服务器的通信或与网络数据传输等恶意活动。因此，至关重要的是我们监控我们的网络有没有进行这样的活动以保护客户的数据。

这篇文章讨论了使用DNS协议以在计算机网络中获得未授权访问的对手所使用的技术以及用于检测这些技术的监控策略。

检测内容

对手的渗透测试工具可能会滥用DNS使用下表中的技术来实现以下目标。

网络足迹
对手可能会尝试通过滥用DNS来获取有关目标网络的信息。可以使用涉及DNS的具体技术（见下表）来了解目标网络中的域名，计算机名称和IP地址。该信息可用于构建网络的模型

凭据盗用
对手可能会创建一个类似于合法域名的恶意域名，并在网络钓鱼广告系列中使用它来窃取凭据。

恶意软件
对手可能会尝试通过将请求引导到恶意域或IP地址来在目标网络的计算机上安装恶意软件。这可以通过劫持DNS查询并使用恶意IP地址进行响应来完成。恶意软件安装的目标也可以通过将请求引导到钓鱼网站来实现。

命令和控制（C2）通信
如果对手设法在目标网络中获得立足点，可能会滥用DNS与C2服务器进行通信。这通常涉及从目标网络中的计算机对DNS进行定期查询。响应包含可用于在目标网络中执行未授权操作的编码消息。

数据窃取
像C2通信一样，对手可能会滥用DNS将数据从目标网络中的计算机传输到命令和控制服务器。这可以通过使用其他协议（如FTP，SSH）通过DNS查询和响应进行。这通常涉及将多个DNS查询从受感染的计算机发送到对手拥有的域。DNS隧道也可用于执行命令并将恶意软件传输到目标网络。

逃避检测
对手可能会使用高级技术来逃避对恶意DNS流量的检测，并使用户难以发现恶意域名或域名服务器。

有关详细讨论上述主题的帖子，请参阅参考部分。

本表总结了常见对手的目标，技术和DNS活动。

对手目标	对手技巧	DNS活动（指标）
网络足迹	通过IP范围反向DNS查找域转移尝试强制添加子域名	大量的PTR查询 SOA和AXFR查询转发目标网络本地域中不存在的子域的DNS查找
凭据盗窃，恶意软件安装	DNS劫持使用欺骗性域名将合法域解析为恶意IP地址（缓存中毒）	转发错误的DNS查找主机文件修改 DNS缓存投毒
指挥与控制（C2）通信	对对手控制域的定期查询	DNS异常域查询解析IP地址的低TTL 独立DNS请求
恶意软件安装，数据窃取	通过DNS隧道使用大量查询到对手控制域	异常域的大量子域查找异常域的子域查询响应大高熵长子域包含随机/非字典词大量或不寻常的查询类型（MX，TXT）独立DNS请求
逃避检测	使用域生成算法使用快速通量对异常DNS流量使用异常的名称服务器	许多DNS请求失败（NXDomain响应）域的低TTL和多个IP地址分析 DNS流量绕过默认DNS服务器

上表中列出的指标有助于我们为对手使用的技术创建检测清单。以下是检测的总结列表。

检测异常DNS查询类型和卷
检测来自异常进程或异常DNS服务器的DNS流量
检测到异常DNS查询的异常卷
检测异常的域解析到不同IP地址
检测网络钓鱼域
检测DNS主机文件中的异常条目
通过DNS响应检测缓存投毒
检测DNS信标到异常域
检测子域中的长和随机标签以及其他的子域数
检测异常的域即只有我们服务器能解决的域

如何检测

我们分析了我们服务中的DNS流量，观察到服务中没有一个可以监控和实现检测恶意活动，报告服务器是否可靠的解决方案。

为了解决这个问题，我们设计了一个包含三个监控策略的解决方案。每个策略都捕获了我们网络中DNS流量的所有细节。这些策略也有一些重复，所以所有的细节都可以拼凑在一起，创造一个端到端的活动图片。

我们通过Windows ETW数据部署这些基于主机的监控策略。隐藏的宝藏：入侵检测与ETW讨论了使用Windows ETW进行安全监控的细节。

监控策略

让我们来看看我们实施的监测策略。

监控每个端口上的DNS通信
在此策略中，我们收集每个端口（或DNS客户端）上标准DNS解析器执行的每个DNS解析。数据是从Microsoft-Windows-DNS-Client ETW跟踪获得的。

监控Netflow（IP）流量到出站DNS端口53
在此策略中，我们从每个服务器收集出站端口53的Netflow数据。我们的Netflow数据是来自数据包头（IP地址，域，端口，协议，字节和进程）的聚合网络元数据。数据来自Microsoft-Windows-Kernel-Network ETW跟踪。

监控内部DNS服务器上的DNS数据（Dnsflow）
在此策略中，我们汇总和收集来自DNS网络中DNS服务器的DNS查询和响应数据。我们称之为Dnsflow监控。收集的一些信息是聚合查询计数，查询类型，查询和响应字节，子域名，客户端和域名服务器IP地址。数据从Microsoft-Windows-DnsServer ETW跟踪中获取。

这是每个监控策略的优缺点的总结。

监控策略	优点	缺点
监控每个端点上的DNS解析	与集中监控相比，分布式监控和负载较小更简单的处理细节清晰。例如可以记录每个DNS查询和响应	无法查看外部名称服务器的IP 无法查看绕过标准解析器的DNS查询（例如，nslookup，chrome）
监控Netflow（IP）流量到出站DNS端口53	由于数据主要来自数据包头（元数据）过程信息对于检测标准DNS解析器的bypassing是非常有价值的（例如，nslookup，chrome）有助于检测标准DNS服务器的bypassing	无法查看应用程序级数据（域名，查询类型，响应等）标准DNS查询的进程信息不足
监视服务内部DNS服务器上的DNS解析（Dnsflow）	接近完整的覆盖访问名称服务器的IP地址 DNS服务器的ETW跟踪能展示DNS客户端跟踪的更多数据	数据量很大无法查看请求DNS解析的客户端进程需要复杂的处理可能导致CPU效率低下，可能会导致服务范围的影响，而对其他两种策略的工作产生影响

性能和可靠性

由于每个策略涉及基于主机的监控，因此数据收集，处理和日志记录功能非常重要。我们通过过滤，聚合数据量高的地方实现这一目标，并持续监测资源使用情况。

监测策略的重叠确保了我们监测中没有任何盲点。此外，整个策略的重叠部分增加了冗余数据，但提高了整体解决方案在几台服务器上监控故障的弹性。

方案总结

我们已经实施了DNS检测，以便检测异常报告包括异常活动中涉及到的用户名，进程名称，计算机名称，异常域名和域名服务器IP地址等可用信息。这有助于我们对异常数据作出最明智的决定。

以下概况了我们如何做到这一点。

Dns_Intrusion_Detection_1

上图显示了通过我们网络DNS流量和与活动相关的监控数据。监视数据在端点上收集并进行处理，以便检测来自所有监控模块（Netflow，Dnsflow等）的数据。

当我们检测到DNS异常时，我们致力于获取与活动相关的所有数据 – 从用户到名称服务器的IP地址。上图显示了监控数据如何检测包含有关可用数据的信息。以下是每个监控模块的相关信息。

流程监控（本文中未讨论的详细信息） – 用户，进程
DNS解析监控 – DNS查询和响应过程
Netflow监控 – 进程，远程IP地址和端口，传输的字节数
Dnsflow监控 – DNS查询和响应，客户端和域名服务器IP地址

我们使用上述数据加入每个异常检测的中间结果，以创建有关DNS异常的更完整的图像。此外，我们将DNS检测结果与其他检测结果进行聚合。这有助于我们理解与机器或域相关的其他异常情况下的DNS异常。

参考文献

*参考来源：office365，