MS Deploy protege el tráfico con TLS en el puerto 8172, pero la cabecera HSTS no se puede aplicar directamente a este servicio porque no actúa como un sitio web convencional; aun así existen prácticas sólidas para reforzar su seguridad.
Contexto de MS Deploy y el puerto 8172
Microsoft Web Deploy instala el Web Management Service (WMSvc), un listener que se registra en HTTP.SYS y escucha peticiones HTTPS en https://servidor:8172/msdeploy.axd. Visual Studio, msdeploy.exe, Azure DevOps Pipelines u otras herramientas se conectan a este extremo para publicar paquetes web, sincronizar archivos o ejecutar comandos remotos.
A diferencia de un sitio IIS, WMSvc:
- No aparece como “Sitio” en el administrador de IIS.
- No tiene
web.configpropio ni módulos de IIS donde insertar directivas como<hsts>. - No sirve contenido HTML a navegadores; las únicas “peticiones” son SOAP/REST específicas del protocolo de despliegue.
HSTS: qué es y por qué no aplica aquí
HTTP Strict‑Transport‑Security es una cabecera pensada para navegadores: cuando un dominio la envía por primera vez con HTTPS, el navegador recuerda durante el periodo indicado (p. ej. un año) que ese dominio solo debe visitarse con HTTPS. Si el usuario teclea http:// será redirigido automáticamente a https:// sin exponer tráfico en claro.
El flujo de MS Deploy no pasa por navegadores ni por peticiones http://; siempre se negocia directamente TLS. Por tanto, añadir HSTS:
- No mejora la seguridad percibida por los clients de despliegue, que ya requieren HTTPS.
- No es aceptado ni procesado por esas herramientas.
- No puede configurarse dentro del propio servicio porque carece de capa HTTP de IIS.
Respuesta breve a la duda original
| ¿Es posible? | Motivo | Alternativas / Soluciones |
|---|---|---|
| No aplica | MS Deploy funciona como un handler de despliegue independiente; no expone la configuración de cabeceras de IIS ni está orientado a tráfico de navegadores donde HSTS es relevante. | 1. Dejarlo tal cual: HSTS solo afecta a navegadores. 2. Situar un proxy inverso (IIS ARR, Nginx, Apache) que termine TLS y añada HSTS, aunque los clientes de MS Deploy la ignorarán. 3. Centrar el esfuerzo en endurecer TLS, credenciales y perímetro de red. |
Análisis técnico de las cabeceras en MS Deploy
Limitaciones del listener WMSvc
El componente se registra con un identificador msdepsvc dentro de HTTP.SYS. Cada vez que llega un paquete TLS se desembolsa al proceso MsDepSvc.exe. No existe la capa de filtrado de módulos (ISAPI, ASP.NET, etc.) que permitiría interceptar y modificar cabeceras.
Diferencias con un sitio IIS convencional
En IIS, un administrador puede:
- Abrir el gestor IIS > Sitio > HTTP Response Headers.
- Agregar “Strict‑Transport‑Security” con valor
max-age=31536000; includeSubDomains; preload. - O bien insertar la sección
<hsts enabled="true" max-age="31536000" includeSubDomains="true" preload="true" />enweb.config.
Ninguna de estas rutas existe para Web Deploy.
Opciones de arquitectura si se desea HSTS de todas formas
Colocar un proxy inverso
Puede dejarse WMSvc escuchando en una red interna y exponer al exterior (o a la DMZ) un servidor que termine TLS:
- IIS Application Request Routing
ReverseProxy.configredirige/msdeployahttps://maquinaInterna:8172/msdeploy.axd. En la pestaña de cabeceras de respuesta se agrega HSTS. - Nginx
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload";proxy_pass https://backend:8172; - Apache httpd con
mod_proxyHeader always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
En los tres casos la cabecera se enviará… pero las herramientas de despliegue la ignorarán. El valor añadido —si lo hay— es proteger cualquier portal HTML extra que se sirva por el mismo proxy.
Refuerzo práctico del canal de despliegue
En lugar de HSTS, enfóquese en controles que sí impactan en MS Deploy:
| Área | Acciones recomendadas | Beneficio |
|---|---|---|
| TLS | Instale certificados con SHA‑256 y clave ≥ 2048 bits. Deshabilite TLS 1.0/1.1 (IISCrypto o registro). Permita solo suites ECDHE+AES_GCM. | Mitiga ataques de deprecados RC4, POODLE y downgrades. |
| Autenticación | Exija autenticación integrada de Windows o certificados de cliente. Deshabilite Basic salvo dentro de túneles VPN. | Evita robo de credenciales. |
| Red | Restrinja el puerto 8172 a IPs de build servers y estaciones de dev. Integre con firewall de capa 7 si existe. | Reduce la superficie expuesta. |
| Auditoría | Active wevtutil set-log Microsoft-IIS-Config/Operations /q:true /e:true. Correlacione con logs de CI. | Rastrea quién despliega qué y cuándo. |
Pruebas de endurecimiento
Tras aplicar los cambios ejecute:
nmap -p 8172 --script ssl-enum-ciphers servidor→ verifica suites abiertas.Test‑TlsCipherSuitede PowerShell.- Revisión manual de los eventos Microsoft‑WebDeploy ID 10001 y 10002.
Preguntas frecuentes
¿Puedo habilitar HSTS tocando el registro de Windows? No. El registro controla TLS, no cabeceras HTTP que pertenecen a la fase de aplicación. ¿Y si recompilo MS Deploy para añadir la cabecera? El código fuente no está disponible; además los clientes no la usarían. El esfuerzo no aporta valor. ¿Un WAF colocará la cabecera automáticamente? Algunos WAF permiten header injection, pero sigue sin beneficiar a MS Deploy. ¿Vale la pena registrar el dominio en la lista preload de HSTS? Solo si el mismo dominio aloja páginas web accesibles a navegadores; no afecta al puerto 8172.
Conclusión
HSTS es una herramienta excelente para sitios web orientados a navegadores, pero su utilidad desaparece en canales técnicos como MS Deploy. Intentar forzar su inclusión implica más complejidad sin ventajas tangibles. En su lugar, concentre sus recursos en:
- Mantener certificados válidos y automatizar su renovación.
- Deshabilitar protocolos y suites débiles.
- Limitar las IP autorizadas y usar credenciales robustas o autenticación de certificados.
- Auditar de forma sistemática cada despliegue.
Con estas medidas, el puerto 8172 quedará adecuadamente protegido frente a los riesgos reales que enfrenta un pipeline de entrega continua.