Безопасность PowerShell

Если вы не слышали о PowerShell, значит, вы живете в затруднительном положении. Если вы слышали о PowerShell, то вам, должно быть, было интересно, насколько безопасен PowerShell. Я впервые увидел PowerShell около 4 лет назад на конференции MVP. При всех усилиях и потехах, которые были вложены в PowerShell, лучше бы он был оснащен какой-нибудь продвинутой системой безопасности. Что ж, это так! PowerShell — это не просто обычный язык сценариев. Существуют встроенные функции безопасности, а также некоторые дополнительные средства безопасности, которые можно настроить один раз в PowerShell.

Безопасность PowerShell по умолчанию

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

Что находится на пути?

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

Например, если вы хотите запустить сценарий с именем Example.ps1 из папки C:scripts, вам потребуется указать полный путь к сценарию, даже если вы находитесь в папке C:scripts в PowerShell. На рис. 1 показано, что происходит, когда вы просто пытаетесь запустить Example.ps1 без указания пути.

Рисунок 1. Сценарии должны включать путь к сценарию для успешного выполнения

Теперь посмотрите, что происходит, когда вы запускаете скрипт, включая путь к скрипту, как показано на рисунке 2.

Рисунок 2. Когда путь включен в скрипт, скрипт работает без сбоев

Почему я ограничен?

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

Этот параметр по умолчанию связан с параметром ExecutionPolicy в PowerShell. ExecutionPolicy по умолчанию имеет значение Restricted, как показано на рис. 3.

Рисунок 3. ExecutionPolicy по умолчанию имеет значение Restricted, чтобы обеспечить выполнение удаленных сценариев PowerShell.

Выход за рамки значений по умолчанию

ExecutionPolicy по умолчанию в PowerShell очень безопасна. Он не позволяет запускать какие-либо сценарии из любого места. Таким образом, сценарии, которые вы создаете и устанавливаете в систему, не будут работать. Скрипты, загруженные из Интернета, работать не будут. Скрипты, которые вы даже подписываете и защищаете до n-й степени, не будут работать. Поэтому вам нужно будет сбросить уровень ExecutionPolicy, прежде чем вы сможете запускать свои скрипты.

Установка уровня ExecutionPolicy

Существует четыре уровня ExecutionPolicy. Эти четыре уровня обеспечивают большую безопасность в отношении того, какие сценарии могут выполняться и какие требования должны быть связаны с запуском сценария. Четыре уровня и требования включают в себя:

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

AllSigned
Этот параметр разрешает выполнение сценариев в PowerShell. Сценарий должен иметь связанную цифровую подпись от доверенного издателя. Перед запуском сценариев от доверенных издателей появится запрос. Это подвергает вас запуску подписанных, но вредоносных сценариев.

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

Неограниченный
Это не рекомендуемая настройка! Это позволяет запускать неподписанные сценарии, включая все сценарии и файлы конфигурации, загруженные из Интернета. Это будет включать файлы из Outlook и Messenger. Риск здесь заключается в запуске скриптов без какой-либо подписи или безопасности.

Чтобы установить любой из этих уровней, просто введите set-executionpolicy <level>, как показано на рисунке 4.

Рисунок 4: Настроить ExecutionPolicy так же просто, как запустить команду set-executionpolicy.

Использование групповой политики

PowerShell великолепен, но если сценарии не могут выполняться на компьютерах в вашей среде, у него есть ограничения. Во-первых, вы должны установить PowerShell на каждый компьютер. Поскольку PowerShell устанавливается через EXE-файл, установить приложение очень просто. Вы можете либо использовать ZAP-файл и отправить его с помощью групповой политики, либо использовать свой текущий централизованный метод установки приложений. Имейте в виду, что PowerShell считается исправлением, поэтому Центр обновления Windows также может вытолкнуть установку PowerShell.

После того, как вы установили PowerShell, мы только что выяснили, что вам нужно разрешить выполнение сценариев. Если для параметра ExecutionPolicy установлено значение Restricted по умолчанию, вам необходимо настроить каждый компьютер для запуска сценариев, которые будут запускать сценарии. Это может занять несколько дней, если вы пытаетесь сделать это вручную.

Однако вы также можете использовать групповую политику, чтобы сделать это за вас. Конечно, вы можете создать свой собственный административный шаблон (файл ADM), чтобы внести это изменение, или загрузить шаблон ADM, который предоставляет вам Microsoft. Я предлагаю вам сделать последнее, загрузив шаблон ADM.

После загрузки вам нужно будет установить MSI. Я признаю, что это не самая чистая и эффективная установка. После установки файл ADM помещается в папку C:program filesMicrosoft Group Policy. Если ничего другого, это большая безопасность! Файл, который необходимо импортировать в редактор объектов групповой политики, называется PowerShellExtensionPolicy.ADM. После импорта у вас будет два новых узла в вашем объекте групповой политики. Один будет находиться в папке Computer ConfigurationAdministrative TemplatesWindows ComponentsWindows PowerShell, а другой — в User ConfigurationAdministrative TemplatesWindows ComponentsWindows PowerShell, как показано на рисунке 5.

Рисунок 5: Шаблон PowerShell ADM добавляет параметры в конфигурацию компьютера и конфигурацию пользователя для выполнения скрипта

Когда вы перейдете к настройке этой политики, вы увидите, что у вас есть три варианта настройки, как показано на рисунке 6.

Рисунок 6: Параметры ExecutionPolicy для PowerShell в GPO

Резюме

PowerShell — новинка в мире. С выходом Windows Server 2008 в начале 2008 года PowerShell взлетит, как ракета. При всем том внимании, которое уделяется PowerShell, все надеются, что в него уже встроена система безопасности. Что ж, тревога закончилась. PowerShell обеспечивает безопасность прямо из коробки с функциями безопасности по умолчанию. Тот факт, что сценарии настроены на ограниченную политику выполнения, просто фантастика. Даже если вы создали файл.PS1, этот сценарий, связанный с Блокнотом, является хорошей защитой по умолчанию. Даже если вы можете получить доступ к интерфейсу PowerShell, тот факт, что путь к сценарию должен быть введен, добавляет ценности. Помимо настроек по умолчанию, возможность устанавливать политику выполнения и управлять PowerShell с помощью групповой политики обеспечивает централизованный контроль над безопасностью PowerShell.