Durcir WinRM et la communication à distance PowerShell

WinRM est le transport sous-jacent de la communication à distance PowerShell, de winrs, de Server Manager, de Windows Admin Center, de JEA et de Windows Event Forwarding. C'est aussi l'un des canaux de mouvement latéral les plus utilisés, car un identifiant d'administrateur valide plus un port 5985 ouvert équivalent, par conception, à une exécution de code à distance. Le guide pilier sur la sécurité de PowerShell liste les trois paramètres de base. Ce guide couvre le reste : ce qui écoute réellement, comment imposer une authentification forte, comment ajouter HTTPS et comment limiter qui peut l'atteindre.

Les valeurs par défaut à connaître

Les valeurs par défaut d'authentification sont sûres. Le problème, c'est la dérive : un programme d'installation d'éditeur, une session de dépannage ou un script trouvé en ligne active Basic, règle TrustedHosts sur * ou ajoute un écouteur sur toutes les interfaces. La stratégie l'empêche.

Étape 1 : inventorier ce qui est réellement configuré

Sur un échantillon de serveurs et de postes de travail, relevez les écouteurs, les paramètres d'authentification et les points de terminaison :

winrm enumerate winrm/config/listener
Get-ChildItem WSMan:\localhost\Service\Auth
Get-ChildItem WSMan:\localhost\Client\Auth
Get-Item WSMan:\localhost\Service\AllowUnencrypted
Get-Item WSMan:\localhost\Client\TrustedHosts
Get-PSSessionConfiguration | Select-Object Name, Permission
Get-LocalGroupMember -Group 'Remote Management Users'

Cherchez les écouteurs HTTP sur des postes qui n'en ont pas besoin, les écouteurs de compatibilité sur les ports 80 ou 443, un TrustedHosts non vide, Basic ou CredSSP à true, et des membres inattendus de Remote Management Users. Tout membre de ce groupe peut ouvrir une session PowerShell distante sur la machine sans être administrateur.

Étape 2 : imposer authentification et chiffrement par GPO

Sous Computer Configuration > Policies > Administrative Templates > Windows Components > Windows Remote Management (WinRM) :

WinRM Service

WinRM Client

Les équivalents registre se trouvent sous HKLM\SOFTWARE\Policies\Microsoft\Windows\WinRM\Service et ...\WinRM\Client (par exemple AllowBasic = 0, AllowUnencryptedTraffic = 0, DisableRunAs = 1). Les référentiels de sécurité Microsoft et CIS définissent la plupart de ces paramètres ; imposez-les là où les référentiels ne s'appliquent pas.

CredSSP mérite une remarque. On l'active généralement pour résoudre le « double saut » (une session distante qui doit atteindre un partage de fichiers). Les meilleures réponses sont la délégation contrainte basée sur les ressources, un point de terminaison JEA s'exécutant sous un gMSA, ou le passage explicite d'un objet d'identifiants à la seconde commande. Chacune évite de laisser un identifiant complet sur le serveur intermédiaire.

Étape 3 : préférer Kerberos, voire Kerberos seul

Kerberos fournit une authentification mutuelle : le client sait qu'il parle au vrai serveur. NTLM, vers lequel Negotiate se replie, ne le fait pas, et reste exposé au NTLM relay. Negotiate se replie sur NTLM quand vous vous connectez par adresse IP, à un hôte hors domaine ou à un nom sans SPN.

Trois niveaux, par ordre de sévérité croissante :

1. Se connecter par FQDN et garder TrustedHosts vide. Les clients utilisent alors Kerberos pour les hôtes du domaine et refusent NTLM vers les serveurs non authentifiés sur HTTP.
2. Restreindre NTLM à l'échelle du domaine avec les stratégies d'audit et de restriction NTLM, pour que les replis apparaissent dans les journaux avant d'être bloqués.
3. Désactiver Negotiate sur les serveurs Tier 0. Dans la stratégie WinRM Service, réglez Disallow Negotiate authentication = Enabled. Les clients doivent alors se connecter avec -Authentication Kerberos.

Enter-PSSession -ComputerName dc01.corp.example -Authentication Kerberos

Testez soigneusement l'option 3. Server Manager, Windows Admin Center et de nombreux scripts utilisent Negotiate par défaut et échoueront tant qu'ils ne seront pas reconfigurés.

Étape 4 : ajouter des écouteurs HTTPS là où ils sont nécessaires

HTTPS ajoute l'authentification du serveur par certificat et TLS. Vous en avez besoin pour les hôtes hors domaine et les serveurs en groupe de travail, entre forêts sans approbation, et partout où la politique exige TLS sur le réseau. Émettez un certificat depuis votre autorité de certification interne avec l'EKU Server Authentication et le FQDN de l'hôte dans le sujet ou le SAN, idéalement par inscription automatique. Ensuite :

$fqdn = [System.Net.Dns]::GetHostEntry($env:COMPUTERNAME).HostName
$cert = Get-ChildItem Cert:\LocalMachine\My |
  Where-Object { $_.Subject -eq "CN=$fqdn" -and $_.EnhancedKeyUsageList.FriendlyName -contains 'Server Authentication' } |
  Sort-Object NotAfter -Descending | Select-Object -First 1

New-Item -Path WSMan:\localhost\Listener -Transport HTTPS -Address * `
  -CertificateThumbPrint $cert.Thumbprint -Force

Les clients se connectent avec -UseSSL. N'utilisez pas de certificats auto-signés avec -SkipCACheck et -SkipCNCheck en dehors d'un laboratoire : cela jette l'authentification du serveur pour laquelle vous avez ajouté HTTPS.

L'écouteur est lié à une empreinte et ne suit pas le renouvellement du certificat. Mettez-le à jour depuis votre gestion de configuration après chaque renouvellement :

Set-WSManInstance -ResourceURI winrm/config/Listener `
  -SelectorSet @{ Address = '*'; Transport = 'HTTPS' } `
  -ValueSet @{ CertificateThumbprint = $cert.Thumbprint }

Une fois que tous les outils de gestion utilisent HTTPS, vous pouvez supprimer l'écouteur HTTP sur les serveurs sensibles. Laissez-le en place là où les collecteurs Windows Event Forwarding ou des outils dépendent encore du port 5985.

Étape 5 : restreindre qui peut atteindre WinRM

Le contrôle WinRM le plus efficace n'est pas un paramètre WinRM. C'est le pare-feu hôte. Seuls les serveurs de rebond, les stations d'administration privilégiées (PAW) et les serveurs de gestion ont besoin d'atteindre 5985/5986.

• Dans la GPO de pare-feu, remplacez la règle intégrée Windows Remote Management (HTTP-In) par des règles dont l'adresse distante correspond à vos sous-réseaux de gestion, pour 5985 comme pour 5986. Voir durcir le pare-feu Windows et gérer la stratégie de pare-feu à grande échelle.
• Sur les postes de travail, bloquez entièrement WinRM en entrée sauf si un outil précis en a besoin.
• Ne comptez pas sur Allow remote server management through WinRM pour cela. Son filtre IPv4/IPv6 contrôle les adresses locales sur lesquelles l'écouteur se lie, pas les clients distants autorisés à se connecter.

Restreignez aussi qui peut s'authentifier une fois le port atteint. Gardez Remote Management Users vide ou étroitement contrôlé, et rappelez-vous que les comptes d'administrateur local sont soumis aux restrictions à distance de l'UAC. Laissez ces restrictions actives comme décrit dans UAC et Administrator protection.

Autorisations des points de terminaison

Chaque point de terminaison de communication à distance a son propre descripteur de sécurité. Get-PSSessionConfiguration les affiche. Les points de terminaison par défaut (microsoft.powershell, microsoft.powershell32 et, s'il est installé, PowerShell.7) autorisent Administrators et Remote Management Users. Des éditeurs enregistrent parfois des points de terminaison supplémentaires aux autorisations plus larges, et les points de terminaison JEA définissent les leurs via les définitions de rôle. Revoyez la liste après chaque déploiement logiciel, supprimez les points de terminaison inutilisés avec Unregister-PSSessionConfiguration, et traitez l'apparition d'un nouveau point de terminaison sur un serveur comme une modification de configuration qui doit avoir un propriétaire. Sur les serveurs sensibles où personne ne devrait utiliser la communication à distance complète, vous pouvez restreindre les points de terminaison par défaut à un groupe d'administrateurs Tier 0 dédié avec Set-PSSessionConfiguration -SecurityDescriptorSddl et publier des points de terminaison JEA pour tout le reste.

Ce qui casse

• Server Manager et Windows Admin Center échouent contre les hôtes où Negotiate est désactivé ou seul HTTPS est disponible, tant qu'ils ne sont pas configurés pour Kerberos ou HTTPS.
• Les scripts qui se connectent par adresse IP cessent de fonctionner avec un TrustedHosts vide. C'est voulu ; corrigez-les pour utiliser des noms.
• Les flux à double saut qui reposaient sur CredSSP cassent. Migrez-les vers la délégation contrainte ou un point de terminaison JEA adossé à un gMSA.
• Le transfert d'événements s'arrête si vous désactivez le service WinRM sur les sources, ou si vous bloquez 5985 sur le collecteur. Voir Windows Event Forwarding à grande échelle.
• Les certificats expirés cassent silencieusement les écouteurs HTTPS. Surveillez l'expiration des certificats des écouteurs.

Vérifier

# Stratégie appliquée ?
Get-Item WSMan:\localhost\Service\AllowUnencrypted          # false
Get-ChildItem WSMan:\localhost\Service\Auth                  # Basic false, CredSSP false
Get-Item WSMan:\localhost\Client\TrustedHosts                # vide

# Kerberos et HTTPS fonctionnent depuis un hôte de gestion
Test-WSMan -ComputerName srv01.corp.example -UseSSL
Invoke-Command -ComputerName srv01.corp.example -UseSSL -ScriptBlock { hostname }

# Bloqué depuis un poste de travail ordinaire (doit expirer)
Test-NetConnection srv01.corp.example -Port 5985

Pour la détection, les sessions distantes apparaissent sous forme de processus wsmprovhost.exe sur la cible (4688 ou Sysmon 1), d'ouvertures de session réseau (4624 de type 3) et d'entrées dans Microsoft-Windows-WinRM/Operational. Alertez sur les sessions WinRM vers des serveurs qui ne proviennent pas de vos sous-réseaux de gestion, et sur les modifications de configuration WinRM hors de votre processus de changement. La page thématique Sécurité de PowerShell rassemble les guides associés, dont JEA pour restreindre ce que ces sessions peuvent faire.

Liste de contrôle

• Écouteurs, paramètres d'authentification, TrustedHosts et autorisations des points de terminaison inventoriés
• Basic, trafic non chiffré, CredSSP et Digest désactivés par GPO (service et client)
• Stockage des identifiants RunAs interdit ; écouteurs de compatibilité désactivés
• TrustedHosts vide ; connexions par FQDN avec Kerberos
• Negotiate désactivé sur les serveurs Tier 0 après tests
• Écouteurs HTTPS avec certificats émis par une AC là où c'est nécessaire ; empreinte mise à jour au renouvellement
• Ports entrants 5985/5986 autorisés uniquement depuis les sous-réseaux de gestion
• Appartenance à Remote Management Users revue
• Détections des sessions WinRM et des modifications de configuration en place