Tags: PowerShell, Sicherheit, Zertifikate
Die Ausführung von PowerShell-Scripts lässt sich über Richtlinien einschränken, standardmäßig wird sie blockiert. Während die vom Admin interaktiv gesetzte Execution Policy von jedem User aufgehoben werden kann, ist die Konfiguration per GPO nachhaltiger. Sicherheit gegen böswillige User bietet sie aber trotzdem nicht.
Der wesentliche Zweck der Execution Policy besteht darin, Benutzer vor dem versehentlichen Ausführen nicht vertrauenswürdiger Scripts zu schützen. Die Voreinstellung auf einem frisch installierten Windows lautet auf Restricted, so dass kein Anwender PowerShell-Scripts starten kann, auch kein Administrator.
Einstellungen für die Execution Policy
Weitere mögliche Werte sind:
- AllSigned: Nur signierte Scripts werden ausgeführt, das gilt auch für lokal erstellte.
- RemoteSigned: Aus dem Internet heruntergeladene Scripts müssen signiert sein.
- Unrestricted: Alle Scripts werden ausgeführt. Bei nicht signierten Scripts aus dem Internet muss man jede Ausführung am Prompt bestätigen.
- Bypass: Keinerlei Einschränkungen, Warnungen oder Prompts.
- Undefined: Entfernt eine zugewiesene Richtlinie
Scope implizit auf LocalMachine
Möchte man das voreingestellte Restricted zum Beispiel auf RemoteSigned ändern und gibt dafür den Befehl
Set-ExecutionPolicy RemoteSigned
ein, dann scheitert dieser, wenn man die PowerShell-Sitzung nicht mit administrativen Rechten geöffnet hat.
Der Grund dafür liegt im Gültigkeitsbereich für die Execution Policy. Gibt man den Scope nicht explizit an, dann geht Set-ExecutionPolicy von LocalMachine aus. Das würde die Einstellung für alle Benutzer auf diesem Rechner ändern, weswegen man dafür Admin-Rechte benötigt.
PC-weite Einstellung für User überschreiben
Wie von der Programmierung bekannt, überschreibt auch hier ein spezifischer Gültigkeitsbereich einen allgemeineren. Definiert man die ExecutionPolicy für den aktuellen Benutzer, dann überschreibt sie jene für die lokale Maschine. Daher kann jeder User eine restriktive, rechnerweite Einstellung so aufheben:
Set-ExecutionPolicy RemoteSigned -Scope CurrentUser
Noch enger gefasst ist der Gültigkeitsbereich Process, der die aktuelle Sitzung betrifft. Die Einstellung dafür wird nicht wie sonst in der Registry, sondern in der Umgebungsvariable $env:PSExecutionPolicyPreference gespeichert. Sie geht nach Ende der Session verloren.
Richtlinien für alle Scopes anzeigen
Die Konfiguration der Execution Policy für jeden Gültigkeitsbereich kann man mit
Get-ExecutionPolicy -List | ft -AutoSize
anzeigen.
Neben den oben beschriebenen Scopes LocalMachine, CurrentUser und Process erscheinen in der Ausgabe des Cmdlets noch zwei weitere, nämlich MachinePolicy und UserPolicy. Die Werte dafür lassen sich nur über Gruppenrichtlinien setzen.
Execution Policy über GPO festlegen
Die dafür zuständige Einstellung findet sich für die Computer- und Benutzerkonfiguration unter Richtlinien => Administrative Vorlagen => Windows-Komponenten => Windows PowerShell und heißt Skriptausführung aktivieren.
Die damit konfigurierte Ausführungsrichtlinie übersteuert die interaktiv festgelegten Werte und verhindert auch, dass ein Administrator sie interaktiv ändern kann. Auch eine Umgehung durch Aufruf einer neuen Shell mit
powershell.exe -ExecutionPolicy "Unrestricted"
klappt dann nicht mehr, wogegen man mit dieser Technik eine Policy für LocalMachine aushebeln kann. Außerdem ist ein Zurücksetzen auf den Wert Undefined nur durch Deaktivieren des GPO möglich.
Über eine Gruppenrichtlinie kann man somit verbindlich vorgeben, welche Kriterien Scripts erfüllen müssen, um ablaufen zu dürfen (auf Logon-Scripts wirkt sich diese Policy übrigens nicht aus). Damit verhindert man, dass nicht vertrauenswürdige Scripts durch zu laxe Einstellungen unversehens Schaden anrichten.
Kein Schutz gegen böswillige User
Wenn ein Anwender entschlossen ist, diese Richtlinie zu umgehen, dann kopiert er den Inhalt eines Scripts einfach in die ISE und startet es dort. Aus dem Internet heruntergeladene, nicht signierte Scripts lassen sich trotz RemoteSigned starten, indem man die Datei mit Unblock-File freischaltet.
Ein weiterer Bypass besteht darin, das Script in Base64 zu kodieren und über den Parameter EncodedCommand an PowerShell.exe zu übergeben. Um mögliche Schäden durch solche Aktivitäten zu begrenzen, empfiehlt sich der Einsatz des Constrained Language Mode.
Täglich Know-how für IT-Pros mit unserem Newsletter
Verwandte Beiträge
- PowerShell-Scripts signieren mit Zertifikaten einer AD-Zertifizierungsstelle
- RDP-Dateien mit einem Zertifikat signieren
- Security- und Health-Checks für Active Directory mit PowerShell-Scripts
- AD-Zertifikatsdienste (AD CS) von SHA-1 auf SHA-2 migrieren: Gründe und Hindernisse
- Lets Encrypt-Zertifikat mit ACME2-Client ausstellen, installieren, automatisch erneuern
Weitere Links