使用 WinRM 进行 PowerShell 远程处理的安全注意事项
建议使用 PowerShell 远程处理来管理 Windows 系统。 默认情况下，在 Windows Server 2012 R2 及更高版本中启用 PowerShell 远程处理。 本文档介绍使用 PowerShell 远程处理时的安全问题、建议和最佳做法。
PowerShell 远程处理是什么？
PowerShell 远程处理使用 Windows 远程管理（WinRM） 允许用户在远程计算机上运行 PowerShell 命令。 WinRM 是 Microsoft 对管理 Web 服务（WS-Management） 协议的实现。 要了解有关使用 PowerShell 远程处理的详细信息，可以查看 运行远程命令。
PowerShell 远程处理与使用 cmdlet 的 ComputerName 参数在远程计算机上运行它不同，后者使用远程过程调用（RPC）作为其基础协议。
PowerShell 远程处理默认设置
PowerShell 远程处理（和 WinRM）侦听以下端口：
- HTTP：5985
- HTTPS：5986
默认情况下，PowerShell 远程处理仅允许来自管理员组成员的连接。 会话在用户的上下文下启动，因此应用于单个用户和组的所有操作系统访问控制在通过 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 身份验证加密由 TGS 票证中的
etype确定。 这是新式系统上的 AES-256。 - CredSSP 加密使用在握手中协商的 TLS 密码套件。
形成第二个跃点
默认情况下，PowerShell 远程处理使用 Kerberos（如果可用）或 NTLM 进行身份验证。 这两种协议都向远程计算机进行身份验证，而无需向其发送凭据。 这是进行身份验证的最安全方法，但由于远程计算机没有用户的凭据，因此无法代表用户访问其他计算机和服务。 这被称为“第二个跃点问题”。
有多种方法可以避免此问题。 若要深入了解这些方法以及每种方法的优缺点，请参阅在 PowerShell 远程处理中形成第二个跃点。
