Share via

使用 WinRM 進行 PowerShell 遠端處理的安全性考慮

  • 發行項

PowerShell 遠端處理是管理 Windows 系統的建議方式。 根據預設，Windows Server 2012 R2 和更新版本會啟用 PowerShell 遠端處理。 本文件涵蓋使用 PowerShell 遠端處理時的安全性考慮、建議和最佳做法。

什麼是PowerShell遠端處理？

PowerShell 遠端處理使用 Windows 遠端管理 （WinRM） 允許使用者在遠端電腦上執行 PowerShell 命令。 WinRM 是 Microsoft 實作 的 Web Services for Management （WS-Management） 通訊協定。 您可以在執行遠端命令中找到使用 PowerShell 遠端處理的詳細資訊。

PowerShell 遠端處理與使用 Cmdlet 的 ComputerName 參數在遠端電腦上執行它不同，而遠端電腦會使用遠端過程調用 （RPC） 做為其基礎通訊協定。

PowerShell 遠端預設設定

PowerShell 遠端處理 （和 WinRM） 會接聽下列埠：

  • HTTP：5985
  • HTTPS：5986

根據預設，PowerShell 遠端處理只允許來自 管理員 istrators 群組成員的連線。 會話會在使用者的內容下啟動，因此套用至個別使用者和群組的所有操作系統訪問控制都會在透過PowerShell遠端連線時繼續套用至它們。

在專用網上，PowerShell 遠端處理的預設 Windows 防火牆規則會接受所有連線。 在公用網路上，預設的 Windows 防火牆規則只允許來自相同子網路內的 PowerShell 遠端連線。 您必須明確變更該規則，以開啟PowerShell遠端至公用網路上的所有連線。

警告

公用網路的防火牆規則是為了保護計算機免於潛在的惡意外部連線嘗試。 拿掉此規則時請小心。

進程隔離

PowerShell 遠端處理會使用 WinRM 進行電腦之間的通訊。 WinRM 會在網路服務帳戶下以服務的形式執行，並繁衍以用戶帳戶身分執行的隔離進程，以裝載 PowerShell 實例。 以一位使用者身分執行的 PowerShell 實例，無法存取以其他使用者身分執行 PowerShell 實例的進程。

PowerShell 遠端所產生的事件記錄檔

FireEye 提供了 PowerShell 遠端會話所產生的事件記錄檔和其他安全性辨識項的良好摘要，可在調查 PowerShell 攻擊中取得。

加密和傳輸通訊協定

從兩個觀點考慮 PowerShell 遠端連線的安全性很有説明：初始驗證和進行中的通訊。

不論所使用的傳輸通訊協議為何（HTTP 或 HTTPS），WinRM 一律會在初始驗證之後加密所有 PowerShell 遠端通訊。

初始驗證

驗證會確認客戶端對伺服器的身分識別，而且最好是伺服器到用戶端。

當用戶端使用計算機名稱連線到網域伺服器時，預設驗證通訊協定為 Kerberos。 Kerberos 可保證使用者身分識別和伺服器身分識別，而不會傳送任何類型的可重複使用認證。

當用戶端使用其IP位址連線到網域伺服器，或連線到工作組伺服器時，就無法進行 Kerberos 驗證。 在此情況下，PowerShell 遠程會依賴 NTLM驗證通訊協定。 NTLM 驗證通訊協定可保證使用者身分識別，而不會傳送任何類型的可委派認證。 為了證明使用者身分識別，NTLM 通訊協定要求用戶端和伺服器都會從使用者的密碼計算會話密鑰，而不需要交換密碼本身。 伺服器通常不知道用戶的密碼，因此它會與域控制器通訊，該域控制器知道用戶的密碼，並計算伺服器的會話密鑰。

不過，NTLM 通訊協定並不保證伺服器身分識別。 如同使用NTLM進行驗證的所有通訊協定，具有已加入網域電腦之計算機帳戶存取權的攻擊者可能會叫用域控制器來計算NTLM會話密鑰，進而模擬伺服器。

根據預設會停用NTLM型驗證，但可能允許在目標伺服器上設定SSL，或是在客戶端上設定WinRM TrustedHosts 設定。

使用 SSL 憑證在 NTLM 型連線期間驗證伺服器身分識別

由於 NTLM 驗證通訊協定無法確保目標伺服器的身分識別（僅知道密碼），因此您可以將目標伺服器設定為使用 SSL 進行 PowerShell 遠端處理。 將 SSL 憑證指派給目標伺服器（如果由用戶端也信任的證書頒發機構單位簽發），可啟用 NTLM 型驗證，保證使用者身分識別和伺服器身分識別。

忽略以 NTLM 為基礎的伺服器身分識別錯誤

如果無法將 SSL 憑證部署至伺服器以進行 NTLM 連線，您可以將伺服器新增至 WinRM TrustedHosts 清單，以隱藏產生的身分識別錯誤。 請注意，將伺服器名稱新增至 TrustedHosts 清單不應視為主機本身可信任的任何形式語句，因為 NTLM 驗證通訊協定無法保證您實際上要連線到您想要連線的主機。 相反地，您應該將 TrustedHosts 設定視為您想要隱藏無法驗證伺服器身分識別所產生的錯誤主機清單。

進行中的通訊

初始驗證完成後，WinRM 會加密進行中的通訊。 透過 HTTPS 連線時，TLS 通訊協定會用來交涉用來傳輸數據的加密。 透過 HTTP 連線時，訊息層級加密是由使用的初始驗證通訊協定所決定。

  • 基本身份驗證不提供加密。
  • NTLM 驗證會使用具有128位金鑰的 RC4 加密。
  • Kerberos 驗證加密是由 etype TGS 票證中的 決定。 這是新式系統上的 AES-256。
  • CredSSP 加密是使用在交握中交涉的 TLS 加密套件。

製作第二個躍點

根據預設，PowerShell 遠端處理會使用 Kerberos（如果有的話）或 NTLM 進行驗證。 這兩種通訊協議都會向遠端計算機進行驗證，而不會傳送認證給遠端計算機。 這是最安全的驗證方式，但由於遠端計算機沒有用戶的認證，因此無法代表使用者存取其他計算機和服務。 這稱為「第二個躍點問題」。

有數種方式可以避免這個問題。 如需這些方法的描述，以及每個方法的優缺點，請參閱 在PowerShell遠端中建立第二個躍點。

參考資料