Partager via

Considérations de sécurité pour la connexion à distance via PowerShell avec WinRM

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 versions ultérieures. Ce document traite des problèmes de sécurité, des recommandations et des meilleures pratiques lors de l’utilisation de PowerShell Remoting.

Qu'est-ce que la communication à distance avec PowerShell ?

PowerShell Remoting utilise windows Remote Management (WinRM) pour permettre aux utilisateurs d’exécuter des commandes PowerShell sur des ordinateurs distants. WinRM est l’implémentation Microsoft du protocole Services Web for Management (WS-Management). Vous trouverez plus d’informations sur l’utilisation de la communication à distance PowerShell sur l’exécution de commandes distantes.

PowerShell Remoting n’est pas identique à l’utilisation du paramètre ComputerName d’une applet de commande 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 de PowerShell

PowerShell pour la communication à distance avec WinRM écoute sur les ports suivants :

  • HTTP : 5985
  • HTTPS : 5986

Par défaut, La communication à distance PowerShell autorise uniquement les connexions des membres du groupe Administrateurs. Les sessions sont lancées dans le contexte de l’utilisateur, de sorte que tous les contrôles d’accès au système d’exploitation appliqués à des utilisateurs et groupes individuels continuent de s’y appliquer tout en étant connectés via la communication à distance PowerShell.

Sur les réseaux privés, la règle de pare-feu Windows par défaut pour PowerShell Remoting 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 explicitement modifier cette règle pour activer PowerShell à distance sur 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 connexion externe potentiellement malveillantes. Utilisez la prudence lors de la suppression de cette règle.

Isolation des processus

PowerShell Remoting utilise WinRM pour la communication entre les ordinateurs. WinRM s’exécute en tant que service sous le compte de service réseau et génère des processus isolés s’exécutant en tant que comptes d’utilisateur pour héberger des instances PowerShell. Une instance de PowerShell s’exécutant en tant qu’utilisateur n’a aucun accès à un processus exécutant une instance de PowerShell en tant qu’autre utilisateur.

Journaux d’événements générés par PowerShell Remoting

Les chercheurs de Mandiant ont présenté une session à la conférence BlackHat, qui fournit un bon résumé des journaux des événements et d'autres preuves de sécurité générées par les sessions PowerShell Remoting. Pour plus d’informations, consultez Examen des attaques PowerShell.

Protocoles de chiffrement et de transport

Il est utile de prendre en compte la sécurité d’une connexion à distance PowerShell de deux points de vue : l’authentification initiale et la communication continue.

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

Authentification initiale

L’authentification confirme l’identité du client sur le serveur et idéalement le serveur du client.

Lorsqu’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 à la fois l’identité de l’utilisateur et l’identité du serveur sans envoyer de sorte d’informations d’identification réutilisables.

Lorsqu’un client se connecte à un serveur de domaine à l’aide de son adresse IP ou qu’il se connecte à un serveur de groupe de travail, l’authentification Kerberos n’est pas possible. Dans ce cas, PowerShell Remoting s’appuie sur le protocole d’authentification NTLM. Le protocole d’authentification NTLM garantit l’identité de l’utilisateur sans envoyer de sorte d’informations d’identification délégables. Pour prouver l’identité de l’utilisateur, le protocole NTLM exige que le client et le serveur calculent une clé de session à partir du mot de passe de l’utilisateur sans jamais échanger le mot de passe lui-même. Le serveur ne connaît généralement pas le mot de passe de l’utilisateur. Il communique donc avec le contrôleur de domaine, qui connaît le mot de passe de l’utilisateur et calcule la clé de session du serveur.

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

L’authentification basée sur NTLM est désactivée par défaut. Vous pouvez activer NTLM 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 basées sur NTLM

Étant donné que le protocole d’authentification NTLM ne peut pas garantir l’identité du serveur cible (uniquement qu’il connaît déjà votre mot de passe), vous pouvez configurer les 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 approuvée par le client) active l’authentification basée sur NTLM qui garantit à la fois l’identité de l’utilisateur et l’identité du serveur.

Ignorer les erreurs d’identité de serveur basée sur NTLM

Si le déploiement d'un certificat SSL sur un serveur pour les connexions NTLM est infaisable, vous pouvez masquer les erreurs d'identité qui en résultent en ajoutant le serveur à la liste WinRM TrustedHosts. L’ajout d’un nom de serveur à la liste TrustedHosts ne doit pas être considéré comme une forme d’instruction de la fiabilité des hôtes eux-mêmes, car le protocole d’authentification NTLM ne peut pas garantir que vous vous connectez en fait à l’hôte auquel vous envisagez de vous connecter. Au lieu de cela, vous devez considérer le paramètre TrustedHosts comme la liste des hôtes pour lesquels vous souhaitez supprimer l’erreur générée en étant incapable de vérifier l’identité du serveur.

Communication en cours

Une fois l’authentification initiale terminée, WinRM chiffre la communication en cours. Lorsque vous vous connectez via HTTPS, WinRM utilise le protocole TLS pour négocier le chiffrement utilisé pour transporter les données. Lorsque vous vous connectez via HTTP, WinRM utilise le chiffrement au niveau du message négocié par le protocole d’authentification initial.

  • L’authentification de base ne fournit aucun chiffrement.
  • L’authentification NTLM utilise un chiffrement RC4 avec une clé 128 bits.
  • Le etype ticket TGS détermine le chiffrement d’authentification Kerberos. Il s’agit d’AES-256 sur les systèmes modernes.
  • Le chiffrement CredSSP utilise la suite de chiffrement TLS négociée lors de l'échange initial.

Effectuer le deuxième saut

Par défaut, PowerShell Remoting utilise Kerberos (le cas échéant) ou NTLM pour l’authentification. Ces deux protocoles s’authentifient auprès de l’ordinateur distant sans lui envoyer d’informations d’identification. Il s’agit du moyen le plus sécurisé de s’authentifier, mais parce que l’ordinateur distant n’a pas les informations d’identification de l’utilisateur, il ne peut pas accéder à d’autres ordinateurs et services au nom de l’utilisateur. Il s’agit du problème du deuxième saut.

Il existe plusieurs façons d’éviter ce problème. Pour obtenir des descriptions de ces méthodes, ainsi que les avantages et les inconvénients de chacune, consultez Effectuer le deuxième saut dans PowerShell Remoting.

références

  • Last updated on