Pregunta ¿Puede el servicio de agente de msdeploy abrir un vector de ataque en nuestros servidores?


estamos evaluando el uso del servicio de agente de implementación web de msdeploy para implementaciones automáticas en nuestros servidores de producción.

Una cosa que no podemos descubrir son los posibles impactos en la seguridad.

Por un lado, nuestros servidores web están protegidos (detrás de los cortafuegos y los balanceadores de carga), por lo que solo se permite el tráfico de http (s) desde el exterior.

Sin embargo, el agente de implementación web se ejecuta integrado con IIS (lo único que mira hacia afuera), ya que es accesible a través de http (s). Por lo tanto, tememos que sea potencialmente posible obtener acceso al agente a través de los sitios web alojados en ese IIS, y de este modo obtener acceso de lectura y escritura a todos nuestros sitios web.

¿Qué tan seguro es msdeploy para uso en entornos de producción?

Actualización: el servidor web de producción está ejecutando IIS7.


13
2017-09-08 09:21


origen


¿Está utilizando IIS 6 o 7 con msdeploy? - August
Esto será principalmente IIS7. Información también actualizada. en cuestión. - Sebastian P.R. Gingter


Respuestas:


Ha pasado un tiempo desde que lo usé, y solo lo usé con IIS 6 que no incluye la parte de administración web. Puede modificar el puerto y la URL de administración remota y bloquearlo en el firewall externo. Mira esto: Personalizando y asegurando el servicio remoto. Su principal mecanismo de seguridad parece ser la seguridad de la cuenta del usuario, pero como usted dijo, todo está dentro de IIS, por lo que una vulnerabilidad de IIS podría inutilizar las medidas de seguridad hasta que se apliquen las revisiones. Solo por esa razón, dudaría en permitir la actualización de contenido web desde Internet, pero esto depende de los requisitos de seguridad de su organización frente a las necesidades de su desarrollador web.

Para evitar exponer el servicio de despliegue web a Internet, puede hacer lo siguiente:

  • hacer que el sitio web predeterminado escuche en una IP solo interna que no tenga NAT o parte del rango de IP de equilibrio de carga
  • puede hacer que el sitio web de administración predeterminado escuche solo en localhost, luego escriba un script que llame al ejecutable msdeploy en cada host para que se ejecute localmente (en lugar de usar msdeploy para conectarse de forma remota a todos los hosts desde un solo punto)
  • haga que su equilibrador de carga filtre las solicitudes externas que intenten llegar a la URL de implementación web (por ejemplo, https: // servidor: 8081 / MSDeploy)
  • tenga un host de implementación designado (interno) del que provienen todas sus implementaciones web y solo permita que IP se conecte a sus servidores web en la URL de implementación (bloquee cualquier cosa) no desde el host de despliegue único)

Si aún es necesario tener la funcionalidad de implementación web disponible directamente desde Internet, diga si todos sus desarrolladores web trabajaron de forma remota (no puedo imaginar por qué esto sería necesario). directamente con el uso generalizado de VPN), podría tener un proceso de implementación de 2 etapas en el que configuró un DMZ aislado con un cuadro de IIS 7 habilitado para el Despliegue Web (separado de la DMZ de su granja de servidores web), y permitir que sus desarrolladores web conéctese solo a esa DMZ desde Internet para implementar los cambios de forma remota. Luego, puede conectarse internamente a ese host e implementarlo en el resto de sus servidores web después de revisar los cambios, las pruebas, etc. Sin embargo, incluso este método no está exento de riesgos: un usuario malintencionado puede terminar comprometiendo la funcionalidad de implementación web, presentando algunos código malicioso sin su conocimiento y sin saberlo, podría introducirlo en su entorno de producción.


10
2017-09-12 15:15



Las actualizaciones solo se realizarían desde un acceso VPN seguro a los servidores de producción, por lo que no es necesario acceder desde Internet. Todavía tengo un mal presentimiento sobre la instalación de algo que puede cambiar las configuraciones del servidor web. En este momento, las personas con 'permisos de implementación' solo tienen acceso SFTP a sus carpetas web específicas, los servidores web no están en un dominio y están completamente aislados de cualquier otra forma. - Sebastian P.R. Gingter
normalmente estoy de acuerdo con "Todavía tengo un mal presentimiento sobre la instalación de algo que puede cambiar las configuraciones del servidor web", pero en este caso, donde tiene una granja de servidores web, existe la posibilidad de que configure incorrectamente algo en uno de los servidores y abra un El agujero involuntario a través de un proceso de actualización manual es mucho más probable y arriesgado que habilitar un servicio que asegure una configuración consistente en todos sus servidores web. - August
Bien, lo tomaría como "probablemente es lo suficientemente seguro como para correr el riesgo a cambio de las posibilidades de una implementación automatizada más fácil". Gracias. - Sebastian P.R. Gingter


Respuesta simple SÍ, cualquier cosa que se ejecute en cualquier computadora abre vectores de ataque. Siempre se debe asumir que hay vulnerabilidades en el software. La mitigación es un factor clave, limita el acceso a redes, usuarios, computadoras, IP, etc. También verifica el acceso físico.

También puede restringir el tiempo en el que se permite que se realicen las actualizaciones, si su firewall puede manejar reglas desde momentos específicos del día.

Recomiendo restringir a los usuarios en sus servidores web, es decir, quién puede hacer la actualización. (Probablemente ya has hecho esto) Luego usaría los firewalls para restringir qué redes (IP) tienen acceso a la interfaz de administración. Luego, si fuera compatible, solo permitiría que las actualizaciones se manejen durante las horas de trabajo (a través de una regla de firewall). Tenga en cuenta que siempre puede hacer que el administrador del firewall edite la regla para una actualización de emergencia. Finalmente, observaría las vulnerabilidades conocidas en el Agente de implementación web y mitigaría más, o lo deshabilitaría hasta que se pueda implementar una solución.


0
2017-09-12 16:07