Recomendaciones de implementación de RPC a través de HTTP

En esta sección se documentan los procedimientos recomendados y las configuraciones de implementación recomendadas para lograr la máxima seguridad y rendimiento al usar RPC a través de HTTP. Las distintas configuraciones que se encuentran en este documento se aplican a diferentes organizaciones en función de varios requisitos de tamaño, presupuesto y seguridad. Cada configuración también proporciona consideraciones de implementación útiles para determinar cuál es mejor para un escenario determinado.

Para obtener información sobre escenarios de RPC de gran volumen a través de HTTP, consulte Equilibrio de carga rpc de Microsoft.

Las siguientes recomendaciones se aplican a todas las configuraciones:

• Use versiones de Windows que admitan RPC a través de HTTP v2.
• Coloque IIS en el equipo que ejecuta el proxy RPC en modo IIS 6.0.
• No permitir el acceso anónimo al directorio virtual del proxy RPC.
• No habilite nunca la clave del Registro AllowAnonymous.
• Haga que la RPC a través de clientes HTTP use certificateSubjectField (consulte RpcBindingSetAuthInfoEx para obtener más información) para comprobar que el proxy RPC al que se ha conectado es el proxy RPC que espera.
• Configure la clave del Registro ValidPorts para que contenga solo las máquinas a las que se conectará el RPC a través de clientes HTTP.
• No use caracteres comodín en la clave ValidPorts ; si lo hace, puede ahorrar tiempo, pero una máquina completamente inesperada también puede ajustarse al carácter comodín.
• Use SSL en RPC a través de clientes HTTP. Si se siguen las directrices establecidas en estas secciones, el RPC a través del cliente HTTP no podrá conectarse sin usar SSL.
• Configure RPC a través de clientes HTTP para usar el cifrado RPC además de usar SSL. Si el cliente RPC a través de HTTP no puede acceder al KDC, solo puede usar Negotiate y NTLM.
• Configure las máquinas cliente para que usen NTLMv2. Establezca la clave del Registro LMCompatibilityLevel en 2 o superior. Consulte msdn.microsoft.com para obtener más información sobre la clave LMCompatibilityLevel .
• Ejecute una granja de servidores web de máquinas proxy RPC con la configuración descrita anteriormente.
• Implemente un firewall entre Internet y el proxy RPC.
• Para obtener un rendimiento óptimo, configure IIS para enviar una respuesta breve para códigos de error no correctos. Dado que el consumidor de la respuesta IIS es un proceso automatizado, no es necesario enviar explicaciones fáciles de usar al cliente; simplemente serán omitido por el RPC a través del cliente HTTP.

Los objetivos básicos del proxy RPC desde una perspectiva de seguridad, rendimiento y capacidad de administración son los siguientes:

• Proporcione un único punto de entrada para RPC a través del tráfico HTTP en la red del servidor. Tener un único punto de entrada para RPC a través del tráfico HTTP en una red de servidor tiene dos ventajas principales. En primer lugar, dado que el proxy RPC está orientado a Internet, la mayoría de las organizaciones aíslan estas máquinas en una red especial denominada red perimetral que no es de confianza, que es independiente de la red organizativa normal. Los servidores de una red perimetral que no son de confianza se administran, configuran y supervisan cuidadosamente para poder resistir ataques desde Internet. Cuantos menos máquinas de una red perimetral que no sea de confianza, más fácil es configurar, administrar, supervisar y mantenerlas seguras. En segundo lugar, dado que una única granja de servidores web con servidores proxy RPC instalados puede atender cualquier número de RPC a través de servidores HTTP que residen en la red corporativa, tiene mucho sentido separar el proxy RPC del servidor RPC a través del servidor HTTP y hacer que el proxy RPC resida en una red perimetral que no es de confianza. Si el proxy RPC se encontraba en la misma máquina que rpc a través del servidor HTTP, las organizaciones se verían obligadas a colocar todos sus servidores back-end en una red perimetral que no es de confianza, lo que dificultaría mucho la protección de la red perimetral que no es de confianza. Separar el rol del proxy RPC y rpc a través del servidor HTTP ayuda a las organizaciones a mantener el número de máquinas en una red perimetral que no es de confianza administrable y, por lo tanto, más segura.
• Actúa como fusible de seguridad para la red del servidor. El proxy RPC está diseñado como un fusible para la red del servidor: si algo va mal en el proxy RPC, simplemente sale y, por tanto, protege la RPC real a través del servidor HTTP. Si se han seguido los procedimientos recomendados descritos en esta sección hasta ahora, el tráfico RPC a través de HTTP se cifra con cifrado RPC además de SSL. El propio cifrado RPC está entre el cliente y el servidor, no entre el cliente y el proxy. Esto significa que el proxy no entiende y no puede descifrar el tráfico RPC que recibe. Solo entiende algunas secuencias de control enviadas por el cliente que trabaja con el establecimiento de la conexión, el control de flujo y otros detalles de tunelización. No tiene acceso a los datos que el cliente RPC a través de HTTP envía al servidor. Además, el rpc a través del cliente HTTP debe autenticarse de forma independiente en el proxy RPC y en el servidor RPC a través de HTTP. Esto proporciona defensa en profundidad. Si la máquina proxy RPC se pone en peligro, debido a algún error de configuración o a una infracción de seguridad de algún tipo, los datos que pasan por él siguen siendo seguros de la manipulación. Un atacante que obtendría el control del proxy RPC puede interrumpir el tráfico, pero no leerlo ni manipularlo. Aquí es donde entra en juego el rol de fusible del proxy RPC: se puede gastar sin la seguridad del tráfico RPC a través del tráfico HTTP en peligro.
• Distribuya algunas de las comprobaciones de acceso y el descifrado entre varias máquinas que ejecutan el proxy RPC en una granja de servidores web. Al funcionar bien en una granja de servidores web, el proxy RPC permite a las organizaciones descargar el descifrado SSL y algunas de las comprobaciones de acceso, lo que libera más capacidad en el servidor back-end para su procesamiento. El uso de una granja de servidores web de máquinas proxy RPC también permite a una organización aumentar su capacidad de resistir ataques por denegación de servicio (DoS) aumentando la capacidad en sus servidores front-end.

Dentro de las directrices establecidas hasta ahora, las organizaciones siguen teniendo opciones. Cada organización tiene opciones y riesgos entre las molestias del usuario, la seguridad y el costo:

• Usar autenticación básica o autenticación integrada de Windows para autenticarse en el proxy RPC? RPC a través de HTTP actualmente solo admite NTLM: no admite Kerberos. Además, si hay un proxy HTTP o un firewall entre el cliente RPC a través de HTTP y el proxy RPC que inserta el a través de pragma en el encabezado HTTP, la autenticación NTLM no funcionará. Cuando no es así, las organizaciones pueden elegir entre la autenticación Básica y NTLM. La ventaja de la autenticación básica es que es más rápida y sencilla y, por tanto, ofrece menos oportunidades para ataques de denegación de servicio. Pero NTLM es más seguro. En función de las prioridades de una organización, puede elegir Básico, NTLM o permitir que sus usuarios elijan entre los dos. Si solo se elige una, es mejor desactivar la otra del directorio virtual del proxy RPC para reducir el riesgo de ataque.
• Use el mismo conjunto de credenciales para el proxy RPC y rpc a través del servidor HTTP, o use credenciales diferentes para cada una? El inconveniente de esta decisión es entre la comodidad y la seguridad del usuario. Pocos usuarios les gusta escribir varias credenciales. Sin embargo, si se produce una infracción de seguridad en una red perimetral que no es de confianza, tener conjuntos independientes de credenciales para el proxy RPC y rpc a través del servidor HTTP proporciona protección adicional. Tenga en cuenta que si se usan credenciales independientes y un conjunto de credenciales es las credenciales de dominio del usuario, es aconsejable usar las credenciales de dominio del usuario para rpc a través del servidor HTTP y no para el proxy RPC.