¿Cómo mantiene Windows / IIS un certificado protegido o nunca debería ejecutar el servidor web Apache en un servidor Windows?

Question

¿Cómo mantiene Windows / IIS un certificado protegido o nunca debería ejecutar el servidor web Apache en un servidor Windows?

#1 de Tom Leek (14 votos)

7

Si sigo el razonamiento de un colega, parece que nunca debe ejecutar Apache Webserver o Tomcat en un servidor de Windows si desea mantener seguro el certificado https.

Permítame explicarle antes de que esta pregunta se convierta en una batalla de trolls entre Windows y Linux.

Por ejemplo, cuando se utiliza Apache Tomcat para un sitio web https, la clave privada se almacena en un almacén de claves. Para que Tomcat pueda usar esta clave, tenemos tres opciones:

No usar contraseña en el almacén de claves;
La contraseña del almacén de claves se debe ingresar al iniciar el servicio Tomcat;
La contraseña del almacén de claves se establece en texto sin formato en un archivo de configuración.

Usar la opción 3 parece ser el más practicado. Pero cualquiera que tenga acceso a este archivo y al almacén de claves puede extraer la clave privada. Obviamente, puede proteger el sistema de archivos del archivo de almacenamiento de claves y de configuración. Sin embargo, parece que Linux ofrece más opciones para separar el acceso a esos archivos para diferentes procesos. Este razonamiento llevó a la conclusión con la que comencé.

No estoy familiarizado con cómo Windows o IIS manejan esto, pero espero que esto funcione de alguna manera similar bajo el capó. Mi problema es que no estoy seguro. ¿Cómo puede IIS usar el certificado en Windows si nadie ingresa su contraseña? ¿O simplemente se almacena en el registro en lugar de un archivo de configuración? ¿Y es la configuración de seguridad de certificado alta igual a la opción 2?

¿Podría alguien explicarme cómo funciona esto?

Por cierto. No estoy interesado en HSM. Por ahora, me interesa saber si Windows IIS protege un certificado o una clave privada que no utiliza la opción 3 y cómo lo hace.

He buscado, pero no pude encontrar respuestas concluyentes. He navegado 30 páginas etiquetadas con "certificados" y he usado Google. Me resulta difícil extraer una respuesta definitiva de ellos. A continuación menciono las fuentes que encontré de alguna ayuda. Realmente espero que pueda ayudarme o indicarme la fuente correcta.

Seguridad en stackExchange:

¿Qué tan segura es mi clave privada en el certificado digital de Windows? tienda?
¿Cómo debo almacenar las claves SSL en el servidor?
¿Cómo almacenar una clave RSA privada para una aplicación?
¿Cuáles son algunas buenas prácticas de diseño para certificados multiplataforma? almacenamiento?

Microsoft:

[Blog de TechNet] ¿Qué es una protección de clave sólida en Windows?
[TechNet, EFS] Cómo se almacenan las claves privadas

Varios sitios:

[ServerFault] Cómo administrar una protección de clave privada SSL de un servidor web (contraseña vs. ninguna contraseña)?
[CodingHorror] Manteniendo Privadas las Claves Privadas
[SecurityInnovation] Cómo probar un almacén de claves inseguro Vulnerabilidades
[RootSecurity] Cómo exportar certificados "no exportables" de la Tienda de certificados de Microsoft
[Symantec] Cómo los atacantes roban claves privadas de certificados digitales

tls certificates webserver iis

pregunta Gos Bilgon 19.12.2013 - 20:52

fuente

1 respuesta

Lea otras preguntas en las etiquetas tls certificates webserver iis

Comprobación de revocación del certificado del sitio web - ¿Gran cosa? [duplicar] stack overflow overflow en la función principal? [cerrado]

score 14 · Answer 1

Un comentario genérico es el siguiente: si puede reiniciar la máquina, y el servidor vuelve a funcionar automáticamente, sin ninguna intervención humana, entonces, por definición, el contenido del disco de la máquina contiene todo lo que La máquina necesita acceder a la clave privada. En consecuencia, alguien que obtenga acceso completo a la máquina (como "root" en Linux, "Administrator" en Windows) también podrá recuperar la clave privada.

En Windows, las claves privadas basadas en software se almacenan en la DPAPI . Para resumir la historia, la clave privada se vincula a una cuenta (la cuenta propia de la máquina para la tienda "Máquina local") y la protección depende en última instancia del cifrado utilizando la contraseña de la cuenta como clave. Para un IIS que se inicia automáticamente, la contraseña correspondiente debe escribirse en algún lugar de las entrañas del sistema. Puede haber capas de cifrado e indirección, pero puede ser desenredado por cualquier persona con suficientes derechos. Consulte esta respuesta para obtener sugerencias sobre cómo hacerlo. que prácticamente.

Además, si alguien obtiene privilegios administrativos en la máquina en vivo, entonces puede adjuntarse al proceso del servidor web en ejecución y saquear sus contenidos de RAM directamente, con ReadProcessMemory () .

Por lo tanto, cualquier protección será, en última instancia, relativa a qué tan bien el sistema operativo evitará que usuarios no autorizados obtengan privilegios de administrador. Desde ese punto de vista, no hay mucha diferencia entre Apache / Tomcat e IIS: puede almacenar la clave privada para Apache en un archivo y configurar alguna ACL para que este archivo sea legible solo para el usuario específico que ejecutará Apache. Las personas con derechos administrativos podrán omitir eso, pero, como se explicó anteriormente, pueden hacer cualquier cosa en la máquina.

Ahora puede haber sutilezas cuantitativas. Hasta el núcleo de la máquina, está el núcleo; El código del núcleo, por definición, es Dios. Puede leer y escribir toda la memoria RAM, acceder a todo el hardware. El núcleo también es el guardián que decide quién puede hacer qué. En la vista del núcleo, cada código aplicativo se ejecuta con un conjunto de privilegios, que describen exactamente lo que puede hacer el código. Algunos privilegios son equivalentes a dios, lo que significa que un proceso que tiene ese privilegio puede organizarse, más o menos directamente, para obtener el mismo poder que el núcleo. En un sistema Linux tradicional, cualquier proceso de raíz es equivalente a dios, ya que la raíz puede crear y cargar módulos del kernel, es decir, código personalizado directamente en el kernel. Por transitividad, cualquier proceso que pueda tomar el control de un proceso con privilegios equivalentes a dios también es equivalente a dios.

Los procesos equivalentes a Dios son objetivos jugosos para los atacantes. Hay más procesos de este tipo, cuanto más probable es que uno de ellos tenga una vulnerabilidad explotable que le permita al atacante alcanzar la divinidad. Por lo tanto, reducir el tamaño y el alcance del proceso equivalente a Dios puede ayudar a aumentar la seguridad práctica. Aún habrá, en lo más profundo de la máquina, algún código equivalente a dios (aunque solo sea el núcleo), pero el ajuste fino puede ayudar a mantener ese código pequeño.

Linux y Windows, de manera predeterminada, son aproximadamente equivalentes a ese respecto (muchos procesos que se ejecutan como cuenta raíz / sistema), pero ofrecen diferentes herramientas para recortar eso. En Linux jugarías con chroot y, más generalmente, SELinux . En Windows puede hacer muchos ajustes y restricciones con las Políticas de grupo. En ambos casos, es bastante fácil cerrarse, así que tenga cuidado.

Resumen: No hay nada malo con Apache / Tomcat en Windows. Las protecciones aplicadas a las claves privadas utilizadas por IIS no son cualitativamente diferentes, ni más fuertes, que los derechos de acceso a los archivos. Un buen administrador del sistema logrará un nivel de seguridad similar en ambos casos, en la misma máquina.

En cualquier caso, le recomendamos que no permita que ningún usuario sin privilegios ejecute código arbitrario en servidores con datos confidenciales. La experiencia muestra que cuando los atacantes pueden ejecutar código sin privilegios localmente, la cantidad de agujeros explotables aumenta bruscamente.