使用 Microsoft 登录
登录或创建帐户。
你好,
使用其他帐户。
你有多个帐户
选择要登录的帐户。

摘要

摘要信息

2020 年 5 月 19 日,Microsoft 发布了安全公告 ADV200009。 本公告描述了以色列研究人员发现的 DNS 放大攻击。 攻击(称为 NXNSAttack)可以针对任何 DNS 服务器,包括对 DNS 区域具有权威性的 Microsoft DNS 和 BIND 服务器。

对于驻留在公司 Intranet 上的 DNS 服务器,Microsoft 将此漏洞的利用风险视为低。 但是,驻留在边缘网络上的 DNS 服务器容易受到 NXNSAttack 的攻击。 位于边缘网络上且操作系统低于 Windows Server 2016 的 DNS 服务器应升级到支持响应速率限制 (RRL) 的 Windows Server 2016 或更高版本。 当目标 DNS 解析器查询你的 DNS 服务器时,RRL 会减少放大效果。

 

症状

当发生 DNS 放大攻击时,你可能会在受影响的服务器上观察到以下一个或多个症状:

  • DNS 的 CPU 使用率明显上升。

  • DNS 响应时间增加且响应可能会停止。

  • 身份验证服务器会生成大量意外的 NXDOMAIN 响应。

攻击概述

DNS 服务器始终容易受到一系列攻击。 因此,DNS 服务器通常位于 DMZ 中的负载均衡器和防火墙后面。

要利用此漏洞,攻击者必须具有多个 DNS 客户端。 通常,这包括僵尸网络、对几十或几百个能够放大攻击的 DNS 解析器的访问、以及专用攻击者 DNS 服务器服务。

攻击的关键是专门构建的攻击者 DNS 服务器,该服务器对于攻击者拥有的域具有权威性。 要成功攻击,DNS 解析器必须知道如何到达攻击者的域和 DNS 服务器。 这种组合可以在递归解析器和受害者的权威 DNS 服务器之间产生大量通信。 结果是 DDoS 攻击。

公司 Intranet 上的 MS DNS 漏洞

内部专用域无法通过根提示和顶级域 DNS 服务器解析。 当你遵循最佳实践时,无法从 Internet 上访问专用内部域(如 Active Directory 域)的权威 DNS 服务器。

尽管从技术上讲,从内部网络进行内部域的 NXNSAttack 是可能的,但需要内部网络上的恶意用户具有管理员级访问权限,才能配置内部 DNS 服务器以指向攻击者域中的 DNS 服务器。 此用户还必须能够在网络上创建恶意区域,并将能够执行 NXNSAttack 的特殊 DNS 服务器放在公司网络上。 具有此访问级别的用户通常倾向于通过发起高度可见的 DNS DDoS 攻击来隐身而不是宣布其存在。
 

面向边缘的 MS DNS 的漏洞

Internet 上的 DNS 解析器使用根提示和顶级域 (TLD) 服务器来解决未知的 DNS 域。 攻击者可以使用此公共 DNS 系统使用任何面向 Internet 的 DNS 解析器来尝试 NXNSAttack 放大。 发现放大矢量后,它可以用作对承载公共 DNS 域(受害域)的任何 DNS 服务器的拒绝服务 (DDoS) 攻击的一部分。

如果允许来自 Internet 的未经请求的传入 DNS 查询,则充当解析器或转发器的边缘 DNS 服务器可用作攻击的放大矢量。 公共访问允许恶意 DNS 客户端将解析器用作整体放大攻击的一部分。

公共域的权威 DNS 服务器必须允许来自正在从根提示和 TLD DNS 基础结构进行递归查找的解析器的未经请求的传入 DNS 流量。 否则,对域的访问将失败。 这将导致所有公有领域权威 DNS 服务器成为 NXNSAttack 的可能受害者。 面向 Edge 的 Microsoft DNS 服务器应运行 Windows Server 2016 或更高版本以获得 RRL 支持。

解决方案

要解决此问题,请为相应的服务器类型使用以下方法。

对于面向 Intranet 的 MS DNS 服务器


这种利用的风险很低。 监视内部 DNS 服务器的异常流量。 在发现位于企业内部网上的内部 NxNSattacker 时禁用它们。

对于面向边缘的权威 DNS 服务器

启用 Windows Server 2016 和更高版本的 Microsoft DNS 支持的 RRL。 在 DNS 解析器上使用 RRL 可最大限度地减少初始攻击放大。 在公共域权威 DNS 服务器上使用 RRL 可减少反射回 DNS 解析器的任何放大。 默认情况下会禁用 RRL。 有关 RRL 的更多信息,请参阅下面的文章:

运行 SetDNSServerResponseRateLimiting PowerShell cmdlet 以便使用默认值启用 RRL。 如果启用 RRL 导致合法 DNS 查询由于限制太紧而失败,则请仅递增增加“Response/Sec” 和“Errors/Sec” 参数的值,直到 DNS 服务器响应以前失败的查询。

其他参数还可以帮助管理员更好地管理 RRL 设置。 这些设置包括 RRL 异常。

有关详细信息,请参阅以下 Microsoft Docs 文章:

DNS 日志记录和诊断

常见问题

问题 1: 此处汇总的缓解措施是否适用于所有版本的 Windows Server?

解答 1: 不适用。此信息不适用于 Windows Server 2012 或 2012 R2。 这些旧版本的 Windows Server 不支持 RRL 功能,该功能可在目标 DNS 解析器查询 DNS 服务器时减少放大效果。

问题 2: 如果客户有 DNS 服务器驻留在运行 Windows Server 2012 或 Windows Server 2012 R2 的边缘网络中,该怎么办?

解答 2: 驻留在运行 Windows Server 2012 或 Windows Server 2012 R2 的边缘网络中的 DNS 服务器应升级到支持 RRL 的 Windows Server 2016 或更高版本。 当目标 DNS 解析器查询你的 DNS 服务器时,RRL 会减少放大效果。

问题 3: 如何确定 RRL 是否导致合法的 DNS 查询失败?

解答 3: 如果 RRL 配置为“LogOnly” 模式,则 DNS 服务器会执行所有 RRL 计算。 但是,服务器不会执行预防性操作(如删除或截断响应),而是记录潜在操作,就像启用了 RRL 一样,然后继续提供常规响应。

需要更多帮助?

需要更多选项?

了解订阅权益、浏览培训课程、了解如何保护设备等。

社区可帮助你提出和回答问题、提供反馈,并听取经验丰富专家的意见。

此信息是否有帮助?

你对语言质量的满意程度如何?
哪些因素影响了你的体验?
按“提交”即表示你的反馈将用于改进 Microsoft 产品和服务。 你的 IT 管理员将能够收集此数据。 隐私声明。

谢谢您的反馈!

×