Введение

Сегодня хочу поговорить про OCSP – Online Certificate Status Protocol, который служит для проверки статуса сертификата на предмет отозванности. Как известно, стандартным механизмом проверки статуса сертификата является публикация CRL (Certificate Revocation List). В жизни существует 2 вида CRL:

• Base CRL – полный список CRL, в котором указываются серийные номера всех отозванных в CA сертификатов и причина отзыва. Поддерживается всеми современными системами Windows. Характеризуется большим объёмом и не очень частой публикацией для уменьшения трафика.
• Delta CRL – инкрементальный (хотя по факту это скорее дифференциальный) список CRL, в который включаются только сертификаты, которые были отозваны с момента последней публикации полного Base CRL. Характеризуется небольшим объёмом и относительно частой публикацией. Нативно поддерживается только системами не ниже Windows XP. Windows 2000 нативно не умеет его читать, но это становится возможным после применения патча MS04-011.

Опыт использования технологии CRL в широкой массе показал её негативные стороны. Если говорить о Base CRL, то Windows Server 2003/2008 по умолчанию публикуют этот список раз в неделю и в него включаются все сертификаты, которые были выданы и отозваны с момента последнего обновления сертификата CA. Т.к. эти сертификаты как правило выдаются на долгий срок (от 5 до 20 лет), то эти списки со временем могут сильно распухнуть. Из-за этого клиенту для проверки сертификата нужно вытягивать весь Base CRL с CA и искать там требуемый сертификат. Кстати, почему HTTPS сайты частенько тормозят :-) Учитывая, что Base CRL публикуются не очень часто, то для обеспечение наиболее актуального списка CRL была внедрена система Delta CRL, которая включает в себя только сертификаты, которые были отозваны с момента последней публикации Base CRL. По умолчанию CA под управлением Windows Server 2003/2008 публикуют его раз в сутки.

Но это не отменяет необходимости клиенту как скачивать не только Base CRL, но и приходится дополнительно скачивать Delta CRL. Однако Certificate Services в Windows Server 2008 позволяют нам сделать жизнь чуточку лучше и облегчить процесс валидации сертификата за счёт использования OCSP.

Вкратце, OCSP работает очень просто: клиент для проверки статуса сертификата отправляет запрос на OCSP Responder с указанием серийного номера проверяемого сертификата. OCSP Responder на своей стороне проверяет статус сертификата и возвращает этот статус клиенту.

Примечание: использовать протокол OCSP нативно умеют только клиенты под управлением Windows Vista и выше. Предыдущие ОС могут его поддерживать только за счёт сторонних компонентов.

Настройка шаблона CA

Итак, для начала нам потребуется установленный в сети Certification Authority под управлением Windows Server 2008 (любой редакции, кроме Web). По умолчанию с добавлением роли  AD CS добавляется и служба Online Respnder. Для этого так же потребуется установить службы IIS, о чём мастер вам сообщит и предложит сделать. На сервере CA необходимо запустить оснастку Certificate Templates (Start –> Run... –> certtmpl.msc) и там найти шаблон OCSP Response Signing:

fig.1

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

• срок действия сертификата составляет 2 недели
• на вкалдке Request Handlings добавлено право чтения приватного ключа для службы Network Service, поскольку служба OCSP работает от лица Network Service, а не LocalSystem (для LocalSystem отдельных разрешений не требуется)
• шаблон не содержит CDP и AIA расширений
• шаблон помечен как неподлежащий для проверки на отзыв (см. fig.1)

На вкладке Security необходимо для учётной записи компьютера, на котором размещён OCSP выдать право Allow Read и Allow Enroll. Это единственное изменение, которое необходимо выполнить для шаблона. Теперь нужно открыть оснастку Certificate Authority и добавить этот шаблон для выдачи:

правой кнопкой на Certificate Templates –> New –> Certificate Template to Issue –> OSCP Response Signing. Далее нужно создать оснастку Certificates для учётной записи компьютера и запросить сертификат на основе этого шаблона с компьютера, где установлен OCSP Responder.

После запроса сертификата не стоит закрывать оснастку Certificates, а выбрать новый сертификат и в All Tasks выбрать Manage Privete keys. В открывшемся окне Permissions выдайте право Read для учётной записи Network Service:

fig.2

Настройка CA

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

fig.3

В списке Extensions выбираем Authority Information Access (AIA), нажимаем Add и в поле вписываем URL для OCSP. В моём случае это http://dc2.contoso.com/ocsp. А так же выставляем нижнюю галочку, чтобы этот путь добавлялся во все издаваемые этим CA сертификаты.

Примечание от 09.08.2009: здесь у меня опечатка на скриншоте - нужно поставить только одну галочку, а именно - только нижнюю. Адрес OCSP не нужно добавлять в AIA издаваемых сертификатов, иначе клиент будет с OCSP адреса пытаться скачать CRT файл.

Примечание: учитвая, что срок действия такого сертификата всего 2 недели, не следует этот шаблон добавлять в Autoenrollment (если используется) Policies, т.к. тут возможны трудности с валидацией сертификата на отрезке времени когда обновляется сертификат CA. Вот как это может выглядеть:

fig.4

в промежутке t0 – t2 используется старый ключ CA для подписи сертификатов (в том числе и OCSP). В промежутке t1-t3 используется новый сертификат CA. И когда наступает этап t1, когда старый сертификат ещё до истечения срока обновляется на новый, то в промежутке t1-t2 может случиться следующее:

• клиент отправляет запрос на проверку статуса сертификата Cert1 или Cert2, которые подписаны ключом CA Key 1
• на сервере CA уже действует новый ключ CA Key 2 и, соответственно, подписанный новым ключом сертификат OCSP
• сервер подписывает новым ключом OCSP ответ для клиента и пересылает
• клиент сверяет подписи OCSP и проверяемого сертификата. Подписи не совпадут, т.к. сертификат подписан ключом CA Key 1, а OCSP ответ уже ключом CA Key 2 и откланяет ответ от OCSP Responder, поскольку проверяемый сертификат и сертификат подписи Online Responder должны быть подписаны одним ключом CA.

Чтобы устранить проблему на указанном отрезке времени в Windows Server 2008 включено обновление OCSP Signing сертификатов с использованием существующих ключей. По умолчанию оно не включено, поэтому для активации такого обновления в командной строке следует выполнить:

certutil –setreg ca\UseDefinedCACertInRequest 1

После выполнения этой команды должно получиться нечто похожее на:

C:\Users\administrator>certutil -setreg ca\UseDefinedCACertInRequest 1
SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\contoso-DC2-CA\UseDefine
dCACertInRequest:

New Value:
  UseDefinedCACertInRequest REG_DWORD = 1
CertUtil: -setreg command completed successfully.
The CertSvc service may need to be restarted for changes to take effect.

Как гласит сообщение, после этой процедуры следует перезапустить службу AD CS:

net stop certsvc
net start certsvc

На сегодня, пожалуй, всё, а в следующий раз продолжим с конфигурированием Online Responder и политики отзыва сертификатов.

Update 04.09.2009: относительно пункта 3 данного поста обязательно прочтите обновление информации по нему: Секреты Software Restriction Policies (часть 3) (так же прочитать пункт 3). Т.е. вы должны исключить LNK файлы из проверки политикой и, следовательно, исключения для них создавать не надо.

Так же прочтите обновление по этой же ссылки относительно использования переменных окружения в правилах SRP.

Наблюдая за сообщениями на форумах (а так же по комментариям в моём блоге) пришёл к выводу, что очень немногие понимают всю значимость Software Restriction Policies и далеко не каждый обладает навыками эффективного управления данной политикой. Я уже освещал некоторые вопросы по данной теме, но тем не менее пробелы до сих пор есть, а так же есть новые трюки для обхода политики.

Итак, для тех, кто ещё не в курсе, о чём идёт речь предлагается прочитать:

• На страже безопасности – Software Restriction Policies
• Секреты Software Restriction Policies

В данном посте я планирую раскрыть секреты расширения SCF, трюки с hh.exe, рассмотреть вопросы унификации правил и два важных момента в управлении политикой.

1) Расширение SCF – это командный файл, который обрабатывается стандартным шеллом (он же explorer.exe). Данные файлы достаточно хитры, поскольку проводник (explorer) даже в режиме показа известных расширений никогда не показывает его. Это ещё пол беды. Основная угроза, которая может от них исходить – встраиваемость в файлы. В двух словах это выглядит как прописывание своего кода в любой файл (будь то текстовый, графический, медиафайл и т.д.), подмена расширения и иконки. Синтаксис SCF файлов очень похож на синтаксис INI и INF файлов. Т.е. он состоит из секций, заключённых в квадратные скобки и элементы секций:

[section]
parameter=value
[section2]
parameter2=value2
parameter3=value3

Самый знакомый нам файл такого типа – Show Desktop в панели quick launch. Это самый настоящий SCF файл, который имеет следующее содержание:

[shell]
Command=2
IconFile=explorer.exe,3
[TaskBar]
Command=ToggleDesktop

как видно отсюда, мы можем изменять иконку файла на любую. Очень полезно для маскировки файла под другой тип файла. И в секции TaskBar мы видим вызов внутренней команды explorer.exe – ToggleDesktop. Напомню, что эти файлы обрабатываются только оболочкой explorer.exe. Если сохранить эту часть в текстовом файле и указать расширение SCF, то вы получите сворачивалку окон. Если, к примеру, в секции Command указать другую команду, например, Explorer, то при двойном клике на него запустится сам explorer.exe:

[shell]
Command=2
IconFile=explorer.exe,3
[TaskBar]
Command=Explorer

А теперь как встраивать код в другие файлы. Берём любой произвольный файл, например картинку в формате JPEG, открываем его в текстовом редакторе, но лушче будет в FAR и в самое начало или самый конец файла пишем:

[shell]
Command=2
IconFile=imageres.dll,66
[TaskBar]
Command=Explorer

сохраняем изменения и переименовываем файл в image.jpeg.scf.В Windows Vista/Windows Server 2008 мы получим файл размером с картинку, подходящее расширение и значок JPEG файла (хвост .scf будет скрыт от нас в любом случае). Если по нему нажать 2 раза, то запустится explorer. Причём никаких ошибок вы не получите, потому что остальное содержимое файла будет проигнорировано и будет выполнена только та часть кода, которую мы добавили. Искать иконки можно различными редакторами ресурсов, как Restorator или ResHacker. Просто в категории Icon или IconGroup выбираете нужный номер иконки и вставляете этот номер в параметр значка. При этом скорее всего потребуется уменьшить это число на единицу, поскольку Explorer будет считать значки с нуля, в то время как редакторы ресурсов считают с единицы. Но это уже детали.

К сожалению я в данный момент не обладаю сведениями о полном функционале файлов SCF, но доподлинно известно, что ими можно манипулировать как оболочкой explorer.exe, так и браузером Internet Explorer. Поэтому я пока не могу сказать на сколько это может быть опасно. Но неадекватное поведение файла при его запуске может доставить массу хлопот как самим пользователям, так и администраторам.

Следовательно имеет смысл при развёртывании политики SRP включить данное расширение в список блокируемых, а значок Show Desktop.scf разрешить по хэшу! Это важно, поскольку разрешение пути позволит пользователю модифицировать файл и исполнить его.

Примечание: в новых версиях Windows начиная от Windows Vista значок ShowDesktop.scf был сменён с SCF файла на Show Desktop.lnk, следовательно для этих версий ОС достаточно будет просто включить данное расширение в список и всё. Хотя SCF файл в Windows Vista будет работать :)

2)hh.exe – исполняемый файл, который обрабатывает фалы справки CHM. CHM – это скомпилированный HTML файл, следовательно может содержать потенциально уязвимый код. Но тут, казалось бы, бояться нечего, поскольку расширение CHM по умолчанию мониторится политикой SRP и его запуск из пользовательского окружения недоступен. Но это не совсем так. В действительности пользователь может обойти ограничение SRP и спокойно запускать любые CHM файлы. Обходится данное ограничение очень просто:

Start –> Run… –> hh.exe path\helpfile.chm

и всё. К сожалению, я не нашёл метода, как гибко бороться с этим, только явно запрещать политикой SRP запуск программы hh.exe. Ещё к бОльшему сожалению блокировать CHM файлы в системах до Windows Vista тяжело, поскольку почти вся справка Windows там написана в CHM. Однако, в Windows Vista и выше встроенная справка уже не базируется на CHM файлах, поэтому в них мы можем со значительно меньшими последствиями просто блокировать hh.exe. Но тут можно упереться в вопрос совместимости сторонних приложений, которые зачастую содержат справку в CHM файлах. Поэтому, я не призываю блокировать hh.exe, но просто исследовать данный вопрос в каждом индивидуальном случае отдельно.

Примечание: на данный момент мне неизвестно о других расширениях, которые подвержены данной проблемы. Я тестировал набор расширений, но добиться подобного результата не удалось. Хочется надеяться, что это единственное такое хитрое расширение :)

3) унификация и стандартизация создания исключений в политику SRP. Прочитав топик на форуме TechNet – сслыка, я в очередной раз пришёл к мнению, что человек первый раз столкнувшись с SRP не обладает навыками эффективного создания исключений. Это и не удивительно вобщем, поэтому я в темах про SRP ставлю перед собой задачу – рассказать про Best Practices для эффективной реализации этой политики.

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

Политика SRP даёт нам широкие возможности для этого, это и использование системных переменных окружений %variable%, но и чтение этих переменных из реестра. Повторюсь, что данная концепция решает несколько задач, как унификация правил для различных платформ и обход локализованных барьеров. В качестве примеров можно привести различия некоторых стандартных путей в ОС Windows XP и Windows Vista.

• Например, профили пользователей раньше хранились в C:\Documents and Settings, а в Vista – C:\Users. Уже здесь мы видим эффект от использования системных переменных окружения как %userprofile%.
• Но если в сети используются и локализованные системы (смешанные), то системные переменные доставят нам хлопот, поскольку придётся часто дублировать исключения пути: %userprofile%\Desktop\*.lnk и %userprofile\Рабочий стол\*.lnk. Это так же существенный барьер, который обойти стандартными переменными окружения практически нерентабельным. И вот здесь мы видим эффект от чтения нужных путей из реестра.

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

• пользователи могут запускать исполняемые файлы из системной папки Windows и Program Files
• пользователи могут запускать ярлыки из своего пользовательского Start Menu
• пользователи могут запускать ярлыки из Start Menu общего профиля, который известен как AllUsersProfile
• пользователи могут запускать ярлыки со своего и AllUsers рабочего стола
• пользователи могут запускать ярлыки из своего меню быстрого запуска (Quick Launch)
• пользователи не могут запускать исполняемые файлы из папки спулера и системного Temp.

И вот такой список исключений нам потребуется:

Unrestricted - %systemroot%
Unrestricted - %programfiles%
Unrestricted - %userprofile%\Application Data\Microsoft\Internet Explorer\Quick Launch\*.lnk – (Windows XP/2003 only)
Unrestricted - %HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders\AppData%/Microsoft/Internet Explorer/Quick Launch/*.lnk – (Windows Vista/2008 или выше)
Unrestricted - %HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders\Desktop%*.lnk
Unrestricted - %HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders\Programs%*.lnk
Unrestricted - %HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders\Programs%*/*.lnk
Unrestricted - %HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders\Programs%*/*/*.lnk
Unrestricted - %HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders\Common Administrative Tools%*.lnk
Unrestricted - %HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders\Common Desktop%*.lnk
Unrestricted - %HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders\Common Programs%*.lnk
Unrestricted - %HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders\Common Programs%*/*.lnk
Unrestricted - %HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders\Common Programs%*/*/*.lnk
Dissalowed - %HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Print\Printers%
Dissalowed - %systemroot%\Temp

Здесь хочу сделать несколько комментариев:

• Мы явно запрещаем запуск недозволенных приложений из системных папок, куда пользователи по умолчанию имеют право записи и исполнения. Это C:\Windows\Temp и папка спулера, поскольку они явно разрешаются первым правилом. Следовательно, чтобы предотвратить запуск файлов из этих папок мы явно их запрещаем отдельными правилами.
• я указал 2 пути для QuickLaunch для систем Windows XP и Windows Vista. Это обусловленно тем, что в Windows XP/Windows Server 2003 максимальная длина исключения для пути ограничена 133 знаками и вот такой “финт ушами”, который я привёл для Windows Vista, не проходит. В новых ОС этот недостаток устранён.
• здесь я не привёл явного запрещения для hh.exe, т.к. это стартовый набор правил, которое обеспечивает достаточную совместимость с другими приложениями.
• Мы разрешаем несколько уровней вложения для Start Menu, поскольку всё это меню как правило состоит из 3-х уровней вложения.

Примечание: для бизнес-приложений, которые как правило инсталлируются на отличный от системного том (обычно D:\) и для них рекомендуется делать исключения по хешу, нежели по пути. Это полезно по двум причинам:

• зачастую бизнес-приложения пишутся “быдлокодерами” (простите уж за такую лексику, но это суровая правда), которые требуют разрешения записи пользователям в папку с исполняемым модулем. Спастись от заражения этого модуля пользователями можно только хешем. Это, к сожалению, актуальная проблема, которую нужно решать примерно так: “разработчиков софта, требующего админских привилегий, нужно силой пересаживать на OpenBSD, и не кормить дошираком до тех пор, пока их г***ософт не начнет там работать в ANSi-режиме на библиотеке ncurses” © Amin
• в случае, если случится факт заражения (в данном случае только от лица неосторожного администратора), то высока вероятность, что вирус постарается инфицировать все .exe файлы в системе и по изменившемуся хешу это можно быстро вычислить (приложение больше не запустится) и в кратчайшие сроки вывести поражённую систему из сети для дальнейшего расследования инцидента.

4) обновление ярлыков временного отключения и включения SRP. Я считаю удобным держать на рабочем столе администратора ярлыки, которые запускают REG файлы, которые в свою очередь временно отключают и возвращают политику в исходную позицию. Если для одной рабочей станции – это менее критично, то в условиях домена отключать политику для установки/обновления ПО на уровне GPO – крайне нецелесообразно. Я уже публиковал в своём предыдущем блоге тексты REG файлов, но без учёта папки Temp.

Т.к. мы явно запретили запуск недозволенных расширений из папки C:\Windows\Temp, то даже временная деактивация политики ярлыками не позволит нам сделать некоторые действия, например, установка драйвера или приложения, если установщик сперва распаковывает INF файлы в эту папку, поскольку перевод глобального режима политики в Unrestricted не отменит этот явный запрет. Следовательно мы помимо перевода политики в Unrestricted должны вывести администраторов из под действия политики. Вот REG файлы для временного отключения и включения политики:

SRP_Disable.reg

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Safer\CodeIdentifiers]
"DefaultLevel"=dword:00040000
"PolicyScope"=dword:00000001

SRP_Enable.reg

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Safer\CodeIdentifiers]
"DefaultLevel"=dword:00000000
"PolicyScope"=dword:00000000

5) обновление политики. В процессе работы с ярлыками обнаружился один неприятный факт: если отключить политику реестром и не включить обратно, то после перезагрузки машины кроме включения политики реестром обратно потребуется выполнить ещё 2 перезагрузки. Как вы, наверное, поняли, эти ключи реестра не изменяют саму политику, а только её поведение. Следовательно пришлось решать вопрос возвращения политики в исходное состояние при перезагрузках при помощи групповых политик. По умолчанию, политики перезаписывают соответствующие ключи реестра только при изменение состояния политики (чего мы ярылками не делаем). Т.к. SRP у нас основывается на реестре (все её правила и настройки хранятся именно в реестре), то нужно задать принудительное переприменение политики при перезагрузках (или периодических обновлений политики в домене). Делается это в Group Policy:

Computer Configuration\Administrative Templates\System\Group Policy\Registry policy processing

и этот элемент необходимо выставить в Enabled внутри поставить галочку в Process even if the Group Policy objects have not changed. В таком случае даже если администратор забудет реестром обратно включить политику SRP, то политика процессинга сама вернёт её в исходное состояние – Disallowed.

-------------------

Сегодня мы рассмотрели очередную партию насущных вопросов по настройке и управлению политикой Software Restriction Policies. Я недеюсь, что этот материал будет полезен как начинающим (тех, кто только начинает работать с политикой SRP) и опытным администраторам, которые уже используют политики SRP в своих сетях.

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

Чтобы поместить свой элемент в контекстное меню при нажатии на PS1 файлы (на других типах файлов его не будет) нам нужно добавить некоторые значения в реестр по пути:

HKLM\Software\Classes\Microsoft.PowerShellScript.1\Shell

подключ с названием нашего элемента – Sign It и в нём уже команду, которая будет отрабатываться при нажатии на него. Я решил не изобретать велосипед и воспользовался приёмами, которые использовал ещё в старом блоге: Полезная безделушка Hash SHA1 на PowerShell. Шапка по сути осталась та же, только тело (исполняемый модуль) изменился. И вот, что получилось для PowerShell 1.0 (для V2 опубликую ниже):

#####################################################################
# Sign PS1 Script.ps1
# Version 1.5
#
# Automatically sign PowerShell script from .PS1 file context menu
# Fully compatible with PowerShell 1.0
#
# Vadims Podans (c) 2009
# http://www.sysadmins.lv/
#####################################################################

$FilePath = Read-Host "Specify path to hold SignIt.PS1"
if (Test-Path $FilePath) {
    $FilePath = $FilePath + "\" + "SignIt.ps1"
    $RegPath = "Registry::HKLM\Software\Classes\Microsoft.PowerShellScript.1\Shell\Sign It\command"
    $RegValue = "C:\WINDOWS\system32\WindowsPowerShell\v1.0\powershell.exe -noninteractive -noprofile -command $FilePath '%1'"
    New-Item -Path $RegPath -Force -ErrorAction SilentlyContinue
    if (Test-Path $RegPath) {
        New-ItemProperty -Path $RegPath -Name "(Default)" -Value $RegValue
        New-Item -ItemType file -Path $FilePath -Force
        if (Test-Path $FilePath) {
            $exefile = 'param ($file)
$cp = new-object Microsoft.CSharp.CSharpCodeProvider
$cpar = New-Object System.CodeDom.Compiler.CompilerParameters
$HideWindow = 0x0080
$ShowWindow = 0x0040
$Code = @"
using System;
using System.Runtime.InteropServices;
namespace Win32API
{
    public class Window
    {
        [DllImport("user32.dll")]
        public static extern bool SetWindowPos(IntPtr hWnd, IntPtr hWndInsertAfter, int x, int y, int cx, int cy, uint uFlags);
    }
}
"@
$cp.CompileAssemblyFromSource($cpar, $code)
$PSHandle = (Get-Process –id $pid).MainWindowHandle
[Win32API.Window]::SetWindowPos($PSHandle, 0, 0, 0, 0, 0, $HideWindow)
function _msgbox_ ($title, $text, $type = "None") {
    [void][reflection.assembly]::LoadWithPartialName("System.Windows.Forms")
    $msg = [Windows.Forms.MessageBox]::Show($text, $title, [Windows.Forms.MessageBoxButtons]::ok, 
    [Windows.Forms.MessageBoxIcon]::$type)
}
$cert = @(dir cert:\currentuser\my -codesigning)[0]
if (!$cert) {
    _msgbox_ -title "Error" -text "Here is no valid signing certificate!" -type "Error"
    exit
}
$status = Set-AuthenticodeSignature "$file" $cert -TimestampServer "http://timestamp.verisign.com/scripts/timstamp.dll"
if ($status.status -eq "Valid") {
    _msgbox_ -title "Success" -text "Script is now signed! Enjoy!"
} else {
    _msgbox_ -title "Error" -text $status.StatusMessage -type "Error"
}
exit'
            Set-Content -Path $FilePath -Value $exefile
            &$filepath $filepath
        }
        else {
            Write-Warning "Unable to create file in: $FilePath. Path is incorrect or you haven't sufficient permissions"
        }
    }
    else {
        Write-Warning "Unable to create registry key. May be you haven't sufficient permissions to HKLM hive"
    }
}

Данный скрипт является установщиком. Для реализации всех функций достаточно запустить этот скрипт и по требованию указать путь, где будет находиться рабочий скрипт (содержимое переменной $exefile).

Примечание: такой метод установки справедлив только для V2. При использовании PowerShell 1.0 установщик следует запускать непосредственно из консоли PowerShell.

Заметка: Здесь следует обратить внимание на блок кода, который идёт после PARAM в переменной $exefile. Данный блок кода скрывает саму консоль PowerShell и показывает только графическую часть, которая исполняется из скрипта. Функция скрытия консоли честно взята из блога Васи Гусева: Win32 API из PowerShell 1.0. Данный метод работает как в PowerShell V2 CTP3, так и в PowerShell 1.0.

И вариант скрипта для PowerShell V2:

#####################################################################
# Sign PS1 Script.ps1
# Version 1.5
#
# Automatically sign PowerShell script from .PS1 file context menu
#
# Require PowerShell V2, not compatible with PowerShell 1.0
#
# Vadims Podans (c) 2009
# http://www.sysadmins.lv/
#####################################################################
#requires -Version 2.0

$FilePath = Read-Host "Specify path to hold SignIt.PS1"
if (Test-Path $FilePath) {
    $FilePath = $FilePath + "\" + "SignIt.ps1"
    $RegPath = "Registry::HKLM\Software\Classes\Microsoft.PowerShellScript.1\Shell\Sign It\command"
    $RegValue = "C:\WINDOWS\system32\WindowsPowerShell\v1.0\powershell.exe -WindowStyle Hidden -noprofile -command $FilePath '%1'"
    New-Item -Path $RegPath -Force -ErrorAction SilentlyContinue
    if (Test-Path $RegPath) {
        New-ItemProperty -Path $RegPath -Name "(Default)" -Value $RegValue
        New-Item -ItemType file -Path $FilePath -Force
        if (Test-Path $FilePath) {
            $exefile = 'param ($file)
function _msgbox_ ($title, $text, $type = "None") {
    [void][reflection.assembly]::LoadWithPartialName("System.Windows.Forms")
    $msg = [Windows.Forms.MessageBox]::Show($text, $title, [Windows.Forms.MessageBoxButtons]::ok,
    [Windows.Forms.MessageBoxIcon]::$type)
}
$cert = @(dir cert:\currentuser\my -codesigning)[0]
if (!$cert) {
    _msgbox_ -title "Error" -text "Here is no valid signing certificate!" -type "Error"
    exit
}
$status = Set-AuthenticodeSignature "$file" $cert -TimestampServer "http://timestamp.verisign.com/scripts/timstamp.dll"
if ($status.status -eq "Valid") {
    _msgbox_ -title "Success" -text "Script is now signed! Enjoy!"
} else {
    _msgbox_ -title "Error" -text $status.StatusMessage -type "Error"
}
exit'
            Set-Content -Path $FilePath -Value $exefile
            &$filepath $filepath
        }
        else {
            Write-Warning "Unable to create file in: $FilePath. Path is incorrect or you haven't sufficient permissions"
        }
    }
    else {
        Write-Warning "Unable to create registry key. May be you haven't sufficient permissions to HKLM hive"
    }
}

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

И если у пользователя есть сертификат для подписи скриптов, то при нажатии на этот элемент получите сообщение:

В противном случае получите ошибку:

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

$cert = @(dir cert:\currentuser\my -codesigning)[0]
dir -Include *.ps1 -Recurse | %{Set-AuthenticodeSignature "$_" $cert}

На этом пока о подписывании скриптов всё, что я хотел рассказать.

Update 30.08.2009: немного переделал скрипты с учётом следующих поправок:

• Добавлена возможность подписывания скриптов с использованием сервера времени VeriSign, который в подписи ставит подписанную VeriSign' ом цифровую метку времени.
• Исправлены ошибки с выводом сообщений о результате операции. Например, если пользователь отменял операцию подписи, либо происходила другая ошибка в процессе подписывания, то появлялось сообщение о том, что файл подписан (хотя это было не так). Сейчас сделана проверка поля Status.
• в связи с этим изменил код в посте на обновлённый.

И, собственно, кнопки для скачивания скриптов:

• для PowerShell 1.0

• для PowerShell 2.0

Как известно практически всем пользователям PowerShell, в целях безопасности была введена политика запуска скриптов. Которая имеет 4 режима:

• Restricted – запрещено исполнять любые скрипты, возможна работа только в интерактивной консоли
• AllSigned – все скрипты должны быть криптографически подписаны
• RemoteSigned – только полученные из недоверенных источников (например, интернет) скрипты должны быть подписаны
• Unrestricted – наименее безопасный уровень, допускается исполнение любых скриптов

В версии V2 (пока ещё CTP3) скрипты PowerShell приравняли к исполняемым файлам и эти файлы стали неотключаемо мониториться политикой Software Restriction Policies. Я об этом уже писал ранее: PowerShell V2 и Software Restriction Policies. Поначалу меня это сильно напрягало, но после пришёл к мнению, что это правильно. Неправильно только то, что мы этого не видим (ps1 расширение нигде не фигурирует). С этим бороться можно двумя методами – явно указывать пути, откуда разрешён запуск .ps1 файлов или подписать их все.

Если компьютеров в сети больше одного, то самое идеальное для решения задачи будет наличие домена Active Directory и, по возможности, Enterprise Certification Authity (CA). Наличие домена решит массу задач, как распространение политики SRP в пределах домена, распространение сертификата в пределах домена, контроль версии сертификата, которым подписаны скрипты.

Итак, для начала нам нужно получить сертификат, которым будут подписываться скрипты. В целях безопасности следует создать ограниченную учётную запись пользователя из под которой администратор (в большинстве случаев) будет подписывать скрипты. В книге PowerShell In Action для генерации сертификата предлагается использовать makecert.exe, который входит в состав Visual Studio SDK, но как мне кажется более правильным будет использование CA. В Windows Server CA для этих целей есть уже готовый шаблон, который называется Code Signing. Но принципиальной разницы нету, каким инструментом вы будете генерировать сертификат и я опишу процесс получения сертификата с использованием доменного CA.

Если CA у нас уже установлен, то открываем оснастку Certification Authority и переходим в раздел Certificate Templates. Нажимаем правой кнопкой и выбираем Manage. Откроется редактор шаблонов. Если у вас Enterprise или Datacenter редакции Windows Server, то вы можете создать свой настроенный шаблон. Но я не вижу в этом необходимости. На данном этапе нам необходимо разрешить ограниченному пользователю запрашивать сертификаты этого шаблона. Для этого в закладке Security шаблона Code Signing нужно разрешить чтение и запрос сертификата ограниченному пользователю. Когда эта процедура проделана, редактор шаблонов можно закрыть. После чего в оснастке Certification Authority снова нажать правой кнопкой на разделе Certificate Templates –> New –> Certificate Template to Issue и в списке выбрать шаблон Code Signing.

После чего нужно залогиниться этим пользователем, запустить оснастку Certificate Manager (Start –> Run… –> certmgr.msc) и выполнить запрос сертификата. В списке шаблонов должен быть и добавленный нами Code Signing. Когда сертификат будет запрошен не надо закрывать оснастку сертификатов. Далее нам потребуется экспортировать открытую часть сертификата в x509 файл (с расширением .cer). Экспорт открытой части нам потребуется для проверки подписи и организации доверия подписи в пределах домена. Экспортированный сертификат необходимо теперь доставить администратору(-ам), который отвечает за групповую политику.

В групповых политиках (чаще всего в доменной политике) необходимо создать новую политику Software Restriction Policies и в Additiona Rules добавить правило сертификата (Certificate Rule) и указать экспортированный сертификат. Это необходимо затем, что PowerShell для проверки доверия сертификата ищет его в контейнере Trusted Publishers и только Software Restriction Policies позволяет централизовано распространять сертификаты в этот контейнер.

Теперь можно приступать к подписыванию скриптов. Для этих целей используется командлет Set-AuthenticodeSignature и синтаксис его такой:

Set-AuthenticodeSignature $file $cert

Где $file – путь к скрипту и $cert – объект сертификата, который получается следующим образом:

$cert = @(dir cert:\CurrentUser\My -codesigning)[0]

здесь мы явно указываем, что нам нужен сертификат, у которого в EKU (Enchanced Key Usage) указан Code Sgining. В нашем случае он будет всего 1. Но если их окажется несколько, то мы выберем самый первый. Вот как это будет выглядеть на практике:

[Desktop] Set-ExecutionPolicy allsigned
[Desktop] Get-ExecutionPolicy
AllSigned
[Desktop] .\uptime.ps1
File C:\Documents and Settings\Signer\Desktop\uptime.ps1 cannot be loaded. The file C:\Documents and Settings\Signer
\Desktop\uptime.ps1 is not digitally signed. The script will not execute on the system. Please see "get-help
 about_signing" for more details..
At line:1 char:13
+ .\uptime.ps1 < +="" categoryinfo="" :="" notspecified:="" (:)="" [],="" pssecurityexception="" +="" fullyqualifiederrorid="" :="">

[Desktop] $cert = @(dir cert:\currentuser\my -codesigning)[0]
[Desktop] $cert


    Directory: Microsoft.PowerShell.Security\Certificate::currentuser\my


Thumbprint                                Subject
----------                                -------
42E5B32A19885C6ADCF9683BDA1C871E0FE5E0DB  CN=Signer, CN=Users, DC=contoso, DC=com


[Desktop] Set-AuthenticodeSignature uptime.ps1 $cert


    Directory: C:\Documents and Settings\Signer\Desktop


SignerCertificate                         Status                                 Path
-----------------                         ------                                 ----
42E5B32A19885C6ADCF9683BDA1C871E0FE5E0DB  Valid                                  uptime.ps1


[Desktop] .\uptime.ps1
System Uptime for DC1 is:  1 days 4 hours 19 minutes 20 seconds
[Desktop]

Я наглядно показал, как это работает. Мы сначала перевели политику исполнения скриптов в AllSigned и убедились, что неподписанный скрипт не исполняется. После чего я подписал этот скрипт и попробовал снова. Как видите, скрипт теперь исполнился.

Если не будет выполнено условие распространения сертификата посредством политики SRP в контейнер Trusted Publishers, то вы получите вот такое сообщение:

[Desktop] .\uptime.ps1

Do you want to run software from this untrusted publisher?
File C:\Documents and Settings\Signer\Desktop\uptime.ps1 is
published by CN=Signer, CN=Users, DC=contoso, DC=com and is not trusted
on your system. Only run scripts from trusted publishers.
[V] Never run  [D] Do not run  [R] Run once  [A] Always run  [?] Help
(default is "D"):d
File C:\Documents and Settings\Signer\Desktop\uptime.ps1 cannot be loaded because you have elected to no
t run this software now.
At line:1 char:12
+ .\uptime.ps1 
[Desktop]

Вот таким образом мы решаем задачу исполнения только проверенного набора скриптов. В этом смысле PowerShell 1.0 менее безопасный и удобный, поскольку мы не можем политикой SRP блокировать исполнение PS1 файлов как класс и имеем только один выход – принудительное подписывание скриптов. В версии V2 политика исполнения скриптов удобно интегрируется с SRP. Удобство интегрирования в том, что SRP помимо распространения сертификата в пределах домена так же на основе этого правила разрешает исполнять эти скрипты в обход общего ограничения на PS1 файлы.

В следующем посте я расскажу, как можно упростить процесс подписывания скриптов. Так что не отключаемся :-)

Как моим читателям известно я недавно репортил баг на connect (подробности здесь - Первые впечатления от PowerShell V2 CTP3) и сегодня получил ответ следующего содержания (если кто-то не может туда попасть):

Software restriction policies intentionally apply to PowerShell scripts now in V2
Posted by Microsoft on 2009.01.05. at 10:49

следовательно это теперь не баг, а фича. Фича by design. Ещё раз ссылка на connect:

https://connect.microsoft.com/feedback/ViewFeedback.aspx?FeedbackID=389878&SiteID=99

И в моём предыдущем посте по этой проблеме временный workaround следует считать постоянным. Я сильно надеюсь, что к релизу подготовят документацию по этому вопросу. И мне до сих пор не ясно, будут ли сделаны какие-то изменения в самой политике SRP (ведь блокируемого расширения .ps1 в списке политики SRP нету). Я считаю, что они должны произведены, чтобы не было никаких неизвестностей при настройке политики. Как это будет реализовано - время покажет. Но для тех, кто планирует использовать PowerShell V2 и Software Restriction Policies будет полезно это знать. Неприятно, конечно же, но что поделать.