用於將 WU 重定向到非域設備的 WSUS 的 DNS 條目

一點背景知識，我不是系統管理員，但無意中聽到我們討論這個問題，並想自己做一些調查。

我們執行一個內部網路，其中包含許多無法訪問 Internet 的虛擬機（和一些物理主機）。虛擬機不斷地被創建、修改、刪除和添加。但是，VM 需要打更新檔並保持最新。我們有一臺本地 WSUS 機器，它可以提取 WU 並將它們分發到域上的電腦。

**我的問題是：**是否可以使用 DNS 條目將 Windows 更新重定向到我們的內部 WSUS？更一般地說，這適用於非 GPO 和非域設備（因此手動修改系統資料庫項是不行的）。

如果這是不可能的，請您簡要概述一下為什麼這個想法行不通？

簡而言之，Windows Update 通過向已知的 Microsoft 管理的端點發送一系列 Web 服務請求來工作——假設只是為了舉例，該端點是https://update.microsoft.com。從那裡它向其他 Microsoft 管理的端點發出進一步的請求，因為原始響應告訴它們（例如重定向負載平衡）——假設這些可能是https://update1.microsoft.com、https://wu2。 update.microsoft.com和https://windowsupdate.largescalecontenthost.net。

為了論證/範例，我們還假設公共 Windows 更新的 Web 服務規範與 WSUS 的 Web 服務規範完全相同，並且在將其標識為 WU 請求而不是 WSUS 的請求中不存在任何其他內容要求。

您的假設是，如果您可以攔截 Windows 更新可能發出的所有請求，並將它們指向您的 WSUS 伺服器，那麼您也許可以讓您的非託管客戶端獲取您的 WSUS。

但是，實際上，您只有少數幾種方法可以攔截此流量：

**您配置 DNS 代理：**使用我們的範例設置，您需要microsoft.com和的區域根目錄largescalecontenthost.net。這將允許您更改 DNS 客戶端接收的 IP 地址，以便它獲取 WSUS 伺服器的 IP 地址，而不是真正的 Windows 更新服務。以下是我可以看到的一些令人頭疼的問題：

1. 維護攔截 DNS 代理很困難。彈性、高可用性服務中的 IP 地址和服務名稱總是在變化。你必須跟上這些變化。他們可能正在使用largescalecontenthost.net now，但在一周後，他們可能會更改為anothercontenthost.net，您也需要攔截這些。
2. 維護攔截 DNS 代理很困難。如果您的 DNS 客戶端（即您的最終使用者）實際上想要訪問 中的真實地址microsoft.com，您的代理將需要知道忽略該值並從轉發器獲取真實地址。
3. 干擾加密流量很難。流量是基於 HTTPS 的，這意味著伺服器流量使用只有有效 Windows 更新伺服器知道的私鑰進行簽名，這些伺服器在公共證書上作為流量的一部分發送，WU 客戶端使用兩者來驗證流量是否合法。如果您的 WSUS 伺服器實際收到此流量，它將發送自己的證書。Windows 更新客戶端將使用（至少）Subject證書中包含的資訊來驗證此證書。您不太可能獲得 Subject 或 SubjectAltName 值以microsoft.com或結尾的證書largescalecontenthost.net，因為您不擁有這些域。運作良好的證書頒發機構不會接受對您不擁有的域的請求；並且可能允許這樣做的 CA 往往不會在 Windows 的信任鏈中保留很長時間。

您配置 DNS 代理和您自己的內部 CA： 您使用內部 CA 為 update.microsoft.com、update1.microsoft.com、wu2.update.microsoft.com 和 windowsupdate.largescalecontenthost.net 頒發假證書。以下是我可以看到的一些令人頭疼的問題：

1. 干擾加密流量很難。 對於在 Windows Update 發出請求期間出現的任何替代主機名，您必須繼續發布這些。您可能不會立即知道這些是來自 Windows 更新的請求，因為您無法檢查它們，因為它們已加密。因此，您需要這些主機名的離線來源來支持您的程序。
2. 干擾加密流量很難。 您的最終使用者客戶端（即您的虛擬機）都不會信任您的假證書，因為您尚未將鏈導入您的 Trusted Roots 儲存。您必須前往每台機器並導入您信任的根證書。當您這樣做時，您不妨首先設置指向 WSUS 伺服器所需的系統資料庫項。

您配置一個 DNS 代理，您自己的內部 CA，將 CA 根推送到您的所有客戶端，並實施出站 TLS 反向代理：現在您的 TLS 反向代理可以解密 WU 發送和接收的流量，偽造基於 WSUS 所需的動態證書，如果您以某種方式連接它以動態重寫 DNS，則涵蓋所有 WU 客戶端請求。您的客戶信任假證書，因為根目錄已隨處導入。一些大牌供應商的硬體可以聲稱可以做到這一點，而且足夠可靠，而且要付出一定的代價。下一組頭痛：

1. 決定解密什麼是困難的。 您是否也想攔截您的財務團隊的網上銀行？您的反向代理可能已經這樣做了。也許您有一個不關心這一點的公司政策，但我希望您必須維護一大堆白名單，以防止您的代理以合理的隱私期望窺探任何流量。
2. 干擾加密流量很難。 許多站點試圖對此類代理具有彈性。Public Key Pinning 正在下降（因為很難做到正確），但它是一種相當有效的工具，可以防止您簽發假證書。Google可能會停止工作，因為他們將證書直接固定在 Chrome 中。代理可能可以配置為從響應中去除公鑰 Pins 標頭，但是對於任何曾經訪問過這些站點的最終使用者來說，這仍然為時已晚。

現在，考慮替代方案： 預填充 Windows 系統資料庫導出文件，其中包含將 Windows 更新客戶端指向 WSUS 伺服器所需的幾個最小值。登錄所有虛擬機並導入系統資料庫文件。更新您的黃金映像/模板，以便新 VM 自動獲取這些設置。更新您的流程文件，以便建構工程師知道包含這些設置。哀嘆您不得不手動登錄所有資產並更新設置的那一周，並研究如何在未來減輕這種手動工作 - 例如將所有內容都納入域架構（甚至是輕觸式架構），或者推出像 Salt、Otter 甚至跨域 Powershell Remoting 這樣的自動化工具——這樣你就不必再遭受這種痛苦了。

在實踐中，我敢打賭（除非您的 IT 團隊真的有條不紊），每個不同的虛擬機上*可能都有一個秘密的公共帳戶。*如果不是普通帳戶，則為電腦和憑據的秘密列表。如果是這樣，您可能可以使用一個編寫良好的批處理文件為這些機器中的 80% 設置系統資料庫設置。

如果不是，那麼您的 IT 團隊的日常維護任務可能對他們來說是一個巨大的痛點。

引用自：https://serverfault.com/questions/922175