Sunday, July 22nd, 2018

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

Published on Февраль 4, 2009 by   ·   Комментариев нет

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

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

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

Что в пути?

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

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

Политика безопасности в powershell

Рисунок 1. Для запуска скрипта требуется указывать полный путь.

А теперь давайте взглянем на то, что произойдет, если включить полный путь к скрипту (Рисунок 2).

Powershell узнать папку запуска

Рисунок 2. При указании полного пути скрипт выполняется без проблем.

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

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

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

Powershell выключить подпись

Рисунок 3. По умолчанию ExecutionPolicy установлена на Restricted для исключения выполнения удаленных скриптов.

За границей настроек по умолчанию

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

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

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

Restricted
Это конфигурация PowerShell по умолчанию. Эта конфигурация означает, что никакие скрипты не могут быть запущены, вне зависимости от подписи. Единственное, что можно делать в PowerShell при такой настройке — это выполнять одиночные команды.
AllSigned
Эта настройка позволяет выполнять скрипты в PowerShell. Скрипт должен иметь электронную подпись от доверенного источника. Перед тем, как выполнить скрипт от такого источника, выскочит предупреждение.
RemoteSigned
Эта настройка позволяет выполнять скрипты, но требует, чтобы все скрипты и файлы конфигурации, загруженные из Интернета, имели электронные подписи от доверенного источника. Скриптам, выполняющимся на локальном компьютере, не требуется подпись. Нет никаких предупреждений перед запуском скриптов. Все еще предупреждает вас о скриптах, которые хоть и подписаны, но потенциально опасны.
Unrestricted
Такая настройка не рекомендуется! Она позволяет запускать неподписанные скрипты, включая те, что загружены из Интернета. Сюда входят и файлы из Outlook и Messenger. Здесь риск в запуске скриптов без подписи и надежности.

Для установки любого из этих уровней, просто наберите set-executionpolicy <level>, как показано на Рисунке 4.

Включить выполнение скриптов powershell

Рисунок 4. Установка политики ExecutionPolicy проста до выполнения простой команды set-executionpolicy.

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

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

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

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

После загрузки вам нужно будет установить MSI. Я допускаю, что это не самый ясный и не самый эффективный способ. После установки ADM файл отправляется в папку C:\program files\Microsoft Group Policy. И ничего больше, что очень надежно! Файл, который нужно импортировать в редактор Group Policy Object Editor — PowerShellExtensionPolicy.ADM. После импорта у вас появится два новых узла в Group Policy Object. Один из них будет в Computer Configuration\Administrative Templates\Windows Components\Windows PowerShell и другой в User Configuration\Administrative Templates\Windows Components\Windows PowerShell (Рисунок 5).

Как запустить скрипт powershell?

Рисунок 5. PowerShell ADM шаблон добавляет настройки в Computer Configuration и User Configuration для выполнения скриптов.

Когда вы соберетесь настраивать эту политику, вы увидите, что у вас есть три опции для настройки (Рисунок 6).

Powershell рисование образов

Рисунок 6. Настройки ExecutionPolicy для PowerShell в GPO.

Заключение

PowerShell — новое слово в своей области. С Windows Server 2008, выходящим в начале 2008, PowerShell взлетит как ракета. Ему уделяется столько внимания, и каждый надеется, что он выйдет с уже встроенной безопасностью. И беспокойство ни к чему. PowerShell обеспечивает идеальную безопасность простыми свойствами по умолчанию. Тот факт, что политика скриптов установлена на restricted execution policy, является фантастическим. Даже если вы создали .PS1 файл, скрипт, связанный с Notepad, — хорошая надежность по умолчанию. Даже если вы можете запустить интерфейс PowerShell, тот факт, что вы должны вводить полный путь к скрипту, добавляет надежности. А если выйти за границы настроек по умолчанию, возможность устанавливать политику выполнения и контролировать PowerShell с помощью групповой политики дает централизованный контроль над надежностью PowerShell.

Источник www.windowsecurity.com


Смотрите также:

Readers Comments (Комментариев нет)




Да человек я, человек! =)

Exchange 2007

Проведение мониторинга Exchange 2007 с помощью диспетчера System Center Operations Manager 2007 (часть 3)

Если вы хотите прочитать предыдущие части этой серии статей, перейдите по ссылкам: Проведение мониторинга Exchange 2007 с помощью диспетчера System ... [+]

Практическое рассмотрение перехода с Exchange 2003 на Exchange 2007 (часть 1)

Введение В этой статье из нескольких частей я хочу показать вам процесс, который недавно использовал для перехода с существующей среды Exchange 2003 ... [+]

Использование инструмента Exchange Server Remote Connectivity Analyzer Tool (часть 2)

Если вы пропустили первую часть этой серии, пожалуйста, прочтите ее по ссылке Использование инструмента Exchange Server Remote Connectivity Analyzer Tool (Часть ... [+]

Мониторинг Exchange 2007 с помощью диспетчера System Center Operations Manager 2007 (часть 2)

Если вы пропустили предыдущую часть этой серии статей, перейдите по ссылке Мониторинг Exchange 2007 с помощью диспетчера System Center Operations ... [+]

Подробное рассмотрение подготовки Active Directory для Exchange 2007 (часть 5)

Если вы пропустили предыдущие части этой серии статей, перейдите по ссылкам: Подробное рассмотрение подготовки Active Directory для Exchange 2007 (часть 1) ... [+]

Установка и настройка Exchange 2007 из командной строки (Часть 3)

If you missed the previous parts in this article series please read: Exchange 2007 Install and Configuration from the command line (Part ... [+]

Использование инструмента Exchange Server Remote Connectivity Analyzer Tool (часть 1)

Инструмент ExRCA Текущий выпуск инструмента предоставляется только в целях тестирования и оснащен 5 опциями: Тест подключения Outlook 2007 Autodiscover Тест подключения Outlook 2003 RPC ... [+]

Развертывание сервера Exchange 2007 Edge Transport (часть 5)

Если вы хотите прочитать предыдущие части этой серии статей, перейдите по ссылкам: Развертывание сервера Exchange 2007 Edge Transport (часть 1) Развертывание ... [+]

Установка и настройка Exchange 2007 из командной строки (часть 2)

Если вы пропустили первую статью данного цикла, пожалуйста, перейдите по ссылке: Exchange 2007 Install and Configuration from the command line (Part ... [+]

Использование интегрированных сценариев Using Exchange Server 2007 – часть 2: генерирование отчетов агента Transport AntiSpam Agent

Если вы пропустили предыдущую часть этой серии статей, перейдите по ссылке Использование интегрированных сценариев Using Exchange Server 2007 – часть ... [+]