用于将非域设备的 WU 重定向到 WSUS 的 DNS 条目

Question 1

简而言之，Windows 更新的工作原理是向已知的 Microsoft 管理端点发送一系列 Web 服务请求——为了举例说明，假设该端点是https://update.microsoft.com。从那里，它会向其他 Microsoft 管理的端点发出进一步的请求，因为原始响应告诉它们（例如重定向以进行负载平衡）——假设这些可能是https://update1.microsoft.com，https://wu2.update.microsoft.com和https://windowsupdate.largescalecontenthost.net。

为了论证/示例的目的，我们还假设公共 Windows 更新的 Web 服务规范与 WSUS 的完全相同，并且请求中没有任何其他内容将其标识为 WU 请求而不是 WSUS 请求。

你的假设是，如果你可以拦截 Windows Update 可能发出的所有请求，并将它们指向你的 WSUS 服务器，那么你可能能够让您的非托管客户端接收您的 WSUS。

但实际上，拦截此类流量的方法只有几种：

您配置 DNS 代理：使用我们的示例设置，您需要microsoft.com和的区域根largescalecontenthost.net。这将允许您更改 DNS 客户端收到的 IP 地址，以便它获取 WSUS 服务器的 IP 地址，而不是真正的 Windows 更新服务。以下是我看到的一些麻烦：

维护拦截 DNS 代理很困难弹性、高可用性服务中的 IP 地址和服务名称总是在变化。您必须跟上这些变化。他们可能会使用largescalecontenthost.net 现在，但一周后，它们可能会变成anothercontenthost.net，您也需要拦截这些。
维护拦截 DNS 代理很困难。如果您的 DNS 客户端（即您的最终用户）实际上想要获取中的真实地址microsoft.com，则您的代理将需要知道忽略该值并从转发器获取真实地址。
干扰加密流量很困难。流量基于 HTTPS，这意味着服务器流量使用只有有效 Windows 更新服务器知道的私钥进行签名，这些服务器将公共证书作为流量的一部分发送，而 WU 客户端使用两者来验证流量是否合法。如果您的 WSUS 服务器确实收到了此流量，它将发送自己的证书。Windows 更新客户端将使用（至少）Subject证书中包含的信息来验证此证书。它是不太可能您将能够获得带有以microsoft.com或结尾的 Subject 或 SubjectAltName 值的证书largescalecontenthost.net，因为您不拥有这些域名。运作良好的证书颁发机构不会接受您不拥有的域名的请求；并且可能允许这样做，往往不会在 Windows 的信任链中停留很长时间。

您配置 DNS 代理和您自己的内部 CA： 您使用内部 CA 为 update.microsoft.com、update1.microsoft.com、wu2.update.microsoft.com 和 windowsupdate.largescalecontenthost.net 颁发虚假证书。以下是我发现的一些问题：

干扰加密流量很困难。 您必须继续针对 Windows Update 发出的请求期间出现的任何替代主机名发出这些请求。您可能不会立即知道这些是来自 Windows Update 的请求，因为您无法检查它们，因为它们是加密的。因此，您需要这些主机名的离线源来为您的流程提供信息。
干扰加密流量很困难。 您的最终用户客户端（即您的虚拟机）都不会信任您的假证书，因为您没有将证书链导入到您的受信任根存储中。您必须转到每台机器并导入您的受信任根证书。在执行此操作时，您最好首先设置指向 WSUS 服务器所需的注册表项。

您配置 DNS 代理、您自己的内部 CA、将 CA 根推送到所有客户端，并实现出站 TLS 反向代理：现在您的 TLS 反向代理可以解密 WU 发送和接收的流量，根据 WSUS 的需要动态制作假证书，如果您以某种方式将其连接到动态重写 DNS，那么所有 WU 客户端请求都将被覆盖。您的客户端信任假证书，因为根证书被导入到任何地方。一些大牌供应商的硬件可以声称能够以一定价格可靠地做到这一点。下一组麻烦：

决定解密什么很困难。 您是否还想拦截财务团队的网上银行？您的反向代理可能已经这样做了。也许您的公司政策并不关心这一点，但我认为您必须维护一大堆白名单，以防止您的代理在合理的隐私预期下窥探任何流量。
干扰加密流量很困难。 许多网站都试图抵御此类代理。公钥固定正在逐渐衰落（因为很难做到正确无误），但它是一种相当有效的工具，可以防止你颁发假证书。谷歌可能会停止工作，因为他们将证书直接固定在 Chrome 中。代理可能可以配置为从响应中删除公钥固定标头，但对于曾经访问过这些网站的任何最终用户来说，这仍然为时已晚。

现在，考虑一下替代方案： 预填充 Windows 注册表导出文件，其中包含将 Windows 更新客户端指向 WSUS 服务器所需的几个最少值。登录所有虚拟机并导入注册表文件。更新黄金映像/模板，以便新虚拟机自动获取这些设置。更新流程文档，以便构建工程师知道包含这些设置。回想一下你不得不登录所有资产并手动更新设置的一周，并研究如何在将来减轻这种手动工作量——例如将所有内容纳入域架构（即使是轻触式架构），或推出自动化工具，如 Salt、Otter 或甚至跨域 Powershell Remoting——这样你就再也不必遭受这种痛苦了。

在实践中，我敢打赌（除非你的 IT 团队真的很有条理），大概在这些不同的虚拟机上设置一个秘密的公共帐户。如果不是公共帐户，则设置一个秘密的计算机和凭据列表。如果是这样，您可能可以使用一个编写良好的批处理文件为 80% 的计算机设置注册表设置。

如果不是，那么您的 IT 团队的日常维护任务可能就是他们的一个巨大的痛点。

Answer

简而言之，Windows 更新的工作原理是向已知的 Microsoft 管理端点发送一系列 Web 服务请求——为了举例说明，假设该端点是https://update.microsoft.com。从那里，它会向其他 Microsoft 管理的端点发出进一步的请求，因为原始响应告诉它们（例如重定向以进行负载平衡）——假设这些可能是https://update1.microsoft.com，https://wu2.update.microsoft.com和https://windowsupdate.largescalecontenthost.net。