Compartir a través de

Seguridad RPC sobre HTTP

  • Artículo

RPC sobre HTTP proporciona tres tipos de seguridad además de la seguridad RPC estándar, lo que da como resultado que el tráfico RPC sobre HTTP esté protegido una vez por RPC y, a continuación, doblemente protegido por el mecanismo de tunelización que proporciona RPC sobre HTTP. Para obtener una descripción de los mecanismos de seguridad RPC estándar, consulte Seguridad. El mecanismo de tunelización RPC sobre HTTP se añade a la seguridad RPC normal de la siguiente manera:

  • Proporciona seguridad a través de IIS (disponible solo para RPC sobre HTTP v2).
  • Proporciona cifrado SSL y comprobación del proxy RPC (autenticación mutua). También disponible solo en RPC sobre HTTP v2.
  • Proporciona restricciones en el nivel de proxy RPC que dictan qué máquinas de la red del servidor pueden recibir llamadas RPC sobre HTTP.

Cada una de estas tres características de seguridad se describe con más detalle en las secciones siguientes.

Autenticación IIS

RPC sobre HTTP puede aprovechar el mecanismo de autenticación normal de IIS. El directorio virtual para el proxy RPC se puede configurar mediante el nodo RPC en el sitio web predeterminado en el complemento MMC de IIS:

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

IIS puede configurarse para deshabilitar el acceso anónimo y requerir autenticación en el directorio virtual para el proxy RPC. Para ello, haga clic con el botón derecho en el nodo RPC y seleccione Propiedades. Seleccione la pestaña Seguridad de directorio y haga clic en el botón Editar en el grupo Autenticación y control de acceso, como se muestra aquí:

Screenshot showing the RPC Properties dialog box.

Aunque puede usar RPC sobre HTTP incluso cuando el directorio virtual del proxy RPC permite el acceso anónimo, Microsoft recomienda deshabilitar el acceso anónimo a ese directorio virtual por motivos de seguridad. En su lugar, para RPC sobre HTTP, habilite la autenticación básica, la autenticación integrada de Windows o ambas. Recuerde que solo RPC sobre HTTP v2 puede autenticarse en el proxy RPC que requiere autenticación básica o integrada de Windows; RPC sobre HTTP v1 no podrá conectarse si no se deshabilita No permitir el acceso anónimo. Dado que RPC sobre HTTP v2 es la implementación más segura y sólida, el uso de una versión de Windows que la admita mejorará la seguridad de las instalaciones.

Nota:

De forma predeterminada, el directorio virtual del proxy RPC está marcado para permitir el acceso anónimo. Sin embargo, el proxy RPC para RPC sobre HTTP v2 rechaza las solicitudes que no se autentican de forma predeterminada.

 

Cifrado de tráfico

RPC sobre HTTP puede cifrar el tráfico entre el cliente RPC sobre HTTP y el proxy RPC con SSL. El tráfico entre el proxy RPC y el servidor RPC sobre HTTP se cifra mediante mecanismos de seguridad RPC normales y no usa SSL (incluso si se elige SSL entre el cliente y el proxy RPC). Esto se debe a que esa parte del tráfico viaja dentro de la red de una organización y detrás de un firewall.

El tráfico entre el cliente RPC sobre HTTP y el proxy RPC, que generalmente viaja a través de Internet, se puede cifrar con SSL además del mecanismo de cifrado elegido para RPC. En este caso, el tráfico en la parte de Internet de la ruta se cifra doblemente. El cifrado del tráfico a través del proxy RPC proporciona una defensa secundaria, en caso de que el proxy RPC u otras máquinas de la red perimetral estén en peligro. Dado que el proxy RPC no puede descifrar la capa de cifrado secundaria, el proxy RPC no tiene acceso a los datos que se envían. Consulte Recomendaciones de implementación de RPC sobre HTTP para obtener más información. El cifrado SSL solo está disponible con RPC sobre HTTP v2.

Restricción de llamadas RPC sobre HTTP a determinados equipos

La configuración de seguridad de IIS se basa en los intervalos de puertos y equipos permitidos. La capacidad de usar RPC sobre HTTP se controla mediante dos entradas del Registro en el equipo que ejecutan IIS y el proxy RPC. La primera entrada es una marca que activa la funcionalidad del proxy RPC. La segunda es una lista opcional de equipos a los que el proxy puede reenviar llamadas RPC.

De forma predeterminada, un cliente que se pone en contacto con el proxy RPC para tunelizar llamadas RPC sobre HTTP no puede acceder a ningún proceso de servidor RPC, excepto los procesos del servidor de RPC sobre HTTP que se ejecutan en la misma máquina que el proxy RPC. Si la marca ENABLED no está definida o se establece en un valor cero, IIS deshabilita el proxy RPC. Si se define la marca ENABLED y se establece en un valor distinto de cero, un cliente puede conectarse a servidores RPC sobre HTTP en el equipo que ejecuta IIS. Para permitir que el cliente tunele a un proceso de servidor RPC sobre HTTP en otro equipo, debe agregar una entrada del Registro a la lista de servidores RPC sobre HTTP del equipo IIS.

Los servidores RPC no pueden aceptar llamadas RPC sobre HTTP a menos que hayan solicitado específicamente a RPC que escuche RPC sobre HTTP.

En el ejemplo siguiente se muestra cómo configurar el registro para permitir que los clientes se conecten a servidores a través de Internet:

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

La entrada ValidPorts es una entrada REG_SZ que contiene una lista de equipos a los que el proxy RPC de IIS puede reenviar llamadas RPC y los puertos que debe usar para conectarse a los servidores RPC. La entrada REG_SZ tiene la siguiente forma: Rosco:593;Rosco:2000-8000;Data*:4000-8000.

En este ejemplo, IIS puede reenviar llamadas RPC sobre HTTP al servidor "Rosco" en los puertos 593 y 2000 a 8000. También puede enviar llamadas a cualquier servidor cuyo nombre comience por "Data". Se conectará en los puertos 4000 a 8000. Además, antes de reenviar el tráfico a un puerto determinado del servidor RPC sobre HTTP, el proxy RPC realiza un intercambio de paquetes especial con el servicio RPC que escucha en ese puerto para comprobar que está dispuesto a aceptar solicitudes sobre HTTP.

Para obtener un ejemplo basado en esta configuración de ejemplo, si un servicio RPC escucha en el puerto 4500 en el servidor "Data1", pero no ha llamado a una de las funciones RpcServerUseProtseq* con ncacn_http, rechazará la solicitud. Este comportamiento proporciona protección adicional para los servidores que escuchan en un puerto abierto debido a un error de configuración; a menos que el servidor haya solicitado específicamente que escuche en RPC sobre HTTP, no recibirá llamadas procedentes de fuera del firewall.

Las entradas de la clave ValidPortsdeben ser una coincidencia exacta del servidor RPC sobre HTTP que ha solicitado el cliente (no distingue mayúsculas de minúsculas). Para simplificar el procesamiento, el proxy RPC no realiza la canónicación del nombre que proporciona el cliente RPC sobre HTTP. Por lo tanto, si el cliente solicita rosco.microsoft.com y en ValidPorts solo contiene Rosco, el proxy RPC no hará coincidir los nombres, aunque ambos nombres puedan hacer referencia a la misma máquina. Además, si la dirección IP de Rosco es 66.77.88.99 y el cliente solicita 66.77.88.99, pero la clave ValidPorts solo contiene Rosco, el proxy RPC rechazará la conexión. Si un cliente puede solicitar el servidor RPC sobre HTTP por nombre o por dirección IP, inserte ambos en la clave ValidPorts.

Nota:

Aunque RPC está habilitado para IPv6, el proxy RPC no admite direcciones IPv6 en la clave ValidPorts. Si se utiliza IPv6 para conectar el proxy RPC y el servidor RPC sobre HTTP, solo se pueden utilizar nombres DNS.

 

IIS lee las entradas del Registro Enabled y ValidPorts al iniciarse. Además, RPC sobre HTTP vuelve a leer el contenido de la clave ValidPorts aproximadamente cada 5 minutos. Si se cambia la entrada ValidPorts, los cambios se implementan en 5 minutos.

RPC sobre HTTP v1: el servicio WEB debe detenerse y reiniciarse mediante Internet Service Manager para los nuevos valores de las entradas del Registro que se van a implementar.