Considérations de sécurité concernant l’accès distant à PowerShell avec WinRM

Article
04/02/2024

La communication à distance PowerShell est la méthode recommandée pour gérer les systèmes Windows. La communication à distance PowerShell est activée par défaut dans Windows Server 2012 R2 et ultérieur. Ce document couvre les questions de sécurité, les recommandations et les bonnes pratiques lors de l’utilisation de la communication à distance PowerShell.

Présentation de la communication à distance PowerShell

La communication à distance PowerShell utilise Windows Remote Management (WinRM) pour permettre aux utilisateurs d’exécuter des commandes PowerShell sur des ordinateurs distants. WinRM est l’implémentation par Microsoft du protocole Web Services for Management (WS-Management). Pour plus d’informations sur l’utilisation de la communication à distance PowerShell, voir Exécution de commandes à distance.

La communication à distance PowerShell n’équivaut pas à l’utilisation du paramètre ComputerName d’une cmdlet pour l’exécuter sur un ordinateur distant, qui utilise l’appel de procédure distante (RPC) comme protocole sous-jacent.

Paramètres par défaut de la communication à distance PowerShell

La communication à distance PowerShell et WinRM écoutent sur les ports suivants :

HTTP : 5985
HTTPS : 5986

Par défaut, la communication à distance PowerShell autorise uniquement les connexions des membres du groupe de l’administrateur. Les sessions étant lancées dans le contexte de l’utilisateur, tous les contrôles d’accès au système d’exploitation appliqués à des utilisateurs et des groupes continuent de leur être appliqués pendant la connexion via la communication à distance PowerShell.

Sur les réseaux privés, la règle de Pare-feu Windows par défaut pour la communication à distance PowerShell accepte toutes les connexions. Sur les réseaux publics, la règle de Pare-feu Windows par défaut autorise les connexions de communication à distance PowerShell uniquement sur le même sous-réseau. Vous devez modifier explicitement cette règle pour ouvrir la communication à distance PowerShell à toutes les connexions sur un réseau public.

Avertissement

la règle de pare-feu pour les réseaux publics est destinée à protéger l’ordinateur contre les tentatives de connexions externes potentiellement malveillantes. Soyez prudent lors de la suppression de cette règle.

Isolation des processus

La communication à distance PowerShell utilise WinRM pour la communication entre les ordinateurs. WinRM s’exécute comme service sous le compte de service réseau et génère des processus isolés exécutés comme comptes d’utilisateur pour héberger les instances de PowerShell. Une instance de PowerShell exécutée comme un utilisateur n’a pas accès à un processus utilisant une instance de PowerShell exécutée comme autre utilisateur.

Journaux des événements générés par la communication à distance PowerShell

FireEye a fourni un bon résumé des journaux des événements et autres preuves de sécurité générés par les sessions de communication à distance PowerShell, disponible sur Investigating PowerShell Attacks.

Protocoles de transport et chiffrement

Il est utile de considérer la connexion de la communication à distance PowerShell sous deux angles : l’authentification initiale et la communication en cours.

Quel que soit le protocole de transport utilisé (HTTP ou HTTPS), WinRM chiffre toujours l’intégralité des communications à distance PowerShell après l’authentification initiale.

Authentification initiale

L’authentification confirme l’identité du client auprès du serveur et, idéalement, du serveur auprès du client.

Quand un client se connecte à un serveur de domaine à l’aide de son nom d’ordinateur, le protocole d’authentification par défaut est Kerberos. Kerberos garantit l’identité de l’utilisateur et l’identité du serveur sans envoyer aucune sorte d’informations d’identification réutilisables.

Quand un client se connecte à un serveur de domaine avec son adresse IP ou qu’il se connecte à un serveur de groupe de travail, l’authentification Kerberos n’est pas possible. Dans ce cas, la communication à distance PowerShell s’appuie sur le protocole d’authentification NTLM. Le protocole d’authentification NTLM garantit l’identité de l’utilisateur sans envoyer aucune sorte d’informations d’identification délégables. Pour prouver l’identité de l’utilisateur, le protocole NTLM nécessite que le client et le serveur calculent une clé de session à partir du mot de passe de l’utilisateur sans jamais s’échanger le mot de passe proprement dit. Le serveur ne connaissant en général pas le mot de passe de l’utilisateur, il communique avec le contrôleur de domaine qui connaît ce mot de passe et calcule la clé de la session pour le serveur.

Le protocole NTLM ne garantit cependant pas l’identité du serveur. Comme avec tous les protocoles qui utilisent NTLM pour l’authentification, un pirate ayant accès au compte d’un ordinateur appartenant à un domaine peut appeler le contrôleur de domaine pour calculer une clé de session NTLM et donc emprunter l’identité du serveur.

L’authentification NTLM est désactivée par défaut, mais peut être autorisée en configurant SSL sur le serveur cible ou en configurant le paramètre WinRM TrustedHosts sur le client.

Utilisation de certificats SSL pour valider l’identité du serveur pendant les connexions NTLM

Comme le protocole d’authentification NTLM ne peut pas garantir l’identité du serveur cible (il connaît seulement déjà votre mot de passe), vous pouvez configurer des serveurs cibles pour utiliser SSL pour la communication à distance PowerShell. L’attribution d’un certificat SSL au serveur cible (s’il est émis par une autorité de certification également approuvée par le client) active l’authentification NTLM qui garantit l’identité de l’utilisateur et l’identité du serveur.

Erreurs d’identité de serveur NTLM ignorées

S’il n’est pas possible de déployer un certificat SSL sur un serveur pour les connexions NTLM, vous pouvez supprimer les erreurs d’identité obtenues en ajoutant le serveur à la liste TrustedHosts de WinRM. Notez que l’ajout d’un nom de serveur à la liste TrustedHosts ne doit pas être considéré comme une garantie de fiabilité des hôtes, car le protocole d’authentification NTLM ne peut pas garantir que vous vous connectez réellement à l’hôte souhaité. Vous devez plutôt considérer le paramètre TrustedHosts comme représentant la liste des hôtes pour lesquels vous voulez supprimer l’erreur générée par l’impossibilité de vérifier l’identité du serveur.

Communications en cours

Une fois l’authentification initiale terminée, WinRM chiffre toutes les communications en cours. Lors de la connexion via HTTPS, le protocole TLS est utilisé pour négocier le chiffrement qui est utilisé pour le transport des données. Lors de la connexion via HTTP, le chiffrement au niveau du message est déterminé par le protocole utilisé lors de l’authentification initiale.

L’authentification de base ne fournit pas de chiffrement.
L’authentification NTLM utilise un chiffrement RC4 avec une clé de 128 bits.
Le chiffrement de l’authentification Kerberos est déterminé par le etype du ticket TGS. Sur les systèmes modernes, il s’agit de AES-256.
Le chiffrement CredSSP utilise la suite de chiffrement TLS qui a été négociée lors de l’établissement de la liaison.

Second saut

Par défaut, la communication à distance PowerShell utilise Kerberos (s’il est disponible) ou NTLM pour l’authentification. Ces deux protocoles permettent de s’authentifier auprès de l’ordinateur distant sans lui envoyer d’informations d’identification. C’est la méthode la plus sûre pour s’authentifier mais comme l’ordinateur distant ne dispose pas des informations d’identification de l’utilisateur, il ne peut pas accéder à d’autres ordinateurs ni à d’autres services au nom de l’utilisateur. Ce problème est connu sous le nom de « deuxième saut ».

Il existe plusieurs moyens de l’éviter. Pour connaître la description de ces méthodes, ainsi que les avantages et les inconvénients de chacune, consultez Effectuer le deuxième saut dans la communication à distance PowerShell.