Quand la plupart des gens entendent parler de « WinRM sur HTTP », ils pensent immédiatement que c'est un désastre en matière de sécurité qui ne demande qu'à se produire. Après tout, on nous répète depuis des années que le protocole HTTP est mauvais et que le protocole HTTPS est bon.
Mais en réalité, l'utilisation du protocole WinRM (Windows Remote Management) est plus nuancée qu'il n'y paraît. Dans de nombreux environnements, le protocole HTTP n'est pas vraiment moins sûr que le protocole HTTPS.
L'idée fausse sur le chiffrement :
Le protocole WinRM sur HTTP est-il intrinsèquement peu sûr ?
La plus grande idée fausse est que WinRM transmet des données en clair via HTTP. Ce n'est pas le cas.
Par défaut, WinRM utilise l'authentification Kerberos ou NT LAN Manager (NTLM) ; les clés secrètes servent à chiffrer le contenu du message au niveau de la couche application, indépendamment du protocole de transport.
Dans WinRM, HTTP n'est qu'un simple canal de transport ; le chiffrement et l'authentification sont gérés au niveau de la couche applicative qui le surpasse. Un pirate qui intercepterait le trafic sur votre réseau ne verrait ni votre commande ni la sortie. Il ne serait pas non plus en mesure de se faire valider auprès du point de terminaison HTTP WinRM.
WinRM a été conçu en tenant compte de cette séparation, ce qui le rend fondamentalement différent, par exemple, d'un site web fonctionnant sous HTTP, où la charge utile est bel et bien en clair.
Qu'apporte réellement le protocole HTTPS ?
Le protocole HTTPS protège l'intégralité de la connexion grâce au protocole TLS (Transport Layer Security), qui offre deux garanties supplémentaires :
- chiffrement au niveau de la couche de transport
- authentification du serveur par certificat
Le chiffrement au niveau de la couche de transport est en grande partie superflu, compte tenu du chiffrement des messages intégré à WinRM.
La validation du certificat est véritablement utile. Elle vous offre une garantie plus solide que vous communiquez bien avec le serveur auquel vous pensez, ce qui contribue à vous protéger contre certains scénarios d'attaques de type « homme au milieu » (MiTM) sur des réseaux non fiables.
Toutefois, sur un réseau interne bien géré, doté de contrôles DNS et Active Directory (AD) adéquats, ces menaces sont déjà considérablement atténuées par d'autres moyens.
Quand l'utilisation de WinRM sur HTTP est tout à fait justifiée
Dans un environnement intégré à un domaine, WinRM sur HTTP offre trois fonctionnalités essentielles pour une gestion à distance sécurisée :
- Intégrité du message
- Le chiffrement des messages, et un
- Un certain niveau d'authentification mutuelle si Kerberos est utilisé
Une mise en garde importante : l'authentification de base doit toujours être désactivée — ce qui est le cas par défaut.
L'authentification de base transmet les identifiants sans aucune protection réelle et constituerait la seule véritable faille de WinRM sur HTTP si elle restait activée. Veillez donc à ce qu'elle reste désactivée.
De nombreux environnements d'entreprise bien établis utilisent WinRM sur HTTP en interne sans que cela n'entraîne d'augmentation notable des risques. De plus, la charge opérationnelle liée à la gestion des certificats pour le protocole HTTPS peut en réalité constituer un risque si elle n'est pas correctement gérée ; les certificats expirés, les autorités de certification mal configurées et les pipelines d'automatisation défaillants sont des problèmes concrets que le protocole HTTP permet d'éviter complètement.
Quand faut-il utiliser le protocole HTTPS ? Lisez d'abord ceci
Le protocole HTTPS est la solution idéale lorsque l'on se connecte via des réseaux non sécurisés.
Cependant, le fait d'utiliser WinRM sur HTTPS sans configurer correctement un jeton de liaison de canal (CBT) peut en réalité vous exposer à un risque de sécurité plus important qu'avec HTTP.
Le protocole CBT lie la procédure d'authentification à un canal TLS spécifique, empêchant ainsi un attaquant de réutiliser les identifiants capturés pour s'authentifier auprès de WinRM au nom de l'utilisateur concerné.
L'utilisation du protocole HTTPS sans CBT peut donner un faux sentiment de sécurité. La connexion est certes chiffrée, mais l'authentification peut toujours faire l'objet d'un relais, ce qui crée une vulnérabilité critique. Sans CBT, les authentifications Kerberos et NTLM sur TLS restent exposées aux attaques par relais.
En revanche, WinRM sur HTTP n'est pas affecté de la même manière, car le trafic est protégé par WinRM grâce aux identifiants d'authentification de l'utilisateur.
Heureusement, Windows active par défaut les tests CBT en mode « Relaxed », ce qui offre une protection dans la plupart des cas.
C:>winrm get winrm/config/service/auth
Auth
Basic = false
Kerberos = true
Negotiate = true
Certificate = false
CredSSP = false
CbtHardeningLevel = Relaxed
Toutefois, il est recommandé de définir explicitement les CBT sur « Strict ».
C:>winrm set winrm/config/service/auth @{CbtHardeningLevel="Strict"}
Cela garantit que seules les tentatives d'authentification correctement associées au canal TLS sont acceptées, ce qui réduit considérablement la surface d'attaque par relais.
Conclusion : optez délibérément pour WinRM sur HTTP
Les décisions en matière de sécurité doivent reposer sur des modèles de menaces concrets, et non sur des préférences protocolaires instinctives.
Dans un environnement de domaine utilisant Kerberos, l'utilisation de WinRM sur HTTP n'est pas une configuration imprudente. Le protocole HTTPS est préférable sur les réseaux non fiables, mais uniquement s'il est correctement configuré. Un déploiement HTTPS dont les paramètres CBT ne sont pas réglés au moins sur la valeur par défaut « Relaxed » (ou, idéalement, sur « Strict ») est sans doute plus dangereux que le protocole HTTP, car il suscite une confiance injustifiée tout en laissant ouvert un vecteur critique de relais d'authentification.
Comprenez le fonctionnement de votre protocole d'authentification. Comprenez la structure de confiance de votre réseau.
