So konfigurieren Sie Windows für das Arbeiten mit PowerShell-Skripts - Blog 2023
Windows und PowerShell verfügen über integrierte Sicherheitsfunktionen und Standardkonfigurationen, die verhindern sollen, dass Endbenutzer versehentlich Skripts während ihrer täglichen Aktivitäten starten. Wenn Ihre täglichen Aktivitäten jedoch routinemäßig das Schreiben und Ausführen eigener PowerShell-Skripts umfassen, kann dies eher ein Ärgernis als ein Vorteil sein. Hier zeigen wir Ihnen, wie Sie diese Funktionen umgehen können, ohne die Sicherheit zu beeinträchtigen.
Wie und warum Windows und PowerShell die Skriptausführung verhindern.
PowerShell ist effektiv die Befehlsshell und Skriptsprache, die CMD- und Batch-Skripts auf Windows-Systemen ersetzen soll. Daher kann ein PowerShell-Skript so konfiguriert werden, dass es alle Aufgaben ausführt, die Sie manuell über die Befehlszeile ausführen können. Dies bedeutet, dass Sie praktisch alle Änderungen an Ihrem System vornehmen können, bis zu den Einschränkungen für Ihr Benutzerkonto. Wenn Sie also einfach auf ein PowerShell-Skript doppelklicken und es mit vollständigen Administratorrechten ausführen können, könnte ein einfacher Einzeiler wie dieser Ihren Tag ruinieren:
Das geht einfach durch das Dateisystem und löscht, was es kann. Interessanterweise wird das System dadurch möglicherweise nicht so schnell funktionsunfähig, wie Sie vielleicht denken - selbst wenn Sie von einer Sitzung mit erhöhter Kapazität ausgehen. Wenn Sie jedoch nach dem Ausführen dieses Skripts von jemandem angerufen wird, weil er seine Dateien plötzlich nicht finden oder Programme ausführen kann, führt das "Ausschalten und Wiedereinschalten" wahrscheinlich dazu, dass Windows-Startreparatur ausgeführt wird nichts, was getan werden kann, um das Problem zu beheben. Schlimmer noch: Statt ein Skript zu erhalten, das nur das Dateisystem in den Papierkorb bringt, könnte Ihr Freund dazu verleitet werden, eines auszuführen, das einen Keylogger oder einen Fernzugriffsdienst herunterlädt und installiert. Anstatt Ihnen Fragen zu "Startup Repair" zu stellen, stellen sie möglicherweise der Polizei einige Fragen zu Bankbetrug!
Inzwischen sollte klar sein, warum bestimmte Dinge erforderlich sind, um die Endbenutzer sozusagen vor sich selbst zu schützen. Power User, Systemadministratoren und andere Freaks sind jedoch im Allgemeinen (obwohl es Ausnahmen gibt) etwas vorsichtiger gegenüber diesen Bedrohungen. Sie wissen, wie man sie erkennt und leicht vermeidet, und wollen einfach nur ihre Arbeit erledigen. Dazu müssen sie einige Straßensperren deaktivieren oder umgehen:
PowerShell lässt standardmäßig keine externe Skriptausführung zu. Die Einstellung ExecutionPolicy in PowerShell verhindert standardmäßig die Ausführung externer Skripts in allen Windows-Versionen. In einigen Windows-Versionen lässt die Standardeinstellung keine Skriptausführung zu. Wir haben Ihnen gezeigt, wie Sie diese Einstellung in So ändern Sie die Ausführung von PowerShell-Skripts unter Windows 7 ändern können, aber wir werden es hier auch auf ein paar Ebenen behandeln.
PowerShell ist standardmäßig nicht der.PS1-Dateierweiterung zugeordnet. Wir haben dies anfangs in unserer PowerShell Geek School-Serie angesprochen. Windows legt die Standardaktion für.PS1-Dateien fest, um sie in Notepad zu öffnen, anstatt sie an den PowerShell-Befehlsinterpreter zu senden. Dies dient dazu, die versehentliche Ausführung böswilliger Skripts direkt zu verhindern, wenn sie einfach doppelt angeklickt werden.
Einige PowerShell-Skripts funktionieren nicht ohne Administratorberechtigungen. Selbst wenn Sie mit einem Konto auf Administratorebene arbeiten, müssen Sie immer noch die Benutzerkontensteuerung (UAC) verwenden, um bestimmte Aktionen auszuführen. Für Befehlszeilentools kann dies, um es gelinde auszudrücken, etwas umständlich sein. Wir möchten die Benutzerkontensteuerung nicht deaktivieren, aber es ist immer noch schön, wenn wir es einfacher machen können, damit umzugehen.
Dieselben Probleme werden in So verwenden Sie eine Batch-Datei zur Vereinfachung der Ausführung von PowerShell-Skripts beschrieben. Hier werden Sie durch das Schreiben einer Batch-Datei geführt, um sie vorübergehend zu umgehen. Jetzt zeigen wir Ihnen, wie Sie Ihr System mit einer langfristigeren Lösung einrichten. Beachten Sie, dass Sie diese Änderungen grundsätzlich nicht an Systemen vornehmen sollten, die nicht ausschließlich von Ihnen verwendet werden. Andernfalls setzen Sie andere Benutzer einem höheren Risiko aus, die gleichen Probleme zu haben, die diese Funktionen verhindern sollen.
Ändern der.PS1-Dateizuordnung
Die erste und vor allem ärgerliche Art, um herumzukommen, ist die Standardzuordnung für.PS1-Dateien. Das Zuordnen dieser Dateien zu einem anderen Element als PowerShell.exe ist sinnvoll, um die versehentliche Ausführung unerwünschter Skripts zu verhindern. Aber wenn man bedenkt, dass PowerShell über eine Integrated Scripting Environment (ISE) verfügt, die speziell für die Bearbeitung von PowerShell-Skripts entwickelt wurde, warum sollten wir.PS1-Dateien standardmäßig in Notepad öffnen? Auch wenn Sie nicht bereit sind, vollständig auf die Aktivierung der Doppelklickfunktion zu wechseln, möchten Sie wahrscheinlich diese Einstellungen anpassen.
Sie können die.PS1-Dateizuordnung mit dem Kontrollfeld "Standardprogramme" in ein beliebiges Programm ändern. Wenn Sie jedoch direkt in die Registrierung gehen, haben Sie ein wenig mehr Kontrolle darüber, wie die Dateien genau geöffnet werden. Auf diese Weise können Sie auch zusätzliche Optionen festlegen oder ändern, die im Kontextmenü für.PS1-Dateien verfügbar sind. Vergessen Sie nicht, eine Sicherungskopie der Registrierung zu erstellen, bevor Sie dies tun.
Die Registrierungseinstellungen, die steuern, wie PowerShell-Skripts geöffnet werden, werden an folgendem Speicherort gespeichert:
Um diese Einstellungen zu untersuchen, bevor wir sie ändern, sehen Sie sich diesen Schlüssel und seine Unterschlüssel mit Regedit an. Der Shell-Schlüssel sollte nur einen Wert haben ("Standard"), der auf "Öffnen" gesetzt ist. Dies ist ein Zeiger auf die Standardaktion für das Doppelklicken auf die Datei, die in den Unterschlüsseln angezeigt wird.
Erweitern Sie den Shell-Schlüssel, und Sie sehen drei Unterschlüssel. Jede dieser Aktionen stellt eine Aktion dar, die Sie ausführen können, die für PowerShell-Skripts spezifisch ist.
Sie können jeden Schlüssel erweitern, um die darin enthaltenen Werte zu untersuchen, sie entsprechen jedoch im Wesentlichen den folgenden Standardwerten:
0 - Mit PowerShell ausführen. „Mit PowerShell ausführen“ist eigentlich der Name einer Option, die sich bereits im Kontextmenü für PowerShell-Skripts befindet. Der Text wird einfach von einem anderen Ort abgerufen, anstatt den Tastennamen wie die anderen zu verwenden. Und es ist immer noch nicht die Standard-Doppelklickaktion.
Bearbeiten - In PowerShell ISE öffnen. Das macht viel mehr Sinn als Notepad, aber Sie müssen immer noch mit der rechten Maustaste auf die.PS1-Datei klicken, um dies standardmäßig zu tun.
Öffnen - Im Editor öffnen. Beachten Sie, dass dieser Schlüsselname auch die Zeichenfolge ist, die im Wert "(Standard)" des Shell-Schlüssels gespeichert ist. Das bedeutet, wenn Sie auf die Datei doppelklicken, wird sie geöffnet, und normalerweise wird Notepad verwendet.
Wenn Sie die bereits vorhandenen Befehlszeichenfolgen beibehalten möchten, können Sie einfach den Wert "(Standard)" im Shell-Schlüssel so ändern, dass er mit dem Namen des Schlüssels übereinstimmt, der mit dem Doppelklick übereinstimmt. Dies kann leicht in Regedit erledigt werden. Sie können auch die Lektionen nutzen, die Sie aus unserem Tutorial zur Erkundung der Registrierung bei PowerShell (plus einem kleinen PSDrive-Tweak) gelernt haben, um mit dem Erstellen eines wiederverwendbaren Skripts zu beginnen, das Ihre Systeme für Sie konfigurieren kann. Die folgenden Befehle müssen in einer erweiterten PowerShell-Sitzung ausgeführt werden, ähnlich wie CMD als Administrator ausgeführt wird.
Zunächst möchten Sie ein PSDrive für HKEY_CLASSES_ROOT konfigurieren, da dieses nicht standardmäßig eingerichtet ist. Der Befehl dafür lautet:
New-PSDrive HKCR Registry HKEY_CLASSES_ROOT
Jetzt können Sie Registrierungsschlüssel und -werte in HKEY_CLASSES_ROOT wie in den regulären HKCU- und HKLM-PSDrives navigieren und bearbeiten.
So konfigurieren Sie das Doppelklicken zum direkten Starten von PowerShell-Skripts:
Dies sind nur die Grundlagen zum Ändern der Standard-Doppelklickaktion. Im Folgenden wird näher darauf eingegangen, wie die Verarbeitung von PowerShell-Skripts beim Öffnen in PowerShell über den Explorer im nächsten Abschnitt erfolgt. Beachten Sie, dass das Scoping verhindert, dass PSDrives über Sitzungen hinweg bestehen bleiben. Daher möchten Sie wahrscheinlich die New-PSDrive-Zeile zu Beginn eines Konfigurationsskripts hinzufügen, das Sie zu diesem Zweck erstellen, oder es Ihrem PowerShell-Profil hinzufügen. Andernfalls müssen Sie dieses Bit manuell ausführen, bevor Sie versuchen, auf diese Weise Änderungen vorzunehmen.
Ändern der PowerShell ExecutionPolicy-Einstellung.
Die ExecutionPolicy von PowerShell ist eine weitere Schutzschicht gegen die Ausführung bösartiger Skripts. Hierfür gibt es mehrere Optionen, und es gibt verschiedene Möglichkeiten, es einzustellen. Die meisten Optionen sind am wenigsten sicher:
Eingeschränkt - Es dürfen keine Skripts ausgeführt werden. (Standardeinstellung für die meisten Systeme.) Dadurch wird sogar die Ausführung Ihres Profilskripts verhindert.
AllSigned - Alle Skripts müssen von einem vertrauenswürdigen Herausgeber digital signiert werden, damit sie ohne Aufforderung des Benutzers ausgeführt werden können. Skripts, die von Herausgebern signiert wurden, die ausdrücklich als nicht vertrauenswürdig definiert sind, oder Skripts, die überhaupt nicht digital signiert sind, werden nicht ausgeführt. PowerShell fordert den Benutzer zur Bestätigung auf, wenn ein Skript von einem Herausgeber signiert ist, der noch nicht als vertrauenswürdig oder nicht vertrauenswürdig definiert ist. Wenn Sie Ihr Profilskript nicht digital signiert haben und Vertrauen in diese Signatur hergestellt haben, kann es nicht ausgeführt werden. Seien Sie vorsichtig, welchen Herausgebern Sie vertrauen, da Sie trotzdem bösartige Skripts ausführen können, wenn Sie dem falschen vertrauen.
RemoteSigned - Für aus dem Internet heruntergeladene Skripts entspricht dies praktisch "AllSigned". Skripts, die lokal erstellt oder aus anderen Quellen als dem Internet importiert wurden, können jedoch ohne Sicherheitsabfrage ausgeführt werden. Hier müssen Sie auch auf die digitalen Signaturen achten, denen Sie vertrauen, aber auch auf die nicht signierten Skripts achten, die Sie ausführen möchten. Dies ist die höchste Sicherheitsstufe, unter der Sie ein Arbeitsprofilskript erstellen können, ohne es digital signieren zu müssen.
Uneingeschränkt - Alle Skripts können ausgeführt werden, für Skripts aus dem Internet ist jedoch eine Bestätigungsaufforderung erforderlich. Von diesem Punkt an liegt es ganz an Ihnen, nicht vertrauenswürdige Skripts auszuführen.
Bypass - Alles läuft ohne Warnung. Seien Sie vorsichtig mit diesem.
Nicht definiert - Im aktuellen Bereich ist keine Richtlinie definiert. Dies wird verwendet, um einen Rückfall auf Richtlinien zu ermöglichen, die in niedrigeren Bereichen definiert sind (weitere Details unten) oder auf die Standardeinstellungen des Betriebssystems.
Wie in der Beschreibung von Undefined vorgeschlagen, können die obigen Richtlinien in einem oder mehreren von mehreren Bereichen festgelegt werden. Sie können Get-ExecutionPolicy mit dem Parameter -List verwenden, um alle Bereiche und ihre aktuelle Konfiguration anzuzeigen.
Die Bereiche werden in der Rangfolge aufgeführt, wobei der oberste definierte Bereich alle anderen überschreibt. Wenn keine Richtlinien definiert sind, wird das System auf seine Standardeinstellung zurückgesetzt (in den meisten Fällen ist dies "Eingeschränkt").
MachinePolicy repräsentiert eine auf Computerebene gültige Gruppenrichtlinie. Dies wird im Allgemeinen nur in einer Domäne angewendet, kann aber auch lokal erfolgen.
UserPolicy stellt eine für den Benutzer geltende Gruppenrichtlinie dar. Dies wird normalerweise auch nur in Unternehmensumgebungen verwendet.
Der Prozess ist ein für diese Instanz von PowerShell spezifischer Bereich. Änderungen an der Richtlinie in diesem Bereich wirken sich nicht auf andere ausgeführte PowerShell-Prozesse aus und sind nach dem Beenden dieser Sitzung unwirksam. Dies kann durch den Parameter -ExecutionPolicy konfiguriert werden, wenn PowerShell gestartet wird, oder es kann innerhalb der Sitzung mit der entsprechenden Set-ExecutionPolicy-Syntax festgelegt werden.
CurrentUser ist ein Bereich, der in der lokalen Registrierung konfiguriert ist und für das Benutzerkonto gilt, das zum Starten von PowerShell verwendet wird. Dieser Bereich kann mit Set-ExecutionPolicy geändert werden.
LocalMachine ist ein in der lokalen Registrierung konfigurierter Bereich, der für alle Benutzer des Systems gilt. Dies ist der Standardbereich, der geändert wird, wenn Set-ExecutionPolicy ohne den Parameter -Scope ausgeführt wird. Da es für alle Benutzer des Systems gilt, kann es nur von einer erhöhten Sitzung aus geändert werden.
Da es in diesem Artikel hauptsächlich darum geht, die Sicherheit zu verbessern, um die Benutzerfreundlichkeit zu erleichtern, sind wir nur über die unteren drei Bereiche besorgt. Die Einstellungen für MachinePolicy und UserPolicy sind nur dann wirklich nützlich, wenn Sie eine restriktive Richtlinie durchsetzen möchten, die nicht einfach umgangen wird. Indem wir unsere Änderungen auf der Prozessebene oder darunter beibehalten, können wir jederzeit die von uns für die jeweilige Situation angemessenen Richtlinieneinstellungen verwenden.
Um ein gewisses Gleichgewicht zwischen Sicherheit und Benutzerfreundlichkeit zu erhalten, ist die in der Abbildung dargestellte Richtlinie wahrscheinlich die beste. Wenn Sie die LocalMachine-Richtlinie auf "Restricted" setzen, wird im Allgemeinen verhindert, dass Skripts von anderen Personen als Ihnen ausgeführt werden. Natürlich kann dies von Benutzern umgangen werden, die ohne großen Aufwand wissen, was sie tun. Es sollte jedoch verhindern, dass Nicht-Tech-versierte Benutzer in PowerShell versehentlich eine Katastrophe auslösen. Wenn Sie den CurrentUser (d. H.: Sie) als "Nicht eingeschränkt" festlegen, können Sie Skripts manuell über die Befehlszeile ausführen, wie Sie möchten, aber er erinnert an Vorsicht, wenn Skripts aus dem Internet heruntergeladen werden. Die RemoteSigned-Einstellung auf der Prozessebene muss in einer Verknüpfung zu PowerShell.exe oder (wie unten beschrieben) in den Registrierungswerten erfolgen, die das Verhalten von PowerShell-Skripts steuern. Dies ermöglicht eine einfache Doppelklick-Funktion für alle Skripts, die Sie schreiben, und bietet eine stärkere Barriere gegen die unbeabsichtigte Ausführung von (potenziell böswilligen) Skripts aus externen Quellen. Wir möchten dies hier tun, da es viel einfacher ist, versehentlich auf ein Skript zu doppelklicken, als es normalerweise von einer interaktiven Sitzung aus manuell aufgerufen wird.
Führen Sie die folgenden Befehle aus einer erweiterten PowerShell-Sitzung aus, um die CurrentUser- und LocalMachine-Richtlinien wie im obigen Screenshot festzulegen:
Um die RemoteSigned-Richtlinie für Skripts zu erzwingen, die vom Explorer ausgeführt werden, müssen Sie einen Wert in einem der zuvor angezeigten Registrierungsschlüssel ändern. Dies ist besonders wichtig, da die Standardkonfiguration je nach PowerShell- oder Windows-Version möglicherweise darin besteht, alle ExecutionPolicy-Einstellungen außer AllSigned zu umgehen. Um die aktuelle Konfiguration für Ihren Computer anzuzeigen, können Sie diesen Befehl ausführen (wobei sicherzustellen ist, dass zuerst das HKCR-PSD-Laufwerk zugeordnet ist):
Die erste ist nicht so schlimm, da sie das Skript lediglich unter den vorhandenen ExecutionPolicy-Einstellungen ausführt. Es könnte verbessert werden, indem strengere Einschränkungen für eine unfallanfälligere Aktion erzwungen werden. Ursprünglich sollte dies jedoch nicht durch einen Doppelklick ausgelöst werden, und die Standardrichtlinie ist in der Regel immer eingeschränkt. Die zweite Option ist jedoch eine vollständige Umgehung aller Ausführungspfeile, die Sie wahrscheinlich installiert haben - sogar eingeschränkt. Da der Bypass im Prozessbereich angewendet wird, wirkt er sich nur auf die Sitzungen aus, die gestartet werden, wenn Skripts vom Explorer aus ausgeführt werden. Dies bedeutet jedoch, dass Sie am Ende Skripts starten können, die Sie andernfalls erwarten (und möchten), dass Ihre Richtlinie verbietet.
Um die ExecutionPolicy auf Prozessebene für vom Explorer gestartete Skripts entsprechend dem obigen Screenshot festzulegen, müssen Sie denselben Registrierungswert ändern, den Sie gerade abgefragt haben. Sie können es manuell in Regedit tun, indem Sie es wie folgt ändern:
Sie können die Einstellung auch in PowerShell ändern, wenn Sie möchten. Denken Sie daran, dies von einer erhöhten Sitzung aus zu tun, wobei das HKCR PSDrive zugeordnet ist.
Führen Sie PowerShell-Skripts als Administrator aus.
Eine UAC-Deaktivierung der Benutzerkontensteuerung ist in jedem Fall eine schlechte Idee. Es ist auch eine schlechte Sicherheitspraxis, Skripts oder Programme mit erhöhten Berechtigungen auszuführen, sofern sie nicht tatsächlich für Vorgänge erforderlich sind, für die Administratorzugriff erforderlich ist. Daher wird die Eingabe der UAC-Eingabeaufforderung in die Standardaktion für PowerShell-Skripts nicht empfohlen. Wir können jedoch eine neue Kontextmenüoption hinzufügen, mit der wir Skripts bei Bedarf problemlos in erweiterten Sitzungen ausführen können. Diese Methode ähnelt der Methode, die zum Hinzufügen von „Mit Editor öffnen“zum Kontextmenü aller Dateien verwendet wird. Hier werden jedoch nur PowerShell-Skripts als Ziel angegeben. Wir werden auch einige Techniken, die im vorigen Artikel verwendet wurden, übernehmen, bei denen wir eine Batchdatei anstelle von Registrierungshacks zum Starten unseres PowerShell-Skripts verwendeten.
Um dies in Regedit zu tun, gehen Sie zurück in den Shell-Schlüssel unter:
Dort erstellen Sie einen neuen Unterschlüssel. Nennen Sie es "Mit PowerShell (Admin) ausführen". Erstellen Sie darunter einen weiteren Unterschlüssel namens "Befehl".Legen Sie dann unter "Befehl" den Wert "(Standard)" fest:
Wenn Sie dasselbe in PowerShell tun, werden diesmal tatsächlich drei Zeilen benötigt. Eine für jede neue Taste und eine, um den Wert ((Standard) für Command festzulegen. Vergessen Sie nicht die Höhe und die HKCR-Zuordnung.
New-Item 'HKCR:Microsoft.PowerShellScript.1ShellRun with PowerShell (Admin)' New-Item 'HKCR:Microsoft.PowerShellScript.1ShellRun with PowerShell (Admin)Command' Set-ItemProperty 'HKCR:Microsoft.PowerShellScript.1ShellRun with PowerShell (Admin)Command' '(Default)' ''C:WindowsSystem32WindowsPowerShellv1.0powershell.exe' '-Command' ''& {Start-Process PowerShell.exe -ArgumentList ''-ExecutionPolicy RemoteSigned -File '%1''' -Verb RunAs}''
Achten Sie auch sorgfältig auf die Unterschiede zwischen der über PowerShell eingegebenen Zeichenfolge und dem tatsächlichen Wert, der in die Registrierung eingeht. Insbesondere müssen wir das Ganze in einfache Anführungszeichen packen und die internen einfachen Anführungszeichen verdoppeln, um Fehler bei der Befehlsparsung zu vermeiden.
Jetzt sollten Sie einen neuen Kontextmenüeintrag für PowerShell-Skripts mit der Bezeichnung "Mit PowerShell (Admin) ausführen" erstellen.
Mit der neuen Option werden zwei aufeinander folgende PowerShell-Instanzen erzeugt. Der erste ist nur ein Starter für den zweiten, der Start-Process mit dem Parameter "-Verb RunAs" verwendet, um die Erhöhung für die neue Sitzung anzufordern. Von dort sollte Ihr Skript mit Administratorrechten ausgeführt werden können, nachdem Sie auf die UAC-Eingabeaufforderung geklickt haben.
Feinschliff.
Es gibt nur ein paar Verbesserungen, die das Leben noch ein bisschen einfacher machen können. Wie wäre es, wenn Sie die Notepad-Funktion vollständig loswerden würden? Kopieren Sie einfach den Wert "(Standard)" von der Befehlstaste unter Bearbeiten (unten) an dieselbe Stelle unter Öffnen.
Ein weiterer kleiner Ärger ist die Gewohnheit der Konsole, nach dem Abschluss eines Skripts zu verschwinden. In diesem Fall haben wir keine Möglichkeit, die Skriptausgabe auf Fehler oder andere nützliche Informationen zu überprüfen. Dies kann durch eine Pause am Ende jedes Skripts natürlich behoben werden. Alternativ können wir die Werte für ("Standard") für unsere Befehlstasten so ändern, dass sie den Parameter "-NoExit" enthalten. Nachfolgend sind die geänderten Werte aufgeführt.
Um dies zu testen, verwenden wir ein Skript, das uns zeigt, welche Einstellungen für ExecutionPolicy vorhanden sind und ob das Skript mit Administratorberechtigungen gestartet wurde oder nicht. Das Skript heißt "MyScript.ps1" und wird in unserem Beispielsystem unter "D: Script Lab" gespeichert. Der Code ist unten als Referenz.
Verwenden der Aktion "Mit PowerShell (Admin) ausführen" nach dem Klicken durch die Benutzerkontensteuerung:Um die ExecutionPolicy im Prozessbereich in Aktion zu demonstrieren, können wir Windows mit diesem PowerShell-Code denken lassen, dass die Datei aus dem Internet stammt:
