RPC over HTTP 安全性

除了标准 RPC 安全性之外,RPC over HTTP 还提供三种类型的安全性,这导致 RPC over HTTP 流量可以获得一次由 RPC 提供的保护,然后获得由 RPC over HTTP 的隧道机制提供的双重保护。 有关标准 RPC 安全机制的说明,请参阅“安全性”。 RPC over HTTP 隧道机制通过以下方式增加了普通 RPC 安全性:

  • 通过 IIS 提供安全性(仅适用于 RPC over HTTP v2)。
  • 提供 SSL 加密和 RPC 代理验证(相互身份验证)。 也仅在 RPC over HTTP v2 中可用。
  • 提供对 RPC 代理级别的限制,规定服务器网络上的哪些计算机可以接收 RPC over HTTP 调用。

以下各部分将对注意对这三个安全功能进行详细介绍。

IIS 身份验证

RPC over HTTP 可以利用 IIS 的正常身份验证机制。 可以使用 IIS MMC 管理单元中默认网站下的 Rpc 节点配置 RPC 代理的虚拟目录:

Screenshot showing the Rpc node under the Default Web Site in the IIS MMC snap-in.

可以将 IIS 配置为禁用匿名访问并要求对 RPC 代理的虚拟目录进行身份验证。 为此,请右键单击 Rpc 节点,然后选择“属性”。 选择“目录安全性”选项卡,然后单击“身份验证和访问控制”组中的“编辑”按钮,如下所示:

Screenshot showing the RPC Properties dialog box.

尽管即使 RPC 代理虚拟目录允许匿名访问,也可以使用 RPC over HTTP,但出于安全原因,Microsoft 强烈建议禁用对该虚拟目录的匿名访问。 相反,对于 RPC over HTTP,请启用基本身份验证、Windows 集成身份验证或同时启用两者。 请记住,只有 RPC over HTTP v2 才能针对需要基本或 Windows 集成身份验证的 RPC 代理进行身份验证;如果禁用“禁止匿名访问”,则 RPC over HTTP v1 将无法连接。 由于 RPC over HTTP v2 是更安全、更稳健的实施,因此使用支持它的 Windows 版本可提高安装的安全性。

注意

默认情况下,RPC 代理虚拟目录被标记为允许匿名访问。 但是,RPC over HTTP v2 的 RPC 代理默认会拒绝未经身份验证的请求。

 

流量加密

RPC over HTTP 可以使用 SSL 加密 RPC over HTTP 客户端和 RPC 代理之间的流量。 RPC 代理和 RPC over HTTP 服务器之间的流量使用普通 RPC 安全机制进行加密,并且不使用 SSL(即使选择了客户端和 RPC 代理之间的 SSL)。 这是因为该部分流量在组织的网络内以及防火墙保护下传输。

除了为 RPC 选择的加密机制之外,还可以使用 SSL 对 RPC over HTTP 客户端和 RPC 代理之间的流量(通常通过 Internet 传输)进行加密。 在这种情况下,路由的互联网部分上的流量将被双重加密。 通过 RPC 代理加密流量可提供辅助防御,以防 RPC 代理或外围网络中的其他计算机受到威胁。 由于 RPC 代理无法解密辅助加密层,因此 RPC 代理无权访问正在发送的数据。 有关详细信息,请参阅 RPC over HTTP 部署建议。 SSL 加密仅适用于 RPC over HTTP v2。

限制对某些计算机的 RPC over HTTP 调用

IIS 安全配置基于允许的计算机和端口范围。 使用 RPC over HTTP 的功能由运行 IIS 和 RPC 代理的计算机上的两个注册表项控制。 第一个条目是切换 RPC 代理功能的标志。 第二个是代理可以将 RPC 调用转发到的计算机的可选列表。

默认情况下,联系 RPC 代理以通过隧道转发 RPC over HTTP 调用的客户端无法访问任何 RPC 服务器进程,但与 RPC 代理在同一计算机上运行的 RPC over HTTP 服务器进程除外。 如果 ENABLED 标志未定义或设置为零值,IIS 将禁用 RPC 代理。 如果定义了 ENABLED 标志并将其设置为非零值,则客户端可以连接到运行 IIS 的计算机上的 RPC over HTTP 服务器。 若要使客户端能够通过隧道连接到另一台计算机上的 RPC over HTTP 服务器进程,必须将注册表项添加到 IIS 计算机的 RPC over HTTP 服务器列表中。

RPC 服务器无法接受 RPC over HTTP 调用,除非它们明确请求 RPC 侦听 RPC over HTTP。

以下示例演示如何配置注册表以允许客户端通过 Internet 连接到服务器:

HKEY_LOCAL_MACHINE\
   Software\Microsoft\Rpc\RpcProxy\Enabled:REG_DWORD
   Software\Microsoft\Rpc\RpcProxy\ValidPorts:REG_SZ

ValidPorts 条目是一个 REG_SZ 条目,其中包含允许 IIS RPC 代理转发 RPC 调用的计算机列表,以及用于连接 RPC 服务器的端口。 REG_SZ 条目采用以下形式:Rosco:593;Rosco:2000-8000;Data*:4000-8000。

在此示例中,IIS 可以通过端口 593 以及 2000 到 8000 将 RPC over HTTP 调用转发至服务器“Rosco”。 它还可以将调用发送到名称以“Data”开头的任何服务器。 它将连接到端口 4000 到 8000。 此外,在将流量转发到 RPC over HTTP 服务器上的给定端口之前,RPC 代理会与侦听该端口的 RPC 服务执行特殊的数据包交换,以验证它是否愿意接受通过 HTTP 发送的请求。

对于基于这些示例设置的示例,如果 RPC 服务侦听服务器“Data1”上的端口 4500,但尚未使用 ncacn_http 调用 RpcServerUseProtseq* 函数之一,它将拒绝该请求。 此行为可为因配置错误而侦听开放端口的服务器提供额外的保护;除非服务器特别请求侦听 RPC over HTTP,否则它将不会接收来自防火墙外部的调用。

ValidPorts 密钥中的条目必须与客户端请求的 RPC over HTTP 服务器完全匹配(不区分大小写)。 为了简化处理,RPC 代理不会对 RPC over HTTP 客户端提供的名称执行规范化。 因此,如果客户端请求 rosco.microsoft.com,并且 ValidPorts 中仅包含 Rosco,RPC 代理将不会匹配这些名称,即使这两个名称可能指的是同一台计算机。 此外,如果 Rosco 的 IP 地址是 66.77.88.99,并且客户端请求 66.77.88.99,但 ValidPorts 密钥仅包含 Rosco,则 RPC 代理将拒绝连接。 如果客户端可能通过名称或 IP 地址请求 RPC over HTTP 服务器,请将两者都插入 ValidPorts 密钥中。

注意

尽管 RPC 已启用 IPv6,但 RPC 代理不支持 ValidPorts 密钥中的 IPv6 地址。 如果使用 IPv6 连接 RPC 代理和 RPC over HTTP 服务器,则只能使用 DNS 名称。

 

IIS 会在启动时读取 EnabledValidPorts 注册表项。 此外,RPC over HTTP 大约每 5 分钟会重新读取一次 ValidPorts 密钥的内容。 如果 ValidPorts 条目发生更改,更改将在 5 分钟内实施。

RPC over HTTP v1:必须使用 Internet Service Manager 停止并重新启动 WEB 服务,才能实现注册表项中的新值。