Если вы не слышали о 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 для исключения выполнения удаленных скриптов.
За границей настроек по умолчанию
По умолчанию ExecutionPolicy в PowerShell достаточно строгая. Она не позволяет скриптам запускаться отовсюду. То есть скрипты, созданные вами и всунутые в систему, не будут запущены. Скрипты, загруженные из Интернета, не будут запущены. Даже те скрипты, которые вы подписываете, не будут запущены. Поэтому вам понадобится переставить уровень политики ExecutionPolicy перед запуском своих скриптов.
Установка уровня политики ExecutionPolicy
Всего существует 4 уровня политики ExecutionPolicy. Эти 4 уровня обеспечивают хорошую надежность в том, что будут делать скрипты, и каким требованиям надо удовлетворять, чтобы выполнять скрипты. Эти четыре уровня и требования включают в себя:
RestrictedЭто конфигурация PowerShell по умолчанию. Эта конфигурация означает, что никакие скрипты не могут быть запущены, вне зависимости от подписи. Единственное, что можно делать в PowerShell при такой настройке — это выполнять одиночные команды.
AllSignedЭта настройка позволяет выполнять скрипты в PowerShell. Скрипт должен иметь электронную подпись от доверенного источника. Перед тем, как выполнить скрипт от такого источника, выскочит предупреждение.
RemoteSignedЭта настройка позволяет выполнять скрипты, но требует, чтобы все скрипты и файлы конфигурации, загруженные из Интернета, имели электронные подписи от доверенного источника. Скриптам, выполняющимся на локальном компьютере, не требуется подпись. Нет никаких предупреждений перед запуском скриптов. Все еще предупреждает вас о скриптах, которые хоть и подписаны, но потенциально опасны.
UnrestrictedТакая настройка не рекомендуется! Она позволяет запускать неподписанные скрипты, включая те, что загружены из Интернета. Сюда входят и файлы из Outlook и Messenger. Здесь риск в запуске скриптов без подписи и надежности.
Для установки любого из этих уровней, просто наберите set-executionpolicy <level>, как показано на Рисунке 4.
Рисунок 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).
Рисунок 5. PowerShell ADM шаблон добавляет настройки в Computer Configuration и User Configuration для выполнения скриптов.
Когда вы соберетесь настраивать эту политику, вы увидите, что у вас есть три опции для настройки (Рисунок 6).
Рисунок 6. Настройки ExecutionPolicy для PowerShell в GPO.
Заключение
PowerShell — новое слово в своей области. С Windows Server 2008, выходящим в начале 2008, PowerShell взлетит как ракета. Ему уделяется столько внимания, и каждый надеется, что он выйдет с уже встроенной безопасностью. И беспокойство ни к чему. PowerShell обеспечивает идеальную безопасность простыми свойствами по умолчанию. Тот факт, что политика скриптов установлена на restricted execution policy, является фантастическим. Даже если вы создали .PS1 файл, скрипт, связанный с Notepad, — хорошая надежность по умолчанию. Даже если вы можете запустить интерфейс PowerShell, тот факт, что вы должны вводить полный путь к скрипту, добавляет надежности. А если выйти за границы настроек по умолчанию, возможность устанавливать политику выполнения и контролировать PowerShell с помощью групповой политики дает централизованный контроль над надежностью PowerShell.
Автор: Дерек Мелбер (Derek Melber)
Источник: www.winsecurity.ru