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

estamos evaluando el uso del servicio del 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 de seguridad.

Por un lado, nuestros servidores web están, por supuesto, protegidos (detrás de firewalls y equilibradores de carga), por lo que solo se permite el tráfico 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 pueda ser posible obtener acceso al agente a través de las páginas web alojadas en ese IIS, y de este modo obtener acceso de lectura y escritura a todas nuestras páginas web.

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

Actualización: el servidor web de producción ejecuta IIS7.

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. Consulte esto: Personalización y seguridad del servicio remoto . Su principal mecanismo de seguridad parece ser la seguridad de la cuenta de usuario, pero como usted dijo, todo está dentro de IIS, por lo que una vulnerabilidad de IIS podría hacer que las medidas de seguridad sean inútiles hasta que se reparen. 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 implementación web a Internet, puede hacer lo siguiente:

• hacer que el sitio web predeterminado escuche en una IP solo interna que no sea NAT o que forme 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 una secuencia de comandos 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 intentan llegar a la URL de implementación web (por ejemplo, https: // servidor: 8081 / MSDeploy )
• tener un host de implementación designado (interno) de donde provienen todas sus implementaciones web y solo permitir que esa IP se conecte a sus servidores web en la URL de implementación (bloquee todo lo que no sea del host de implementación único)

Si todavía existe la necesidad de 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 directamentecon el uso generalizado de VPN), podría tener un proceso de implementación de 2 etapas en el que configure una DMZ aislada con un cuadro IIS 7 habilitado para Web Deploy (separado de la DMZ de su granja de servidores web) y permita que sus desarrolladores web conéctese solo a esa DMZ desde Internet para implementar 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, probar, etc. Incluso este método no está exento de riesgos: un usuario malintencionado puede terminar comprometiendo la funcionalidad de implementación web, introduciendo algunos código malicioso sin su conocimiento y podría introducirlo sin saberlo en su entorno de producción.

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

También podría restringir el tiempo que se permite que ocurran las actualizaciones, si su firewall puede manejar reglas de 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 haya hecho esto). Luego usaría los firewalls para restringir qué redes (IP) tienen acceso a la interfaz de administración. Entonces, si es 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, estaría atento a las vulnerabilidades conocidas en el Agente de implementación web y mitigaría aún más, o lo deshabilitaría hasta que se pueda implementar una solución.