RPC a través de seguridad HTTP

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

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

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

Autenticación de IIS

RPC a través de 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:

IIS se puede configurar 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 de seguridad de directorio de y haga clic en el botón editar de en el grupo autenticación y control de acceso de, como se muestra aquí:

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

Cifrado de tráfico

RPC a través de HTTP puede cifrar el tráfico entre rpc a través del cliente HTTP y el proxy RPC con SSL. El tráfico entre el proxy RPC y RPC a través del servidor 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 a través del cliente 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 RPC a través de recomendaciones de implementación HTTP para obtener más información. El cifrado SSL solo está disponible con RPC a través de HTTP v2.

Restricción de RPC a través de llamadas 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 a través de 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 RPC a través de llamadas HTTP no puede acceder a ningún proceso de servidor RPC, excepto los procesos rpc a través del servidor 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 RPC a través de servidores HTTP en el equipo que ejecuta IIS. Para permitir que el cliente tunele a un proceso rpc a través del servidor HTTP en otro equipo, debe agregar una entrada del Registro a la lista de RPC del equipo IIS a través de servidores HTTP.

Los servidores RPC no pueden aceptar RPC a través de llamadas HTTP a menos que hayan solicitado específicamente RPC que escuchen en RPC a través de 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; Datos*:4000-8000.

En este ejemplo, IIS puede reenviar RPC a través de llamadas 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 en el servidor RPC a través del servidor HTTP, el proxy RPC realiza un intercambio de paquetes especial con el servicio RPC escuchando en ese puerto para comprobar que está dispuesto a aceptar solicitudes a través de 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 de 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 a través de HTTP, no recibirá llamadas procedentes de fuera del firewall.

Las entradas del ValidPorts clave deben ser una coincidencia exacta del RPC a través del servidor HTTP solicitado por el cliente (no distingue mayúsculas de minúsculas). Para simplificar el procesamiento, el proxy RPC no realiza la canónicación del nombre proporcionado por rpc a través del cliente HTTP. Por lo tanto, si el cliente solicita rosco.microsoft.com y, en ValidPorts solo contienen Rosco, el proxy RPC no coincidirá con los nombres, aunque ambos nombres puedan hacer referencia al mismo equipo. 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 contiene solo Rosco, el proxy RPC rechazará la conexión. Si un cliente puede solicitar el RPC a través del servidor HTTP por nombre o por dirección IP, inserte ambos en la clave validPorts.

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

RPC a través de HTTP v1: El servicio WEB debe detenerse y reiniciarse mediante Internet Service Manager para que se implementen nuevos valores en las entradas del Registro.