Windows PowerShell. Обеспечение безопасности Shell.
Когда команда, работавшая над созданием Windows PowerShell, засела за создание новой оболочки и за столом прозвучало слово «сценарии», скорбные стоны были, вероятно, слышны на весь Редмонд. В конце концов, предыдущие опыты Майкрософт в области сценариев администрирования — здесь я имею в виду VBScript — нельзя назвать лишенными недостатков. Излишне либеральная модель выполнения в сочетании с привычкой большинства пользователей входить в систему с полными правами администратора проложила дорогу для несчастья.
«Только бы, — должно быть, молились собравшиеся на первом рабочем совещании по Windows PowerShell™, — не пришлось нам испытать все это снова». Не пришлось. Корпорация Майкрософт значительно улучшила свою репутацию по части безопасности, во многом потому, что начала обращать на нее внимание в первую очередь, а не на поздних этапах разработки программного обеспечения. Такой подход весьма заметен в Windows PowerShell.
Почему не запускаются мои сценарии?
Установите Windows PowerShell на свежем компьютере и дважды щелкните файл PS1: появится Notepad, а не Windows PowerShell. Это произойдет потому, что расширение имени файла PS1 — расширение, используемое для сценариев Windows PowerShell, — не сопоставляется с самой оболочкой. Другими словами, сценарии не запускаются простым двойным щелчком. Единственный способ запустить сценарий — открыть Windows PowerShell, ввести имя сценария и нажать клавишу ВВОД.
На самом деле, простого ввода имени сценария тоже недостаточно. Как можно увидеть на Рис. 1, файл Demo1.ps1 находится в текущей папке, однако ввод demo1 и нажатие клавиши ВВОД заканчивается ошибкой: «Терм 'demo1' не опознан как командлет, функция, выполнимая программа или файл сценария». Почему это происходит? Ведь файл находится там, где надо.
Рис. 1 Windows PowerShell требует путь к сценарию в целях предотвращения подмены команд (Щелкните изображение, чтобы увеличить его)
Это еще один аспект модели безопасности Windows PowerShell. Один из приемов, часто используемых злоумышленниками в других оболочках, заключается в создании сценария с тем же именем, что и встроенная команда. Для примера, если злоумышленник хочет, чтобы пользователь запустил его сценарий, он может назвать его Dir.ps1 и забросить в какую-нибудь папку. Если пользователь имел несчастье ввести Dir и нажать клавишу ВВОД, запустится не команда Dir, которую он ожидал, а сценарий злоумышленника. Этот прием называется подменой команд. В Windows PowerShell пользователь всегда должен указать путь к такому сценарию, что делает оболочку Windows PowerShell весьма хорошо защищенной от подмены команд.
Запустить demo1 не получается из-за отсутствия пути, но запуск ./demo1 работает. Происходит это потому, что теперь я указал путь — текущую папку. Такую командную строку сложнее спутать со встроенной командой, поскольку при обращении к встроенной команде не указывается путь. Таким образом, требование пути помогает Windows PowerShell избежать подмены команд и неуверенности относительно последствий нажатия клавиши ВВОД.
Политика выполнения сценариев
Допустим, у пользователя есть свежеустановленная копия Windows PowerShell, он использует правильный синтаксис и пытается запустить сценарий. К его удивлению, он сталкивается с очередным сообщением об ошибке, информирующим его, что Windows PowerShell не позволено запускать сценарии. Что такое??? Позвольте представить. Политика выполнения оболочки.
Текущую политику выполнения можно увидеть, запустив Get-ExecutionPolicy в оболочке. По умолчанию она установлена на Restricted, что попросту означает запрет на запуск сценариев. Полный запрет. Для всех. По умолчанию оболочку Windows PowerShell можно использовать только интерактивно, но не для запуска сценариев. Командлет Set-ExecutionPolicy можно использовать для выбора одного из четырех режимов политики выполнения:
• Restricted, настройка по умолчанию, не допускает запуска сценариев. • AllSigned допускает запуск лишь доверенных сценариев (подробнее об этом рассказано чуть ниже). • RemoteSigned допускает запуск локальных сценариев, даже если они не являются доверенными, однако сценарии, загруженные из Интернета, должны быть доверенными для возможности их запуска. • Unrestricted допускает запуск всех сценариев, даже не являющихся доверенными.
Откровенно говоря, AllSigned — минимальный режим для рабочего компьютера. RemoteSigned я нахожу полезным для разработки и тестирования, но вряд ли он необходим среднему пользователю. Unrestricted же мне кажется ненужным, и я не стал бы возражать, если бы в одной из будущих версий Windows PowerShell этот чрезмерно либеральный режим был полностью исключен.
Это вопрос доверия
Компьютер любого пользователя заранее настроен на то, чтобы считать доверенными определенные корневые центры сертификации — то есть серверы, выпускающие цифровые сертификаты. На Рис. 2 показано приложение панели управления «Свойства обозревателя», перечисляющее доверенные корневые CA. В Windows Vista®, этот список весьма короток, включая лишь несколько крупных коммерческих центров сертификации. В Windows® XP, напротив, список по умолчанию настолько велик, что о многих корневых центрах сертификации из него я никогда не слышал ранее. Помещая центр сертификации в этот список, пользователь, по сути, говорит, что он доверяет компании, управляющей корневым центром сертификации, и ее дотошности при проверке тех, кому она поставляет цифровые сертификаты.
При получении цифрового сертификата класса III — часто именуемого сертификатом подписывания кода — центр сертификации (который может быть коммерческим центром сертификации или частным центром сертификации, существующим в рамках организации пользователя) должен удостовериться в личности пользователя. Цифровой сертификат подобен электронному паспорту или идентификационной карте. Скажем, перед выдачей мне идентификатора, говорящего, что я Дон Джонс, центру сертификации нужно предпринять определенные шаги, чтобы удостовериться, действительно ли я Дон Джонс. При использовании своего сертификата для установки цифровой подписи на сценарий Windows PowerShell, что делается с помощью командлета Set-AuthenticodeSignature, пользователь ставит на него подпись со своим именем. Само собой, если ему удалось добыть фальшивый сертификат с чужим именем, он может использовать его для подписывания сценария, почему и важно, чтобы список на Рис 2 содержал только достойные доверия центры сертификации.
Рис. 2 Доверенные корневые центры сертификации по умолчанию в Windows Vista[/center]
Когда Windows PowerShell проверяет, является ли сценарий доверенным — что она делает при режимах политики выполнения AllSigned и RemoteSigned — она ставит три вопроса:
• Подписан ли сценарий? Если нет, он не является доверенным. • Цела ли подпись? Другими словами, не изменялся ли сценарий после подписывания? Если подпись не цела, сценарий не является доверенным. • Была ли подпись создана при помощи цифрового сертификата, выпущенного доверенным корневым центром сертификации? Если нет, он не является доверенным.
Как система доверия улучшает безопасность? Конечно, хакер, в принципе, может написать вредоносный сценарий, подписать его и убедить кого-нибудь в среде пользователя исполнить его. Поскольку сценарий был подписан, он запустится. Но подпись можно использовать для обнаружения личности автора и принятия соответствующих мер (таких, как обращение в правоохранительные органы). Впрочем, только законченный дурак может подписать вредоносный сценарий своим собственным именем!
Само собой, если пользователь-злоумышленник сумел добыть сертификат под чужим именем — скажем, от центра сертификации, не располагающего надежной процедурой проверки личности — подпись не удастся использовать для обнаружения настоящего виновника. Именно поэтому от корневых центров сертификации требуется наличие удовлетворительной для пользователя процедуры проверки личности.
При использовании режима политики выполнения AllSigned пользователю даже необходимо ставить цифровые подписи на все сценарии, созданные им самим, прежде чем запускать их. Использовать командлет Set-AuthenticodeSignature довольно легко, но все же это может стать изрядным препятствием. Тут-то и может пригодиться программное обеспечение от сторонних производителей. Я рекомендую выбрать редактор сценариев или среду визуальной разработки, автоматически подписывающую сценарии, используя указанный ей сертификат. Это делает использование подписей прозрачным и не требующим дополнительных усилий. Чтобы получить совет насчет редакторов и сред разработки, поддерживающих данную функцию, можно пройтись по сетевым форумам создателей сценариев (таким, как мой веб-узел ScriptingAnswers.com) и создать сообщение, спрашивающее у любителей Windows PowerShell, что они используют.
По получении сертификата можно также запустить следующую команду, чтобы подписать все сценарии, находящиеся в определенном месте:
Set-AuthenticodeSignature — ключевой элемент цифрового подписывания сценариев Windows PowerShell, позволяющий пользователю применять наиболее безопасную политику выполнения, AllSigned. Для использования этого командлета, нужно начать с другого — Get-ChildItem — который получает установленный сертификат подписывания кода:
Здесь необходимо заменить путь к файлу на другой, указывающий на установленный сертификат — любой установленный сертификат будет доступен через cert: drive. После загрузки сертификата запустите следующий файл для подписывания сценария: Set-AuthenticodeSignature MyScript.ps1
–cert $cert
Само собой, нужно предоставить полный путь к файлу сценария PS1. Оболочка добавит блок подписи к сценарию.
Централизованная безопасность
Политику выполнения Windows PowerShell, можно, само собой, устанавливать отдельно на каждом компьютере. Но это решение не является удовлетворительным для корпоративных сред. Вместо него можно использовать групповую политику. (Административные шаблоны Windows PowerShell можно загрузить с go.microsoft.com/fwlink/?LinkId=93675.) Просто перетащите файл в объект групповой политики (GPO), действующий на домен в целом, и установите для него режим Restricted. Таким образом, можно быть уверенным, что где бы ни была установлена оболочка Windows PowerShell, сценарии не станут запускаться. Затем можно применить более либеральный режим (скажем, AllSigned) для тех компьютеров, где предполагается запускать сценарии (таких, как собственная рабочая станция).
Альтернативные учетные данных
В отличие от всех предыдущих административных языков сценариев для Windows, Windows PowerShell даже готова к безопасной работе с альтернативными учетными данными. Например, командлет Get-WMIObject имеет параметр –credential, который позволяет указать альтернативные учетные данные для удаленных подключений WMI. Данный параметр может принять имя пользователя, но не пароль, не позволяя жестко программировать конфиденциальные пароли в сценарий в формате открытого текста. Вместо этого, после предоставления имени пользователя, Windows PowerShell запрашивает пароль, используя диалоговое окно. Если планируется использовать альтернативные учетные данные снова, сведения, относящиеся к проверке подлинности, можно сохранить при помощи командлета Get-Credential:
$cred = Get-Credential DOMAIN\USER
Последует немедленный запрос пароля, и итоговые учетные данные будут сохранены в переменной $cred. Переменная $cred может затем передаваться параметру –credential настолько часто, насколько нужно. Можно даже использовать командлеты ConvertTo-SecureString и ConvertFrom-SecureString для преобразования учетных данных в зашифрованную строку, или ранее зашифрованной строки обратно в учетные данные.
Однако при этом ключ шифрования оказывается хранимым в обычном текстовом сценарии, что начисто разрушает безопасность. Так что вместо этого можно добавить вызов Get-Credential в профиль Windows PowerShell. Впоследствии при запусках Windows PowerShell будет немедленно следовать запрос имени пользователя и пароля, сохраняемых затем в переменной $cred. Таким образом, переменная $cred всегда остается доступной в оболочке, представляя учетную запись администратора домена. Волноваться о хранении этих учетных данных больше не придется — поскольку они воссоздаются при каждом запуске оболочки, их не нужно хранить.
Безопасная по умолчанию
По умолчанию Windows PowerShell устанавливается и настраивается с наиболее жестким режимом безопасности, который можно придумать для административной оболочки, поддерживающей написание сценариев. Пока эти параметры остаются неименными, Windows PowerShell будет настолько безопасной, насколько возможно. Другими словами, любое уменьшение безопасности Windows PowerShell является результатом решений и действий пользователя. Так что перед тем, как менять любые параметры по умолчанию — включая допустимые расширения файлов, политику выполнения и так далее — следует удостовериться в своем понимании последствий этих действий и готовности нести ответственность за вносимые изменения.
Дон Джонс (Don Jones) — ведущий программист компании SAPIEN Technologies и преподаватель на ScriptingTraining.com. Связаться с ним можно через его веб-узел ScriptingAnswers.com.
