Dans quelle mesure est-il sûr d'activer WinRM / PSRemoting sur un ordinateur connecté à Internet?

5

Dans quelle mesure est-il sûr de rendre le point de terminaison Powershell distant (aussi appelé PSRemoting) d’un serveur de production accessible depuis Internet?
Nous ne sommes pas une banque ou quoi que ce soit, mais le serveur contient des données d'entreprise sensibles.

J'ai l'intention de le sécuriser par:

  • Utiliser le filtrage IP pour n'accepter que les connexions de notre propre plage IP publique, afin que nous puissions le gérer à partir d'une autre partie de notre réseau.
  • Avoir le terminal accepte uniquement les connexions SSL
  • Autoriser uniquement les connexions d'un nombre limité d'utilisateurs avec un mot de passe complexe (entropie de 150 bits environ)
  • Utilisation d'une configuration PSSessionConfiguration LanguageModedéfinie sur NoLanguage, de sorte que seuls les scripts puissent être exécutés
  • Exiger que tous les scripts Powershell exécutés de cette manière soient signés ( Set-ExecutionPolicy RemoteSigned)

D'autre part:

  • Les scripts distants seront exécutés sous un compte administrateur local
  • sans restrictions sur les Cmdlets / Modules qu’il peut invoquer.
  • Je soupçonne que le service WinRM (qui rend PSRemoting possible) est suffisamment sûr pour être exposé à Internet (les ordinateurs virtuels Azure l'ont par défaut), mais je n'ai aucune preuve de cela.

Donc, je suppose que ma question est la suivante: est-ce "sûr" ou existe-t-il des vecteurs d'attaque qui me manquent ici?

En passant, la plupart de mes informations proviennent de la télécommande gratuite eBook Secrets of Powershell .

Astrotrain
la source
PowerShell Web Access est installé sur le serveur 2012 .
EVIL

Réponses:

3

En règle générale, vous ne devez jamais rien ouvrir depuis Internet vers un serveur de production, sauf s’il s’agit d’un service que vous souhaitez que le public utilise. Si la machine est un serveur Web, seul le port 80 devrait lui être ouvert. Si aucun autre port n'est ouvert via le pare-feu, l'attaquant n'a aucun moyen d'entrer.

Un réseau privé virtuel serait la meilleure solution, car les utilisateurs devaient s'authentifier puis accéder aux systèmes de production uniquement de l' intérieur . Un VPN est beaucoup plus flexible et sécurisé que toute autre méthode.

Keltari
la source
1
J'en ai discuté avec l'un des responsables de la mise en réseau et nous allons probablement utiliser un VPN. Merci pour votre réponse.
Astrotrain
2

Quelques choses qui pourraient aider:

  1. Ajoutez vos clients à la liste TrustedHosts .

    Set-Item wsman:\localhost\Client\TrustedHosts -Value Server01.Domain01.Fabrikam.com
    
  2. Créez un script d'analyse de journal qui extrait les adresses IP incorrectes de vos journaux et crée des règles de pare-feu pour bloquer ces adresses IP. (Excusez ma technique d'écriture PS :-))

    Obtenez le contenu d'un fichier dont l'adresse IP est incorrecte dans le journal d'activité. J'ai créé un script qui a scanné mon fichier de journal Web propriétaire et a trouvé des clients sondant mon serveur Web. J'ai donc laissé leur adresse IP dans le fichier badips.txt.

    $ips = get-content c:\powershell\utilities\badips.txt
    

    Maintenant, je crée une règle de pare-feu pour bloquer la mauvaise adresse IP

    foreach ($i in $ips){
    [string]$rulename = "disallow-" + $i
    [string]$remoteip = $i + "/32"
    [string]$description = $i
    

    Obtenir la liste des adresses IP défectueuses ayant déjà une règle de blocage

    $processed = get-content c:\powershell\utilities\processedips.txt
    

    Vérification dans la liste pour voir si l'adresse IP est déjà bloquée

    $count = ($processed|select-string $i).count
    

    S'il s'agit d'une nouvelle adresse IP, créez une règle de pare-feu et ajoutez l'adresse IP au fichier texte de liste traité.

    if ($count -lt 1){
    invoke-expression ("netsh advfirewall firewall add rule name=" + $rulename + " action=block enable=yes
    localip=any dir=in profile=public remoteip=" + $remoteip + " description=" + $description)
    $i|add-content c:\powershell\utilities\processedips.txt
    }}
    

Cela ne répond pas vraiment à votre question sur la protection de votre serveur, mais vous donne deux éléments supplémentaires pour limiter les menaces potentielles.

Nous les peuples
la source
Avertissement concernant les listes TrustedHosts de "Secrets of PowerShell Remoting": "L'ajout du nom de l'ordinateur distant (..) à la liste WinRM TrustedHosts de votre ordinateur local désactive fondamentalement l'authentification mutuelle. (..) Configurez l'ordinateur distant pour qu'il accepte HTTPS. (..) ceci permet au certificat SSL de fournir l’authentification mutuelle recherchée par WinRM. "
Astrotrain