通过

RPC over HTTP 部署建议

  • 项目

本部分介绍最佳做法和建议的部署配置，以便在通过 HTTP 使用 RPC 时实现最大安全性和性能。 此处找到的各种配置根据各种大小、预算和安全要求执行不同的组织。 每个配置还提供有助于确定最适合给定方案的部署注意事项。

有关通过 HTTP 方案进行大容量 RPC 的信息，请参阅 MICROSOFT RPC 负载均衡。

以下建议适用于所有配置：

  • 使用支持通过 HTTP v2 进行 RPC 的 Windows 版本。
  • 在 IIS 6.0 模式下运行 RPC 代理的计算机上放置 IIS。
  • 禁止匿名访问 RPC 代理虚拟目录。
  • 从不启用 AllowAnonymous 注册表项。
  • 使用 CertificateSubjectField（有关详细信息，请参阅 RpcBindingSetAuthInfoEx），验证连接到的 RPC 代理是否为所需的 RPC 代理。
  • 配置 ValidPorts 注册表项，以仅包含 RPC over HTTP 客户端将连接到的计算机。
  • 请勿在 ValidPorts 键中使用通配符;这样做可以节省时间，但完全意外的计算机也可能适合通配符。
  • 通过 HTTP 客户端在 RPC 上使用 SSL。 如果遵循这些部分中设置的准则，则通过 HTTP 客户端的 RPC 无法在不使用 SSL 的情况下进行连接。
  • 除了使用 SSL 之外，配置 RPC over HTTP 客户端以使用 RPC 加密。 如果 RPC over HTTP 客户端无法访问 KDC，则只能使用 Negotiate 和 NTLM。
  • 将客户端计算机配置为使用 NTLMv2。 将 LMCompatibilityLevel 注册表项设置为 2 或更高版本。 有关 LMCompatibilityLevel 密钥的详细信息，请参阅 msdn.microsoft.com。
  • 使用上述配置运行 RPC 代理计算机的 Web 场。
  • 在 Internet 和 RPC 代理之间部署防火墙。
  • 为了获得最佳性能，请将 IIS 配置为发送短响应以实现非成功错误代码。 由于 IIS 响应的使用者是一个自动化过程，因此无需向用户友好的说明发送到客户端;通过 HTTP 客户端的 RPC 将忽略它们。

从安全、性能和可管理性角度实现 RPC 代理的基本目标如下：

  • 为通过 HTTP 流量进入服务器网络的 RPC 提供单一入口点。 将 RPC 通过 HTTP 流量进入服务器网络的单一入口点具有两个主要优势。 首先，由于 RPC 代理面向 Internet，因此大多数组织在称为不受信任的外围网络的特殊网络中隔离此类计算机，该网络独立于正常的组织网络。 不受信任的外围网络中的服务器经过精心管理、配置和监视，能够抵御来自 Internet 的攻击。 不受信任的外围网络中的计算机越少，配置、管理、监视和保护它们就越容易。 其次，由于安装了 RPC 代理的单个 Web 场可以通过驻留在公司网络上的 HTTP 服务器为任意数量的 RPC 提供服务，因此，通过 HTTP 服务器将 RPC 代理与 RPC 分离并让 RPC 代理驻留在不受信任的外围网络中非常有意义。 如果 RPC 代理与 RPC over HTTP 服务器位于同一台计算机上，则组织将强制将其所有后端服务器放入不受信任的外围网络，这将使不受信任的外围网络更加困难。 将 RPC 代理和 RPC 通过 HTTP 服务器的角色分离有助于组织将计算机数量保留在不受信任的外围网络中可管理，因此更安全。
  • 充当服务器网络的安全保险丝。 RPC 代理设计为服务器网络的可消耗保险丝 - 如果在 RPC 代理上出现问题，它只是出去，从而通过 HTTP 服务器保护真正的 RPC。 到目前为止，如果本部分中概述的最佳做法已遵循，则除 SSL 外，还使用 RPC 加密对 HTTP 流量的 RPC 进行加密。 RPC 加密本身在客户端和服务器之间，而不是在客户端和代理之间。 这意味着代理无法理解并且无法解密它收到的 RPC 流量。 它只了解客户端发送的一些控制序列，处理连接建立、流控制和其他隧道详细信息。 它无法访问 RPC over HTTP 客户端发送到服务器的数据。 此外，RPC over HTTP 客户端必须独立地向 RPC 代理和基于 HTTP 服务器的 RPC 进行身份验证。 这提供深度防御。 如果 RPC 代理计算机由于某种配置错误或某种安全漏洞而遭到入侵，则通过它的数据仍会受到篡改。 获得 RPC 代理控制权的攻击者最多可以中断流量，但不会读取流量或篡改流量。 这是 RPC 代理的融合作用发挥作用的地方 - 无需通过 HTTP 流量泄露 RPC 的安全性即可使用。
  • 在 Web 场中运行 RPC 代理的多台计算机之间分发一些访问检查和解密工作。 通过 Web 场中运行良好，RPC 代理使组织能够卸载 SSL 解密和某些访问检查，从而释放后端服务器上的更多容量进行处理。 使用 RPC 代理计算机的 Web 场还使组织能够通过增加前端服务器上的容量来抵御拒绝服务（DoS）攻击的能力。

到目前为止，在制定的准则中，组织仍然有选择。 每个组织在用户不便、安全性和成本之间都有选择和妥协：

  • 使用基本身份验证或 Windows 集成身份验证向 RPC 代理进行身份验证？ 基于 HTTP 的 RPC 目前仅支持 NTLM - 它不支持 Kerberos。 此外，如果 RPC over HTTP 客户端与 RPC 代理之间存在 HTTP 代理或防火墙，该代理通过 HTTP 标头中的 杂注插入，NTLM 身份验证将不起作用。 在这种情况下，组织可以在基本身份验证和 NTLM 身份验证之间进行选择。 基本身份验证的优点是它更快、更简单，因此为拒绝服务攻击提供了更少的机会。 但 NTLM 更安全。 根据组织的优先级，它可以选择“基本”、“NTLM”或允许用户在两者之间进行选择。 如果只选择一个，最好从 RPC 代理虚拟目录关闭另一个目录，以减少攻击风险。
  • 对 RPC 代理和通过 HTTP 服务器使用同一组凭据，或者对每个凭据使用不同的凭据？ 此决定的权衡在于用户的便利性和安全性。 很少有用户喜欢输入多个凭据。 但是，如果安全漏洞发生在不受信任的外围网络中，则为 RPC 代理和通过 HTTP 服务器的 RPC 提供单独的凭据集可提供额外的保护。 请注意，如果使用单独的凭据，并且一组凭据是用户的域凭据，建议使用用户通过 HTTP 服务器而不是 RPC 代理的 RPC 域凭据。