使用 WinRM 的 PowerShell 远程处理的安全注意事项

PowerShell 远程处理是管理 Windows 系统的推荐方法。 Windows Server 2012 R2 及更高版本中默认启用 PowerShell 远程处理。本文档涵盖使用 PowerShell 远程处理时的安全问题、建议和最佳实践。

什么是 PowerShell 远程处理？

PowerShell 远程处理使用 Windows 远程管理 (WinRM) 来允许用户在远程计算机上运行 PowerShell 命令。 WinRM 是 Web 管理服务 (WS-Management) 协议的 Microsoft 实现。您可以在运行远程命令中找到有关使用 PowerShell 远程处理的更多信息。

PowerShell 远程处理与使用 cmdlet 的 ComputerName 参数在远程计算机上运行它不同，后者使用远程过程调用 (RPC) 作为其基础协议。

PowerShell 远程处理默认设置

PowerShell 远程处理（和 WinRM）侦听以下端口：

• HTTP：5985
• HTTPS：5986

默认情况下，PowerShell Remoting 仅允许来自管理员组成员的连接。会话是在用户上下文下启动的，因此应用于单个用户和组的所有操作系统访问控制在通过 PowerShell 远程连接进行连接时将继续应用于他们。

在专用网络上，PowerShell 远程处理的默认 Windows 防火墙规则接受所有连接。在公共网络上，默认的 Windows 防火墙规则仅允许来自同一子网内的 PowerShell 远程连接。您必须显式更改该规则才能对公共网络上的所有连接打开 PowerShell 远程处理。

警告

公共网络的防火墙规则旨在保护计算机免受潜在的恶意外部连接尝试。删除此规则时请小心。

进程隔离

PowerShell Remoting 使用 WinRM 在计算机之间进行通信。 WinRM 作为网络服务帐户下的服务运行，并生成作为用户帐户运行的隔离进程来托管 PowerShell 实例。以一个用户身份运行的 PowerShell 实例无权访问以另一用户身份运行 PowerShell 实例的进程。

PowerShell 远程处理生成的事件日志

FireEye 提供了 PowerShell 远程会话生成的事件日志和其他安全证据的详细摘要，可在调查 PowerShell 攻击中找到。

加密和传输协议

从两个角度考虑 PowerShell 远程连接的安全性会很有帮助：初始身份验证和持续通信。

无论使用哪种传输协议（HTTP 或 HTTPS），WinRM 始终在初始身份验证后加密所有 PowerShell 远程通信。

初始认证

身份验证向服务器确认客户端的身份 - 理想情况下是服务器向客户端确认身份。

当客户端使用其计算机名称连接到域服务器时，默认身份验证协议是 Kerberos。 Kerberos 保证用户身份和服务器身份，而无需发送任何类型的可重用凭据。

当客户端使用其 IP 地址连接到域服务器或连接到工作组服务器时，无法进行 Kerberos 身份验证。在这种情况下，PowerShell Remoting 依赖于 NTLM 身份验证协议。 NTLM 身份验证协议保证用户身份，而无需发送任何类型的可委托凭证。为了证明用户身份，NTLM 协议要求客户端和服务器都根据用户的密码计算会话密钥，而无需交换密码本身。服务器通常不知道用户的密码，因此它与域控制器通信，域控制器知道用户的密码并计算服务器的会话密钥。

然而，NTLM 协议并不保证服务器身份。与使用 NTLM 进行身份验证的所有协议一样，有权访问加入域的计算机的计算机帐户的攻击者可以调用域控制器来计算 NTLM 会话密钥，从而模拟服务器。

默认情况下禁用基于 NTLM 的身份验证，但可以通过在目标服务器上配置 SSL 或在客户端上配置 WinRM TrustedHosts 设置来允许。

在基于 NTLM 的连接期间使用 SSL 证书验证服务器身份

由于 NTLM 身份验证协议无法确保目标服务器的身份（只能确保它已经知道您的密码），因此您可以将目标服务器配置为使用 SSL 进行 PowerShell 远程处理。将 SSL 证书分配给目标服务器（如果由客户端也信任的证书颁发机构颁发）可启用基于 NTLM 的身份验证，从而保证用户身份和服务器身份。

忽略基于 NTLM 的服务器身份错误

如果将 SSL 证书部署到服务器以进行 NTLM 连接不可行，您可以通过将服务器添加到 WinRM TrustedHosts 列表来抑制由此产生的身份错误。请注意，将服务器名称添加到 TrustedHosts 列表中不应被视为对主机本身可信度的任何形式的声明 - 因为 NTLM 身份验证协议无法保证您确实是连接到您想要连接的主机。相反，您应该将 TrustedHosts 设置视为您希望抑制因无法验证服务器身份而生成的错误的主机列表。

持续沟通

初始身份验证完成后，WinRM 会对正在进行的通信进行加密。通过 HTTPS 连接时，TLS 协议用于协商用于传输数据的加密。通过 HTTP 连接时，消息级加密由使用的初始身份验证协议确定。

• 基本身份验证不提供加密。
• NTLM 身份验证使用具有 128 位密钥的 RC4 密码。
• Kerberos 身份验证加密由 TGS 票证中的 etype 确定。这是现代系统上的 AES-256。
• CredSSP 加密使用握手中协商的 TLS 密码套件。

进行第二跳

默认情况下，PowerShell Remoting 使用 Kerberos（如果可用）或 NTLM 进行身份验证。这两种协议都可以向远程计算机进行身份验证，而无需向其发送凭据。这是最安全的身份验证方式，但由于远程计算机没有用户的凭据，因此它无法代表用户访问其他计算机和服务。这被称为“第二跳问题”。

有几种方法可以避免这个问题。有关这些方法的说明以及每种方法的优缺点，请参阅在 PowerShell 远程处理中进行第二个跃点。

参考

• Windows 远程管理 (WinRM)
• 用于管理的 Web 服务（WS-Management）
• 2.2.9.1 加密消息类型
• 克伯罗斯
• NTLM认证协议
• 调查 PowerShell 攻击