M 4.421 Absicherung der Windows PowerShell
Verantwortlich für Initiierung: Leiter IT, IT-Sicherheitsbeauftragter
Verantwortlich für Umsetzung: Administrator
Die Windows PowerShell (WPS) ist eine .NET-basierte Skriptumgebung für die interaktive Systemadministration. 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.
Absicherung auf Dateiebene
Nur Administratoren sollten die Programmdateien C:\Windows\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 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. 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 Vista-, Windows 7 und Windows Server 2008-Systemen). 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.
- 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
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. Windows Vista sowie Windows 7-Systeme 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 Windows XP, Vista und Windows 7 Gruppenrichtlinien), 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 eingeschränkt worden?