Разрешить выполнение скриптов powershell windows server 2008 r2

Most of the existing answers explain the How, but very few explain the Why. And before you go around executing code from strangers on the Internet, especially code that disables security measures, you should understand exactly what you’re doing. So here’s a little more detail on this problem.

From the TechNet About Execution Policies Page:

Windows PowerShell execution policies let you determine the conditions under which Windows PowerShell loads configuration files and runs scripts.

The benefits of which, as enumerated by PowerShell Basics — Execution Policy and Code Signing, are:

• Control of Execution — Control the level of trust for executing scripts.
• Command Highjack — Prevent injection of commands in my path.
• Identity — Is the script created and signed by a developer I trust and/or a signed with a certificate from a Certificate Authority I trust.
• Integrity — Scripts cannot be modified by malware or malicious user.

To check your current execution policy, you can run Get-ExecutionPolicy. But you’re probably here because you want to change it.

To do so you’ll run the Set-ExecutionPolicy cmdlet.

You’ll have two major decisions to make when updating the execution policy.

Execution Policy Type:

• Restricted^† — No Script either local, remote or downloaded can be executed on the system.
• AllSigned — All script that are ran require to be digitally signed.
• RemoteSigned — All remote scripts (UNC) or downloaded need to be signed.
• Unrestricted — No signature for any type of script is required.

Scope of new Change

• LocalMachine^† — The execution policy affects all users of the computer.
• CurrentUser — The execution policy affects only the current user.
• Process — The execution policy affects only the current Windows PowerShell process.

^{† = Default}

For example: if you wanted to change the policy to RemoteSigned for just the CurrentUser, you’d run the following command:

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser

Note: In order to change the Execution policy, you must be running PowerShell As Administrator.
If you are in regular mode and try to change the execution policy, you’ll get the following error:

Access to the registry key ‘HKEY_LOCAL_MACHINESOFTWAREMicrosoftPowerShell1ShellIdsMicrosoft.PowerShell’ is denied. To change the execution policy for the default (LocalMachine) scope, start Windows PowerShell with the «Run as administrator» option.

If you want to tighten up the internal restrictions on your own scripts that have not been downloaded from the Internet (or at least don’t contain the UNC metadata), you can force the policy to only run signed scripts. To sign your own scripts, you can follow the instructions on Scott Hanselman’s article on Signing PowerShell Scripts.

Note: Most people are likely to get this error whenever they open PowerShell because the first thing PowerShell tries to do when it launches is execute your user profile script that sets up your environment however you like it.

The file is typically located in:

%UserProfile%My DocumentsWindowsPowerShellMicrosoft.PowerShellISE_profile.ps1

You can find the exact location by running the PowerShell variable

$profile

If there’s nothing that you care about in the profile, and don’t want to fuss with your security settings, you can just delete it and PowerShell won’t find anything that it cannot execute.

Most of the existing answers explain the How, but very few explain the Why. And before you go around executing code from strangers on the Internet, especially code that disables security measures, you should understand exactly what you’re doing. So here’s a little more detail on this problem.

From the TechNet About Execution Policies Page:

Windows PowerShell execution policies let you determine the conditions under which Windows PowerShell loads configuration files and runs scripts.

The benefits of which, as enumerated by PowerShell Basics — Execution Policy and Code Signing, are:

• Control of Execution — Control the level of trust for executing scripts.
• Command Highjack — Prevent injection of commands in my path.
• Identity — Is the script created and signed by a developer I trust and/or a signed with a certificate from a Certificate Authority I trust.
• Integrity — Scripts cannot be modified by malware or malicious user.

To check your current execution policy, you can run Get-ExecutionPolicy. But you’re probably here because you want to change it.

To do so you’ll run the Set-ExecutionPolicy cmdlet.

You’ll have two major decisions to make when updating the execution policy.

Execution Policy Type:

• Restricted^† — No Script either local, remote or downloaded can be executed on the system.
• AllSigned — All script that are ran require to be digitally signed.
• RemoteSigned — All remote scripts (UNC) or downloaded need to be signed.
• Unrestricted — No signature for any type of script is required.

Scope of new Change

• LocalMachine^† — The execution policy affects all users of the computer.
• CurrentUser — The execution policy affects only the current user.
• Process — The execution policy affects only the current Windows PowerShell process.

^{† = Default}

For example: if you wanted to change the policy to RemoteSigned for just the CurrentUser, you’d run the following command:

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser

Note: In order to change the Execution policy, you must be running PowerShell As Administrator.
If you are in regular mode and try to change the execution policy, you’ll get the following error:

Access to the registry key ‘HKEY_LOCAL_MACHINESOFTWAREMicrosoftPowerShell1ShellIdsMicrosoft.PowerShell’ is denied. To change the execution policy for the default (LocalMachine) scope, start Windows PowerShell with the «Run as administrator» option.

If you want to tighten up the internal restrictions on your own scripts that have not been downloaded from the Internet (or at least don’t contain the UNC metadata), you can force the policy to only run signed scripts. To sign your own scripts, you can follow the instructions on Scott Hanselman’s article on Signing PowerShell Scripts.

Note: Most people are likely to get this error whenever they open PowerShell because the first thing PowerShell tries to do when it launches is execute your user profile script that sets up your environment however you like it.

The file is typically located in:

%UserProfile%My DocumentsWindowsPowerShellMicrosoft.PowerShellISE_profile.ps1

You can find the exact location by running the PowerShell variable

$profile

If there’s nothing that you care about in the profile, and don’t want to fuss with your security settings, you can just delete it and PowerShell won’t find anything that it cannot execute.

По-умолчанию настройки Windows запрещают запуск скриптов PowerShell. Это необходимо для предотвращения запуска вредоносного кода на PowerShell. Настройки политик запуска PowerShell скриптов определяются в Execution Policy. В этой статье мы рассмотрим доступные политики запуска PS скриптов, как изменить Execution Policy и настроить политики использования PowerShell скриптов на компьютерах в домене.

Выполнение PowerShell скриптов запрещено для данной системы

При попытке выполнить PowerShell скрипт (файл с расширением PS1) на чистой Windows 10, появляется ошибка:

File C:ps.ps1 cannot be loaded because running scripts is disabled on this system. For more information, see about_Execution_Policies at https:/go.microsoft.com/fwlink/?LinkID=135170.
+ CategoryInfo : SecurityError: (:) [], PSSecurityException
+ FullyQualifiedErrorId : UnauthorizedAccess

Не удается загрузить файл.ps1, так как выполнение скриптов запрещено для данной системы.

Текущее значение политики выполнения скриптов PowerShell на компьютере можно получить командой:

Get-ExecutionPolicy

Доступны следующие значения PowerShell Execution Policy:

• Restricted – запрещен запуск скриптов PowerShell, можно выполнять только интерактивные команды в консоли;
• AllSigned – разрешено выполнять только подписанные PS скрипты с цифровой подписью от доверенного издателя (можно подписать скрипт самоподписанным сертификатом и добавить его в доверенные). При запуске недоверенных скриптов появляется предупреждение:

  Do you want to run software from this untrusted publisher? File .ps1 is published by CN=test1 and is not trusted on your system. Only run scripts from trusted publishers

  

• RemoteSigned – можно запускать локальные PowerShell скрипты без ограничения. Можно запускать удаленные PS файлы с цифровой подписью (нельзя запустить PS1 файлы, скачанные из Интернета, запущенные из сетевой папки по UNC пути и т.д.);
• Unrestricted – разрешен запуск всех PowerShell скриптов;

  При запуске сторонних PowerShell скриптов может появляется предупреждение с подтверждением запуска, см. ниже.

• Bypass – разрешён запуск любых PS файлов (предупреждения не выводятся) – эта политика обычно используется для автоматического запуска PS скриптов без вывода каких-либо уведомлений (например при запуске через GPO, SCCM, планировщик и т.д.) и не рекомендуется для постоянного использования;
• Default – сброс настроек выполнения скриптов на стандартную;

  В Windows 10 значение политики выполнения PowerShell по-умолчанию Restricted, а в Windows Server 2016 — RemoteSigned.

• Undefined – не задано. Применяется политика Restricted для десктопных ОС и RemoteSigned для серверных.

Как разрешить запуск скриптов PowerShell с помощью Execution Policy?

Чтобы изменить текущее значение политики запуска PowerShell скриптов, используется командлет Set-ExecutionPolicy.

Например, разрешим запуск локальных скриптов:

Set-ExecutionPolicy RemoteSigned

Подтвердите изменение политики запуска PS1 скриптов, нажав Y или A.

Чтобы запрос не появлялся, можно использовать параметр Force.

Set-ExecutionPolicy RemoteSigned –Force

Если вы установили значение политики PowerShell Execution Policy в Unrestricted, то при запуске удаленных скриптов из сетевых каталогов по UNC пути, скачанных из интернета файлов, все равно будет появляться предупреждение:

Security warning
Run only scripts that you trust. While scripts from the internet can be useful, this script can potentially harm your computer. If you trust this script, use the
Unblock-File cmdlet to allow the script to run without this warning message.
Do you want to run?
[D] Do not run [R] Run once [S] Suspend [?] Help (default is "D")

Как PowerShell различает локальные и удаленные скрипты? Все дело в идентификаторе зоны ZoneId, которую выставляет браузер в альтернативном потоке при загрузке файла (см. статью “Как Windows определяет, что файл скачан из Интернета?”). Вы можете разблокировать такой файл, поставив галку “Разблокирвать” в его свойствах или очиститься метку зоны с помощью комадлета Unblock-File.

Также следует различать различные области действия политик выполнения скриптов PowerShell (scopes):

• MachinePolicy – действует для всех пользователей компьютера, настраивается через GPO;
• UserPolicy – действует на пользователей компьютера, также настраивается через GPO;
• Process — настройки ExecutionPolicy действует только для текущего сеанса PowerShell.exe (сбрасываются при закрытии процесса);
• CurrentUser – политика ExecutionPolicy применяется только к текущему пользователю (параметр из ветки реестра HKEY_CURRENT_USER);
• LocalMachine – политика для всех пользователей компьютера (параметр из ветки реестра HKEY_LOCAL_MACHINE);

Область применения политики можно указать с помощью параметр Scope командлета Set-ExecutionPolicy. Например:

Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass –Force

Проверим текущие настройки ExecutionPolicy для всех областей:

Get-ExecutionPolicy -List

Scope ExecutionPolicy
----- ---------------
MachinePolicy Undefined
UserPolicy Undefined
Process Bypass
CurrentUser Undefined
LocalMachine RemoteSigned

Значение политики выполнения, которые вы задаете с помощью командлета Set-ExecutionPolicy для областей CurrentUser и LocalMachine, хранятся в реестре. Например, выполните командлет:

Set-ExecutionPolicy -Scope LocalMachine -ExecutionPolicy Restricted –Force

Откройте ветку реестра HKEY_LOCAL_MACHINESOFTWAREMicrosoftPowerShell1ShellIdsMicrosoft.PowerShell и проверьте значение REG_SZ параметра ExecutionPolicy. Оно изменилось на Restricted (допустимые значения параметра Restricted, AllSigned, RemoteSigned, Bypass, Unrestricted и Undefined).

Аналогичные настройки для области CurrentUser находятся в разделе реестра пользователя HKEY_CURRENT_USERSOFTWAREMicrosoftPowerShell1ShellIdsMicrosoft.PowerShell.

Отметим, что чаще всего в корпоративной среде используется ExecutionPolicy со значением AllSigned на уровне LocalMachine. Это обеспечивает максимальный баланс между безопасностью и удобством. Для личного пользования на компьютере можно использовать RemoteSigned. Ну а Bypass политику лучше использовать только для запуска отдельных задач (например для запуска скриптов через GPO или заданий планировщика).

Настройка PowerShell Execution Policy с помощью групповых политик

Вы можете настроить политику выполнения PowerShel скриптов на серверах или компьютерах домена с помощью групповых политик.

1. С помощью редактора доменных GPO (gpmc.msc) создайте новую GPO (или отредактируйте) существующую и назначьте ее на OU с компьютерами, к которым нужно применить политику запуска PowerShell скриптов;
2. В редакторе политики перейдите в раздел Computer Configuration -> Policies -> Administrative Templates -> Windows Components -> Windows PowerShell и найдите политику Turn on Script Execution (Включить выполнение сценариев);

   Аналогичная политика есть в пользовательском разделе GPO — User Configuration, но политика компьютера имеет приоритет.

3. Для политики доступны три значения:
   • Allow only signed scripts (Разрешать только подписанные сценарии) — соответствует политике AllSigned;
   • Allow local scripts and remote signed scripts (Разрешать локальные и удаленные подписанные сценарии) — соответствует политике PS RemoteSigned;
   • Allow all scripts (Разрешать все сценарии) — политика Unrestricted.
4. Выберите необходимое значение политики, сохраните GPO и обновите политики на компьютере.
5. Проверьте, что для области MachinePolicy теперь действуют новые настройки выполнения.

После настройки политики выполнения через GPO вы не сможете изменить настройки политики выполнения скриптов вручную. При попытке изменить настройки Execution Policy на компьютере, на который применяется такая GPO, появится ошибка:

Set-ExecutionPolicy : Windows PowerShell updated your execution policy successfully, but the setting is overridden by a policy defined at a more specific scope. Due to the override, your shell will retain its current effective execution policy of RemoteSigned. Type "Get-ExecutionPolicy -List" to view your execution policy settings.

Способы обхода политики PowerShell Execution

Есть несколько трюков, которые могут помочь вам, когда нужно запустить на компьютере PowerShell скрипт, не изменяя настройки политики выполнения. Например, я хочу запустить простой PS1 скрипт, который поверяет, что запущен с правами администратора.

Можно с помощью Get-Content получить содержимое скрипта и перенаправить его в стандартныq поток ввода консоли PS.

Get-Content c:pscheck_process_elevation.ps1 | PowerShell.exe -noprofile –

Либо можно запустить новый процесс powershell.exe с политикой выполнения Bypass:

powershell.exe -noprofile -executionpolicy bypass -file c:pscheck_process_elevation.ps1

Most of the existing answers explain the How, but very few explain the Why. And before you go around executing code from strangers on the Internet, especially code that disables security measures, you should understand exactly what you’re doing. So here’s a little more detail on this problem.

From the TechNet About Execution Policies Page:

Windows PowerShell execution policies let you determine the conditions under which Windows PowerShell loads configuration files and runs scripts.

The benefits of which, as enumerated by PowerShell Basics — Execution Policy and Code Signing, are:

• Control of Execution — Control the level of trust for executing scripts.
• Command Highjack — Prevent injection of commands in my path.
• Identity — Is the script created and signed by a developer I trust and/or a signed with a certificate from a Certificate Authority I trust.
• Integrity — Scripts cannot be modified by malware or malicious user.

To check your current execution policy, you can run Get-ExecutionPolicy. But you’re probably here because you want to change it.

To do so you’ll run the Set-ExecutionPolicy cmdlet.

You’ll have two major decisions to make when updating the execution policy.

Execution Policy Type:

• Restricted^† — No Script either local, remote or downloaded can be executed on the system.
• AllSigned — All script that are ran require to be digitally signed.
• RemoteSigned — All remote scripts (UNC) or downloaded need to be signed.
• Unrestricted — No signature for any type of script is required.

Scope of new Change

• LocalMachine^† — The execution policy affects all users of the computer.
• CurrentUser — The execution policy affects only the current user.
• Process — The execution policy affects only the current Windows PowerShell process.

^{† = Default}

For example: if you wanted to change the policy to RemoteSigned for just the CurrentUser, you’d run the following command:

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser

Note: In order to change the Execution policy, you must be running PowerShell As Administrator.
If you are in regular mode and try to change the execution policy, you’ll get the following error:

Access to the registry key ‘HKEY_LOCAL_MACHINESOFTWAREMicrosoftPowerShell1ShellIdsMicrosoft.PowerShell’ is denied. To change the execution policy for the default (LocalMachine) scope, start Windows PowerShell with the «Run as administrator» option.

If you want to tighten up the internal restrictions on your own scripts that have not been downloaded from the Internet (or at least don’t contain the UNC metadata), you can force the policy to only run signed scripts. To sign your own scripts, you can follow the instructions on Scott Hanselman’s article on Signing PowerShell Scripts.

Note: Most people are likely to get this error whenever they open PowerShell because the first thing PowerShell tries to do when it launches is execute your user profile script that sets up your environment however you like it.

The file is typically located in:

%UserProfile%My DocumentsWindowsPowerShellMicrosoft.PowerShellISE_profile.ps1

You can find the exact location by running the PowerShell variable

$profile

If there’s nothing that you care about in the profile, and don’t want to fuss with your security settings, you can just delete it and PowerShell won’t find anything that it cannot execute.

Обновлено 16.07.2021

Всем привет сегодня хочу рассказать как запустить скрипт PowerShell в Windows. Представьте ситуацию вы написали скрипт который сильно упрощает вам вывод информации по Active Directory, вы открываете оснастку powershell прописываете путь к своему скрипту нажимаете enter и получаете ошибку.

Не удается загрузить файл <путь к вашему файлу>, так как выполнение скриптов запрещено для данной системы. Введите «get-help about_signing» для получения дополнительных сведений.

Смотрим как ее решить.

Ошибки при запуске скрипта PowerShell

Так же вы можете увидеть ошибку после запуска установленного PowerCLI:

PowerShell обладает рядом режимов исполнения, которые определяют, какой тип кода разрешается выполнять. Все это управляется ключом реестра, живущим в HKLM. Существует 4 различных режима исполнения:

• Ограниченный (Restricted): Политика исполнения по умолчанию, не допускает работу скриптов и разрешает работу лишь интерактивных команд.
• Все подписанные (All Signed): Допускает работу всех скриптов. Правда, все скрипты и файлы конфигурации должны быть подписаны издателем, которому вы доверяете; данный режим подвергает вас риску работы подписанных (но вредоносных) скриптов, после получения подтверждения доверия издателю.
• Удаленные подписанные (Remote Signed): Локальные скрипты работают без подписи. Все скачанные скрипты должны иметь цифровую подпись.
• Неограниченный (Unrestricted): Все скрипты и файлы конфигурации, полученные из коммуникационных приложений, вроде Microsoft Outlook, Internet Explorer, Outlook Express и Windows Messenger работают после подтверждения, что вы понимаете, что файл исходит из Интернета; никакие цифровые подписи не требуются; данный режим подвергает вас риску работу неподписанных, вредоносных скриптов.

По умолчанию для PowerShell используется режим «Ограниченный». В этом режиме, PowerShell работает лишь как интерактивная оболочка. Он не допускает работу скриптов, и загружает лишь те файлы конфигурации, которые подписаны издателем, которому вы доверяете.

Разрешить выполнение скриптов powershell

Чтобы запускать созданные собою скрипты, необходимо разрешить выполнение ненадежных скриптов с помощью команды Set-ExecutionPolicy remotesigned и подтверждением (Внимание!!! для выполнения этой команды необходимо запустить PowerShell с правами администратора). После этого можно вновь запустить выполнения скрипта.

На вопрос жмем Y, для разрешения выполнения скриптов. После этих манипуляций вы сможете запустить ваш скрипт. То же самое я проделал и для PowerCLI, что в результате дало возможность теперь его запускать без проблем.

Как запустить скрипт PowerShell по расписанию

Очень часто на серверах появляется необходимость по запуску скрипта PowerShell по расписанию или по определенному событию, которое появляется в логах Windows, в таких ситуациях нам на помощь приходит планировщик заданий.

Я приведу пример, когда мне нужно было отслеживать события ID 20291 или ID 11707.  И так откройте окно выполнить и введите в нем:

Далее вы щелкаете по библиотеке правым кликом и из контекстного меню выбираете пункт «Создать задачу«.

Задаете имя задания, советую запускать скрипт PowerShell от имени учетной записи «СИСТЕМА (SYSTEM)«, это будет гарантировать, что задание точно отработает.

Поставьте галку «Выполнять с наивысшими правами»

Переходим на вкладку тригеры и создаем новый. В параметрах выберите «При событии«

Далее задаем:

• Журнал — Приложение
• Источник — MsiInstaller
• Код события — 11707

Тут тригер будет срабатывать, когда в логах появится событие 11707.

В действие оставляем «Запуск программы». В программе указываем powershell, а в параметрах задайте путь до самого скрипта, через параметр -File c:scriptsid11707.ps1.

В итоге у меня вышло вот так.

Как видим, мое задание по запуску скрипта PowerShell успешно создано и отработало в планировщике Windows.

Запуск скрипта PowerShell через исполняемый файл exe

Так же вы можете воспользоваться конвертированием скрипта PowerShell из формата ps1 в exe файл, после чего даже не потребуется менять политику запуска не подписанных скриптов. Так же exe скрипт можете запускать и через планировщик.

На этом у меня все, мы разобрали методы запуска скриптов PowerShell в Windows, с вами был Иван Семин. Материал сайта pyatilistnik.org

При разработке PowerShell особое внимание было уделено безопасности. Одной из мер безопасности является наличие политики выполнения (Execution Policy), которая определяет, могут ли скрипты PowerShell выполняться в системе, и если могут, то какие именно.

Для примера возьмем чистую Windows 10, откроем консоль PowerShell и попробуем выполнить простой скрипт. Попытка завершится ошибкой, поскольку, как видно из сообщения, выполнение скриптов в системе запрещено.

Это сработала политика выполнения, и если мы все же хотим выполнить скрипт, то ее необходимо изменить. Выбрать можно одно из следующих значений:

• Restricted — в системе запрещено выполнение любых скриптов, допускается только выполнение отдельных команд. Это политика по умолчанию для клиентских ОС Windows;
• AllSigned — разрешено выполнение только скриптов, имеющих цифровую подпись от доверенного издателя;
• RemoteSigned — для удаленных скриптов требуется наличие цифровой подписи, локальные скрипты выполняются без ограничений. Удаленными считаются скрипты, полученные из удаленных источников (загруженные из интернета, полученные по электронной почте и т.п.), локальными — скрипты, созданные на локальном компьютере. Это политика по умолчанию для серверных ОС Windows;
• Unrestricted — разрешено выполнение любых скриптов, как локальных так и удаленных. При выполнении удаленного скрипта без цифровой подписи будет выдано предупреждение. Это дефолтная и единственно возможная политика для всех ОС, отличных от Windows;
• Bypass — разрешено выполнение любых скриптов, никакие предупреждения и запросы не выводятся;
• Default — сбрасывает политику на значение по умолчанию. Для серверов это RemoteSigned, для клиентов Restricted;
• Undefined — не определено. В случае, если значение политики не определено, то применяется политика Restricted.

Теоретически все понятно, проверим на практике. Для просмотра параметров политики используется командлет Get-ExecutionPolicy, а для  изменения Set-ExecutionPolicy.

Для начала выведем действующую политику выполнения командой:

Get-ExecutionPolicy

Как и ожидалось, текущая политика Restricted. Разрешим выполнение скриптов, установив для политики значение Unrestricted:

Set-ExecutionPolicy Unrestricted -Force

И еще попробуем запустить скрипт. На сей раз он выполнился без ошибок.

Политика Unrestricted разрешает выполнение любых скриптов, но у нее все же есть ограничения. Для проверки я подготовил два скрипта, локальный localscript.ps1 и удаленный remotescript.ps1. Сначала запустим локальный, он выполнится без проблем. А вот при запуске удаленного скрипта PowerShell выдаст предупреждение и потребует подтвердить его запуск. При ручном выполнении это не является большой проблемой, а вот в случае автоматического запуска (напр. из планировщика) скрипт может не отработать.

Теперь изменим политику на Bypass и еще раз запустим удаленный скрипт. На сей раз он просто выполнился, безо всяких сообщений и подтверждений. Bypass удобно использовать в ситуациях, когда скрипт должен гарантированно отработать, причем автоматически, без вмешательства пользователя.

Следующим пунктом нашего меню идет политика RemoteSigned. Она является наиболее сбалансированной как с точки зрения безопасности, так и удобства использования, поэтому на серверах включена по умолчанию. Установим для политики значение RemoteSigned и проверим ее действие. Локальный скрипт снова выполняется без проблем, а удаленный выдает ошибку, поскольку у него нет подписи.

У вас может возникнуть вопрос, как именно PowerShell различает локальные и удаленные скрипты. Тут все просто. При загрузке файла приложение (напр. браузер) добавляет файл идентификатор зоны (ZoneId), который и определяет, откуда был взят файл. Идентификатор хранится в альтернативном потоке и имеет значение от 0 до 4:

• Локальный компьютер (0)
• Местная сеть (1)
• Надежные сайты (2)
• Интернет (3)
• Опасные сайты (4)

Если файл имеет ZoneId 3 или 4, то PowerShell считает его удаленным. А если на компьютере включена конфигурация усиленной безопасности Internet Explorer, то файлы, взятые из локальной сети, тоже могут считаться удаленными.

Как выполнить удаленный скрипт? Во первых его  можно разблокировать (превратить в локальный), для этого есть специальный командлет Unblock-File. Хотя если просто открыть скрипт на локальном компьютере и внести в него изменения, то он тоже станет локальным.

Ну и во вторых удаленный скрипт можно подписать. Подписывание скриптов — это тема отдельной статьи, поэтому вдаваться в подробности не будем. Просто подпишем его уже имеющимся сертификатом, проверим подпись и выполним. На сей раз успешно.

Переходим к политике AllSigned. Это наиболее жесткая политика, требующая подписывания всех без исключения скриптов, как удаленных так и локальных. И даже с подписанными скриптами она работает не так, как RemoteSigned. Для примера сменим политику на AllSigned и снова запустим подписанный скрипт. В этот раз для его выполнения потребуется подтверждение, т.к. PowerShell посчитал подпись недоверенной.

Области применения

Политика выполнения имеет свою область действия (scope). Всего есть 5 областей:

• LocalMachine — политика действует на всех пользователей данного компьютера. Значение хранится в реестре, в разделе HKEY_LOCAL_MACHINE;
• CurrentUser — политика действует только на текущего пользователя. Хранится в разделе реестра HKEY_CURRENT_USER;
• Process — действие политики распространяется только на текущий сеанс PowerShell. Значение хранится в переменной окружения $PSExecutionPolicyPreference и при закрытии сеанса удаляется;
• Userpolicy — политика действует на всех пользователей данного компьютера. Распространяется с помощью групповых политик. Значение хранится в разделе пользователя, соответственно политика применяется при входе пользователя в систему;
• MachinePolicy — действует на всех пользователей данного компьютера. Распространяется с помощью групповых политик. Значение хранится в разделе компьютера, политика применяется при загрузке системы;

Вывести значение политики для всех областей можно командой:

Get-ExecutionPolicy -List

Получается, что при установке политики без указания области изменяется значение LocalMachine. Если же требуется указать конкретную область действия, то сделать это можно с помощью параметра Scope командлета Set-ExecutionPolicy. Для примера установим для области СurrentUser политику Bypass:

Set-ExecutionPolicy -Scope CurrentUser -ExecutionPolicy Bypass -Force

Затем проверим значение политики в текущем сеансе и убедимся в том, что оно изменилось на Bypass.

Теперь установим политику Unrestricted для области Process:

Set-ExecutionPolicy -Scope Process -ExecutionPolicy Unrestricted -Force

Еще раз проверим текущую политику, теперь она имеет значение Unrestricted. Т.е. более ″конкретная″ политика всегда имеет больший приоритет.

Для областей UserPolicy и MachinePolicy значение политики задаются через GPO. За настройку отвечает параметр Turn on Script Execution (Включить выполнение сценариев), находящийся в разделе Administrative TemplatesWindows ComponentsWindows PowerShell. Для UserPolicy он находится в конфигурации пользователя (User Configuration), для MachinePolicy — в конфигурации компьютера (Computer Configuration). Политика, применяемая к компьютеру, имеет приоритет перед политикой пользователя.

Для установки политики надо включить параметр и выбрать одно из трех значений:

• Allow only signed scripts (Разрешать только подписанные сценарии) — политика AllSigned;
• Allow local scripts and remote signed scripts (разрешать локальные и удаленные подписанные сценарии) — политика RemoteSigned;
• Allow all scripts (Разрешать все сценарии) — политика Unrestricted.

Политика Bypass считается небезопасной и ее нельзя установить через групповые политики.

Для примера установим для MachinePolicy политику RemoteSigned и проверим результат. Как видите, политика, назначенная через GPO, имеет больший приоритет и переопределяет все остальные политики.

Более того, при использовании GPO становится невозможным переназначить политики вручную. При попытке изменения выдается предупреждение, а текущая политика остается без изменений.

А что будет, если ни для одной области политика не определена, т.е. везде стоит значение Undefined?  В этом случае все просто, выполнение всех скриптов запрещается, а текущая политика принимает значение Restricted.

Обход политики

Можно ли как то  запустить скрип в обход политики выполнения, не изменяя ее значение? В принципе можно, есть несколько способов.

К примеру для того, чтобы выполнить скрипт, достаточно открыть его в проводнике, кликнуть правой клавишей мыши и выбрать пункт Выполнить с помощью PowewrShell (Run with PowerShell).  Это запускает оболочку PowerShell c политикой Bypass. При этом политика применяется только для выполнения конкретного скрипта, значение политики в реестре не изменяется.

Этот способ называется  ″Run with PowerShell″ и у него есть некоторые ограничения. Скрипты, запущенные таким образом, не могут взаимодействовать с пользователем (выводить сообщения на экран, требовать ввода данных и т.п.). Скрипт просто запускается, выполняется и немедленно закрывается.

Собственно говоря, предыдущий способ использует запуск PowerShell с указанием требуемой политики. Сделать это можно из командной строки, например для запуска скрипта можно попробовать такую команду:

powershell.exe -file .script.ps1 -Executionpolicy Bypass

Теоретически эта команда должна выполнить скрипт, не смотря на текущую политику. Так написано в официальной документации Microsoft. На практике же этот способ работает не всегда, например  на одном из проверенных мной компьютеров я получил ошибку. При этом из проводника скрипт успешно выполнился.

Еще один вариант — это попробовать изменить политику выполнения для области Process. Эта операция не вносит изменений в реестр и не требует прав администратора. Но в том случае, если для назначения политики выполнения используются групповые политики, этот способ не сработает.

Ну и наконец можно просто считать содержимое скрипта и выполнить его в виде команды. Например так:

$script = Get-Content ./script.ps1
Invoke-Expression -Command ″$script″