Bundesamt für Sicherheit in der Informationstechnik

M 4.421 Absicherung der Windows PowerShell

Verantwortlich für Initiierung: IT-Sicherheitsbeauftragter, Leiter IT

Verantwortlich für Umsetzung: Administrator

Die Windows PowerShell (WPS) ist eine .NET-basierte Skriptumgebung für die interaktive Systemadministration mittels so genannter Cmdlets. WPS kann auch administrative Skripte ausführen. Skripte sind eine Auflistung von einzelnen Kommandos, die in einer Textdatei gespeichert und in der Kommandozeile aufgerufen werden.

Wenn die WPS nicht benötigt wird, sollte sie deinstalliert werden.

Ab Windows 7 lässt sich die PowerShell-Skriptumgebung nur noch entfernen, indem das .NET-Framework deinstalliert wird. Ist dieses für andere Applikationen notwendig, müssen für die PowerShell-Umgebung folgende Sicherheitsaspekte beachtet werden:

Auf 64-Bit-Systemen existieren parallel eine 32-Bit-PowerShell und eine 64-Bit-PowerShell. Die 32-Bit-Umgebung verwendet die 32-Bit-Emulationsschicht SysWOW64 für den Zugriff auf das Dateisystem und die Registrierung. SysWOW64 kann zu Fehlfunktionen beim Zugriff auf Systembereiche führen. Außerdem können 32-Bit-Skripte Unverträglichkeiten mit der 64-Bit-Umgebung aufweisen und umgekehrt. Daher sollte auf 64-Bit-Systemen nur die 64-Bit-PowerShell verwendet werden. Skripte, die auf einem 32-Bit-System erstellt und getestet wurden, sollten nicht auf einem 64-Bit-System verwendet werden.

Mit Veröffentlichung der Version 3.0 wurde der Funktionsumfang der PowerShell durch die Einführung neuer Cmdlets erhöht. Eine weitere neu eingeführte Funktion ist der PowerShell Web Access, mit dem sich die PowerShell auch über einen Webbrowser nutzen lässt und somit auch auf Geräten angewendet werden kann, die nicht kompatibel mit der aktuellen PowerShell-Version sind (z. B. mobile Geräte). Zur Nutzung auf einem anderen Server ist die Aktivierung der PowerShell-Remote-Unterstützung notwendig und die Einrichtung eines PowerShell Web Access Gateways erforderlich. Die auf dem System installierte Version der PowerShell kann mit dem Befehl get-host ermittelt werden.

Schutz vor ungewollten Änderungen

Sofern die PowerShell mit aktivierten Administratorrechten ausgeführt wird, besitzt diese vollen Zugriff auf den Computer. Fehleingaben könnten somit zu Schäden führen, oder ungewollt ausgeführte Skripte (Schadsoftware) können weitreichende Zugriffe auf das System vornehmen. Aus diesem Grund wird empfohlen, die PowerShell nicht unter uneingeschränkten Administratorrechten auszuführen. Grundsätzlich sollten nur jene Befehle mit Administratorrechten ausgeführt werden, für die dies erforderlich ist und mit deren Funktionsweise der aufrufende Administrator vertraut ist. Sofern die Benutzerkontensteuerung auf dem System aktiv ist, verfügt die normale PowerShell-Konsole über keine Administratorrechte.

Absicherung auf Dateiebene

Nur Administratoren sollten die Programmdateien C:\Windows\System32\WindowsPowerShell\powershell.exe und powershell_ise.exe aufrufen dürfen. Aus diesem Grund sollte in den Sicherheitseinstellungen dieser Dateien nur die Gruppe der Administratoren das Ausführen-Recht erhalten. Auf 64-Bit-Systemen befinden sich die 32-Bit-Versionen im Ordner C:\Windows\SysWOW64\WindowsPowerShell und müssen ebenfalls abgesichert werden.

Es sollte überlegt werden, den Zugriff auf bestimmte Administratorkonten zu beschränken, beispielsweise wenn die automatische Ausführung von Skripten oder die Ausführung von Skripten über das Netz vorgesehen ist. Hierzu bietet es sich an, eine eigene Sicherheitsgruppe lokal oder in einer Domäne zu definieren und ihr die notwendigen Berechtigungen auf die Programmdateien zu geben.

Hinweis: Bei Programmen, die Berechtigungen auf die Ausführung von WPS besitzen, dürfen die Sicherheitsgruppen System und TrustedInstaller nicht entfernt werden!

Absicherung des PowerShell-Profils

Das benutzerspezifische PowerShell-Profil, das beim Aufruf von WPS geladen wird, sollte abgesichert werden. In der WPS kann mit dem Befehl $profile ermittelt werden, welche Datei das Profil für den aktuell angemeldeten Benutzer enthält. Das Profil liegt normalerweise in einem Ordner innerhalb des Windows-Benutzerprofils, auf den nur der Benutzer selbst sowie Administratoren Zugriff haben. Das PowerShell-Profil ist eine Konfigurationsdatei, über die das Aussehen der Shell konfiguriert werden kann, und über die auch eigene Aliase und Funktionen definiert werden können. Über die Profildatei kann auch die Einbindung von Cmdlets von Drittherstellern erfolgen. Um unberechtigte Zugriffsversuche auszuschließen, sollte die Objektüberwachung für die Profil-Dateien aktiviert werden (Näheres siehe M 4.344 Überwachung von Windows-Systemen ab Windows Vista und Windows Server 2008). Insbesondere ist bei den Profildateien jede Gruppe, die generelle Änderungsrechte besitzt, auch als SACL (System Access Control List) hinzuzufügen (Eigenschaften | Sicherheit | Erweitert | Überwachung). Die Überwachungsereignisse sollten stichprobenartig in der Ereignisanzeige ausgewertet werden.

Absicherung der Skript-Ausführung

Ebenso ist die Absicherung der ausgeführten Skripte notwendig. Besondere Bedeutung kommt dem PowerShell-Profil zu, da es benutzerspezifisch beim Aufruf von WPS gestartet wird. Die Ausführung von Skripten kann, auch ohne dass ein administrativer Zugriff auf Betriebssystemkomponenten erfolgt, für die Stabilität und Integrität des Betriebssystems und der Applikationen kritisch sein. Aus diesem Grund sollten die folgenden ausführbaren Skript-Dateien und Hilfsdateien auf Dateisystemebene mit entsprechend eingeschränkten Berechtigungen versehen werden:

  • .ps1-Dateien: Windows PowerShell Shell-Skript
  • .ps1xml-Dateien: Windows PowerShell Format- und Typdefinitionen
  • .psc1-Dateien: Windows PowerShell Konsolendatei (exportierte Shell-Konfiguration)
  • .psd1-Dateien: Windows PowerShell Datendatei
  • .psm1-Dateien: Windows PowerShell Moduldatei

Die Ändern-Berechtigung an den Skripten sollte auf bestimmte Gruppen eingeschränkt werden, um die Integrität der Skripte zu gewährleisten.

Die Ausführung von PowerShell-Skripten sollte außerdem mit dem Befehl Set-ExecutionPolicy eingeschränkt werden. Hierbei wird festgelegt, welche Bedingungen Skripte erfüllen müssen, um ausgeführt zu werden. Folgende Optionen sind möglich:

  • Restricted: Die Ausführung von Skripten ist gänzlich unterbunden (Standard-Einstellung).
  • AllSigned: .Ps1 und .Ps1xml-Dateien müssen digital signiert sein, um ausgeführt werden zu können.
  • RemoteSigned: Skripte, die lokal erstellt wurden, können ohne Signatur ausgeführt werden.
  • Unrestricted: Alle Skripte können ohne Einschränkungen ausgeführt werden.

Die Ausführung von PowerShell-Skripten sollte auf signierte Skripte eingeschränkt werden. Hierzu wird in der PowerShell-Umgebung folgender Befehl ausgeführt:

Set-ExecutionPolicy AllSigned

Die Ausführung von Skripten kann auch zentral über Gruppenrichtlinien gesteuert werden:

Skriptausführung aktivieren unter Richtlinie Computerkonfiguration | Administrative Vorlagen | Windows-Komponenten | Windows PowerShell

Signieren von PowerShell-Skripten

Das Signieren von Skripten erfordert ein Authenticode-Codesignaturzertifikat der Klasse 3, das auf dreierlei Weise bezogen werden kann.

Institutionen, die über eine interne Public Key Infrastruktur (PKI) verfügen, können das notwendige Zertifikat selbst erzeugen, wenn die zugehörige interne Zertifizierungsstelle von allen IT-Systemen im an die PKI angeschlossenen Informationsverbund als vertrauenswürdig eingestuft wird.

Die zweite Möglichkeit besteht darin, eine externe Zertifizierungsstelle (Certification Authority, CA) zu verwenden. Clients ab Windows Vista sind bereits so konfiguriert, dass sie den Zertifikaten der führenden externen CAs vertrauen.

Die dritte Möglichkeit besteht darin, ein selbst signiertes Zertifikat mithilfe des Tools Makecert.exe zu erstellen. Dieses kostenlose Tool wird mit dem Windows Plattform-SDK geliefert und in einigen Editionen von Microsoft Office automatisch installiert. Der Nachteil besteht darin, dass ein Zertifikat immer nur auf dem IT-System eingesetzt werden kann, auf dem es erzeugt wurde. Für die Ausführung von PowerShell-Skripten über das Netz, beispielsweise als Anmeldeskript (siehe M 2.326 Planung der Gruppenrichtlinien für Clients ab Windows XP), ist eine interne oder externe Zertifizierungsstelle zu empfehlen.

Prüffragen:

  • Ist in der Windows PowerShell die Ausführbarkeit der Dateien von WPS auf Dateiebene den Gruppen der Administratoren, lokal und Domäne vorbehalten?

  • Ist eine Protokollierung von Schreib- und Lesezugriffen auf das Windows PowerShell-Profil eingerichtet, und werden die Protokolle regelmäßig ausgewertet?

  • Ist die Ausführung von Windows PowerShell-Skripten mit dem Befehl Set-ExecutionPolicy AllSigned oder durch eine Gruppenrichtlinie eingeschränkt worden?

Stand: 15. EL Stand 2016