Vous publiez en Web Deploy sur le port 8172 et un scanner vous impose HSTS ? Cet article clarifie pourquoi l’en‑tête Strict‑Transport‑Security ne s’applique pas à MS Deploy/WMSvc, et propose des solutions concrètes pour réussir vos audits sans casser vos pipelines.
Vue d’ensemble de la question
La question revient souvent lors d’audits : « Comment ajouter l’en‑tête Strict-Transport-Security (HSTS) au service de publication Microsoft Web Deploy qui écoute sur le port 8172 ? » En contexte IIS, on a l’habitude d’activer HSTS au niveau des sites Web pour forcer les navigateurs à rester en HTTPS. Mais Web Deploy n’est pas un site IIS : il s’appuie sur le Web Management Service (wmsvc), un service Windows qui écoute via HTTP.SYS et parle directement avec les clients de déploiement (msdeploy.exe, Visual Studio, agents CI/CD). Résultat : les mécanismes classiques d’ajout d’en‑têtes (règles IIS, <hsts>, web.config) ne s’appliquent pas à ce port.
Réponse courte et message clé
Non, on ne peut pas activer HSTS directement sur le port 8172 de MS Deploy/WMSvc. Et ce n’est pas un problème : HSTS est un en‑tête destiné aux navigateurs, tandis que les clients Web Deploy sont des outils non‑navigateurs qui n’interprètent pas HSTS. Si un audit exige quand même HSTS, la voie réaliste consiste à placer un reverse‑proxy HTTPS qui injecte l’en‑tête, et à restreindre l’accès direct au port 8172 (VPN/bastion/pare‑feu).
Pourquoi HSTS ne s’applique pas à Web Deploy
- Des clients non‑navigateurs : HSTS est un signal de sécurité lu par les navigateurs pour « coller » à HTTPS.
msdeploy.exe, Visual Studio ou un agent CI ne gèrent pas ce mécanisme, et ne basculent pas automatiquement dehttp://vershttps://en réponse à HSTS. Ils se connectent à l’URL exacte que vous leur donnez, en TLS si vous mettezhttps://. - WMSvc n’est pas un site IIS : le port 8172 est servi par HTTP.SYS au nom du service « Web Management Service ». Il ne passe pas par le pipeline IIS d’un site où l’on pourrait ajouter des en‑têtes via
web.configou une règle URL Rewrite. Il n’existe pas d’API ou de paramètre pour injecter des en‑têtes arbitraires dans les réponses de WMSvc. - Aucun bénéfice fonctionnel : forcer un navigateur à utiliser HTTPS ne change rien au dialogue binaire de Web Deploy, déjà chiffré en TLS (si vous ciblez
https://). L’ajout de HSTS serait purement cosmétique pour les scanners, et n’apporte rien aux clients MS Deploy.
Ce que Microsoft permet… et ne permet pas
Il n’existe pas de commutateur « Activer HSTS » pour WMSvc, ni de moyen supporté d’ajouter des en‑têtes personnalisés sur le port 8172. À l’inverse, vous pouvez évidemment activer HSTS sur les sites Web IIS (port 443) via l’élément <hsts> ou via une en‑tête personnalisée ; mais cela ne s’applique qu’au trafic traité par ces sites, pas à WMSvc.
Où HSTS est‑il pertinent ?
| Point d’entrée | Port | Moteur | Clients | HSTS possible ? | Commentaire |
|---|---|---|---|---|---|
| Site Web IIS (production) | 443 | IIS (pipeline) | Navigateur | Oui | Activer <hsts> ou un en‑tête personnalisé. |
| Web Management Service (WMSvc) | 8172 | Service Windows + HTTP.SYS | MS Deploy | Non | Pas d’injection d’en‑têtes, clients non‑navigateurs. |
| Web Deploy Agent Service (MsDepSvc) | 80 (par défaut) | Service Windows | MS Deploy | Non pertinent | Ne pas exposer sur Internet. Chiffrer via proxy/VPN si besoin. |
| Reverse‑proxy HTTPS devant WMSvc | 443 | ARR / Nginx / HAProxy | MS Deploy | Oui | Injecte HSTS côté frontal. Restreindre l’accès direct à 8172. |
Stratégies de conformité si un audit exige HSTS
- Réduire la surface d’attaque : limitez l’exposition du 8172 (pare‑feu, listes blanches IP, VPN, bastion). Sur site Windows, fermez l’écoute aux seules adresses internes ou au bastion de déploiement.
- Interposer un reverse‑proxy HTTPS : terminez TLS au proxy, ajoutez l’en‑tête HSTS, puis relayer en HTTPS ou en TCP interne vers 8172. Les scanners verront HSTS côté frontal, tandis que MS Deploy continuera de fonctionner inchangé.
- Changer de mode de déploiement (si compatible avec vos contraintes) : par exemple, publier via un mécanisme déjà servi par un site IIS standard (Git, WebHooks CI, etc.), sur lequel HSTS est natif. Attention : cela impacte vos pipelines et vos rôles de délégation.
- Documenter l’exception : HSTS ne s’applique pas à un protocole non destiné aux navigateurs. Les auditeurs PCI‑DSS acceptent généralement une justification étayée + des compensations (segmentation, journalisation, durcissement TLS).
Implémenter un reverse‑proxy qui injecte HSTS
Trois options courantes : Nginx, IIS ARR ou HAProxy. Le principe est identique : exposer un point d’entrée HTTPS « propre » (443), y ajouter HSTS, puis proxyfier vers https://votre‑cible:8172/msdeploy.axd. Enfin, bloquez l’accès direct au 8172 depuis l’extérieur.
Nginx (exemple)
server {
listen 443 ssl http2;
server_name deploy.example.com;
ssl\_certificate /etc/letsencrypt/live/deploy.example.com/fullchain.pem;
ssl\_certificate\_key /etc/letsencrypt/live/deploy.example.com/privkey.pem;
ssl\_protocols TLSv1.2 TLSv1.3;
# HSTS pour les scanners et les navigateurs
add\_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;
# Relais vers WMSvc
location /msdeploy.axd {
proxy\_pass [https://win-iis.internal:8172/msdeploy.axd](https://win-iis.internal:8172/msdeploy.axd);
proxy\_http\_version 1.1;
proxy\_set\_header Host \$host;
proxy\_set\_header Connection "";
proxy\_ssl\_server\_name on; # SNI si le certificat du 8172 en a besoin
proxy\_ssl\_verify on; # Vérifiez le certificat amont
proxy\_ssl\_trusted\_certificate /etc/ssl/certs/ca-bundle.crt;
client\_max\_body\_size 0; # gros packages MS Deploy
}
# Optionnel : refuser tout le reste
location / { return 403; }
} IIS ARR (IIS en frontal)
- Installez URL Rewrite et Application Request Routing (ARR) sur un serveur frontal.
- Créez un site IIS d’entrée sur 443 (certificat valide public).
- Ajoutez une règle Reverse Proxy vers
https://127.0.0.1:8172/msdeploy.axd(ou vers le serveur cible interne). - Dans Configuration du site → En‑têtes HTTP personnalisés :
- Ajoutez :
Strict-Transport-Security=max-age=31536000; includeSubDomains; preload.
- Ajoutez :
- (Optionnel) Forcez la redirection 80 → 443 pour satisfaire les scanners.
Exemple de web.config au niveau du site frontal :
<configuration>
<system.webServer>
<httpProtocol>
<customHeaders>
<add name="Strict-Transport-Security" value="max-age=31536000; includeSubDomains; preload" />
</customHeaders>
</httpProtocol>
<rewrite>
<rules>
<rule name="Force-HTTPS" enabled="true" stopProcessing="true">
<match url="(.*)" />
<conditions>
<add input="{HTTPS}" pattern="off" ignoreCase="true" />
</conditions>
<action type="Redirect" url="https://{HTTP_HOST}/{R:1}" redirectType="Permanent" />
</rule>
</rules>
<outboundRules>
<preConditions><preCondition name="Always"><add input="{RESPONSE_STATUS}" pattern=".*" /></preCondition></preConditions>
</outboundRules>
</rewrite>
</system.webServer>
</configuration>
HAProxy (exemple)
global
tune.ssl.default-dh-param 2048
defaults
mode http
timeout connect 5s
timeout client 1m
timeout server 1m
frontend fe\_https
bind :443 ssl crt /etc/haproxy/certs/deploy.pem alpn h2,http/1.1
http-response set-header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
use\_backend be\_wmsvc if { path\_beg /msdeploy.axd }
http-request deny if !{ path\_beg /msdeploy.axd }
backend be\_wmsvc
server wmsvc 10.0.0.5:8172 ssl verify required ca-file /etc/ssl/certs/ca-bundle.crt sni str(wmsvc.internal) Restreindre l’accès direct au 8172
Le reverse‑proxy n’est utile que si le 8172 n’est plus accessible depuis Internet. Bloquez‑le au pare‑feu et n’autorisez que le proxy (ou un bastion/VPN).
# PowerShell (exemple) : autoriser 8172 uniquement depuis le proxy
New-NetFirewallRule -DisplayName "WMSvc from proxy only" `
-Direction Inbound -Action Allow -Protocol TCP -LocalPort 8172 `
-RemoteAddress 203.0.113.10 -Profile Any
# Bloquer tout le reste
New-NetFirewallRule -DisplayName "WMSvc block all" \`
-Direction Inbound -Action Block -Protocol TCP -LocalPort 8172 -Profile Any Durcissement TLS de l’hôte WMSvc
Même si HSTS ne s’applique pas, durcir TLS reste essentiel. Sur Windows Server, désactivez SSL 3.0, TLS 1.0/1.1 et les suites faibles, et forcez TLS 1.2+ (ou 1.3 si disponible). Exemple de registre via PowerShell :
# Désactiver TLS 1.0 / 1.1 côté serveur
New-Item -Path "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Server" -Force | Out-Null
New-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Server" -Name "Enabled" -Type DWord -Value 0 -Force | Out-Null
New-Item -Path "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Server" -Force | Out-Null
New-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Server" -Name "Enabled" -Type DWord -Value 0 -Force | Out-Null
# (Redémarrage requis)
Vérifiez aussi que WMSvc utilise un certificat serveur valide (chaîne complète, SAN approprié). Un certificat autosigné fait échouer certains clients et déclenche des alertes de scanners.
Comptes, authentification et délégation MS Deploy
- Rôles minimaux : affectez uniquement les droits nécessaires (Deployers, délégations spécifiques au site et aux fournisseurs MS Deploy).
- Basic Auth : si vous l’activez, exigez des mots de passe forts et des rotations. Basic + TLS reste sûr, mais attention aux fuites locales de journaux.
- Journalisation : activez le logging diagnostic côté
msdeploy.exe(-verbose,-enableRule:AppOfflineselon le scénario) et corrélez avec les journaux de sécurité Windows (échecs/succès d’authentification).
Tester et valider
Après mise en place du proxy :
- Test HSTS : exécutez
curl -I https://deploy.example.com/msdeploy.axd. Vous devez voirStrict-Transport-Security:dans la réponse du proxy. - Test MS Deploy : côté client, la commande historique reste identique, seule l’URL change vers le frontal :
msdeploy -verb:sync -source:package="app.zip" ^ -dest:auto,computerName="https://deploy.example.com/msdeploy.axd?site=MonSite",userName="deployer",password="***",authType="Basic" - Bloquage direct : vérifiez qu’un
Test-NetConnection serveur:8172échoue depuis Internet (ou une machine de test externe).
Tableau de décision : quelle stratégie choisir ?
| Stratégie | Effort | Bénéfices | Impacts & limites |
|---|---|---|---|
| Limitation par pare‑feu/VPN | Faible à moyen | Réduit l’exposition ; simple | Nécessite une exception documentée pour HSTS |
| Reverse‑proxy + HSTS | Moyen | Éteint l’alerte HSTS des scanners | Gestion certif, supervision du proxy, point d’échec supplémentaire |
| Changer de mode de déploiement | Élevé | Aligné sur un site IIS (HSTS natif) | Re‑outillage, régression possible des pipelines |
| Exemption audit + compensations | Faible | Rapide, sans changement technique | Nécessite une gouvernance sécurité solide |
FAQ
HSTS cassera‑t‑il MS Deploy ?
Non. Les clients MS Deploy ignorent HSTS. L’en‑tête, s’il est ajouté par un proxy, est inoffensif et transparent pour l’outil.
Peut‑on écrire une règle IIS pour le port 8172 ?
Non. Le trafic 8172 est servi par WMSvc via HTTP.SYS, en dehors du pipeline IIS d’un site. Les règles URL Rewrite, web.config et <hsts> ne le voient pas.
Et si on tente d’appeler http:// ?
Évitez. Le client doit toujours pointer une URL https://. HSTS n’aidera pas un client non‑navigateur à « se souvenir » de passer en HTTPS.
Peut‑on publier sans WMSvc ?
Il existe d’autres modes (Agent Service, déploiements hors MS Deploy : FTP(S), Git, pipelines natifs). Choisissez‑les uniquement si vos contraintes les justifient ; chacun a ses compromis de sécurité et d’exploitation.
Modèle de justification pour audit
Le point d’entrée évalué est Microsoft Web Deploy via Web Management Service (port 8172).
HSTS s’applique aux navigateurs web ; MS Deploy est un client non-navigateur qui ne traite pas l’en-tête HSTS.
Le service WMSvc, opéré via HTTP.SYS, ne permet pas l’injection d’en-têtes personnalisés.
Mesures compensatoires : exposition restreinte (pare-feu/VPN), TLS 1.2+ durci, certificats valides,
journalisation et contrôle d’accès. Lorsque le flux doit être exposé, un reverse-proxy HTTPS
injecte HSTS côté frontal. L’exigence « HSTS obligatoire » n’est donc pas applicable à ce service,
et/ou est satisfaite au périmètre frontal.Checklist opérationnelle
- Le client MS Deploy utilise bien
https://vers le frontal. - Le frontal renvoie
Strict-Transport-Security(vérifié viacurl -I). - Le port 8172 n’est plus accessible depuis Internet (pare‑feu testé).
- TLS 1.2/1.3 activé, suites faibles désactivées sur l’hôte.
- Certificat serveur valide (SAN, chaîne complète).
- Rôles et délégations MS Deploy minimaux ; journaux activés.
Résumé
HSTS est hors sujet pour MS Deploy/WMSvc : ce service n’est pas un site IIS, ses clients ne sont pas des navigateurs, et il n’existe pas de paramètre pour injecter des en‑têtes. Pour satisfaire un audit sans perturber vos déploiements, combinez segmentation réseau, reverse‑proxy HTTPS avec HSTS et durcissement TLS. Cette approche ferme l’alerte des scanners, tout en respectant l’architecture supportée par Microsoft.
En bref : ne cherchez pas à « forcer » HSTS sur 8172 ; sécurisez l’accès et, si nécessaire, ajoutez HSTS au périmètre via un proxy.