Windows Script Host для Windows 2000/XP
Глава 4. Безопасность при работе со сценариями WSH
Одним из главных преимуществ WSH является возможность запуска программ-сценариев, которые хранятся в виде исходного текста, что максимально упрощает процессы написания и распространения программ — не нужны ни дополнительные компиляторы для создания исполняемого кода, ни специальные утилиты для установки и регистрации сценариев в операционной системе. Однако при использовании таких сценариев в силу той же простоты сразу возникает несколько проблем.
Во-первых, исходный код сценария является незащищенным — любой пользователь, запускающий сценарий, может модифицировать его и использовать в дальнейшем как свой собственный (нарушаются авторские права автора).
Во-вторых, простота распространения и выполнения сценариев открывает широкие возможности для написания вредоносных сценариев-вирусов, которые могут, например, рассылаться по электронной почте, как широко известный вирус "I Love You".
Поэтому при использовании сценариев WSH вопросы безопасности имеют весьма большое значение. В этой главе описано, каким образом можно создавать зашифрованные файлы сценариев и добавлять к сценариям цифровые подписи для указания автора сценария. Кроме этого, рассмотрен процесс организации политик безопасности для сценариев WSH, позволяющих, например, запретить выполнение неподписанных сценариев любого типа или вообще заблокировать WSH для определенных пользователей.
Шифрование сценариев
Начиная с версии 2.0, в WSH появилась возможность скрыть от пользователя исходный текст сценария, преобразовав (зашифровав) его с помощью программы Microsoft Script Encoder, которую можно свободно скачать по адресу
http://msdn.microsoft.com/scripting/vbscript/download/x86/sce10en.exe.
Программа Script Encoder может применяться для шифрования сценариев JScript (файлы *.js), VBScript (файлы *.vbs) и WS-файлов (расширение wsf), а также сценариев, содержащихся в гипертекстовых файлах HTML.
!
Шифрование с помощью Script Encoder не следует рассматривать как
надежное средство сохранения в тайне исходного кода сценария — программа
просто преобразует текст сценария в кодировку, непригодную для чтения, и
профессионал сможет из него восстановить первоначальное содержимое. Однако для
защиты сценария от изменений обычными пользователями подобного шифрования
вполне достаточно.
Для запуска программы Script Encoder служит файл screnc.exe; по умолчанию установка исполняемого файла и файла помощи производится в каталог Program Files\Windows Script Encoder. Программа srcenc.exe запускается из командной строки, в качестве ее обязательных параметров указываются имена исходного файла сценария и файла, в котором будет содержаться этот сценарий в зашифрованном виде.
!
В системе зарегистрированы специальные расширения для файлов с
зашифрованными сценариями WSH: jse для сценариев JScript и vbe для сценариев
VBScript
Рассмотрим пример. Пусть в файле ForEncode.js находится простой JScript-сценарий (листинг 4.1).
►Листинг 4.1. Исходный текст сценария ForEncode.js
/*******************************************************************/
/* Имя: ForEncode.js */
/* Язык: JScript */
/* Описание: Исходный текст сценария */
/*******************************************************************/
WScript.Echo("Привет!");
/************* Конец *********************************************/
Тогда после выполнения команды
sсrenс ForEncode.js Encoded.jse
создастся файл Encoded.jse, содержащий зашифрованный текст сценария ForEncode.js (листинг 4.2).
►Листинг 4.2. Зашифрованный сценарий Еncoded.jse
#@~^0QEAAA==&CeMCeCeeCeCMeCeMeCeMMCeeCMeCeeCMMeCeCeMeMMCeMeCMeCeMMCeeMMCeMeCMCeMJ@#@&ze,Имя),oWM2UmKNn N/P,~P,PP,~~P,P,P~P~~,P~P,~P,P~~,PP~~,P~P,~,P~,P,ez@#@&JMPЯзык=PB?1Dr2DPP,~P,PP,~~P,P,P~P~~,P~P,~P,P~~,PP~~,P~P,~,P~,P,PP,eJ@#@&Je~Описание),ИсходныйPтекстсценария~,PP,~P,PP,~~P,P,P~P~~,P~P,~P,PM&@#@&zMMCeMeCMCeMCeCeeCeCMeCeMeCeMMCeeCMeCeeCMMeCeCeMeMMCeMeCMeCeMMCeeMMCz@#@&qj1DraYc2m4WvEПривет1"r#I@#@&zMMCeeCMeCeeCM~PКонец,eCeMeMMCeMeCMeCeMMCeeMMCeMeCMCeMCeCeeCeCMeCeMz@#@&KEIAAA==^#~@
Сценарии VBScript, записанные в файлах с расширением vbs, шифруются точно так же:
screnc ForEncode.vbs Encoded.vbe
Исходный сценарий ForEncode.vbs приведен в листинге 4.3, зашифрованный сценарий Encoded.vbe — в листинге 4.4.
►Листинг 4.3. Исходный текст сценария ForEncode.vbs
'*******************************************************************
' Имя: ForEncode.vbs
' Язык: VBScript
' Описание: Исходный текст сценария
'*******************************************************************
WScript.Echo "Привет!"
'************* Конец **********************************************
►Листинг 4.4. Зашифрованный сценарий Encoded.vbe
#@~^xQEAAA==vCeMCeCeeCeCMeCeMeCeMMCeeCMeCeeCMMeCeCeMeMMCeMeCMeCeMMCeeMMCeMeCMCeM@#@&EPИмя),sK.2 mGNR-8kPP,~P,PP,~~P,P,P~P~~,P~P,~P,P~~,PP~~,P~P,~,P~,@#@&BPЯзык=Pj$?1DrwDP~~,PP,~P,PP,~~P,P,P~P~~,P~P,~P,P~~,PP~~,P~P,~,P~,P@#@&B,Описание),Исходный~текстPсценария,P~P,P~~,PP,~P,PP,~~P,P,P~P~~,P@#@&EMeCeMMCeeMMCeMeCMCeMCeCeeCeCMeCeMeCeMMCeeCMeCeeCMMeCeCeMeMMCeMeCMeC@#@& UmDr2DR3m4G,JПриветZr@#@&BeCeCMeCeMeCeM~,КонецPeCMeCeeCMMeCeCeMeMMCeMeCMeCeMMCeeMMCeMeCMCeMCe@#@&PEAAAA==^#~@
Как видно из листингов 4.3 и 4.4, символы кириллицы остаются в зашифрованных сценариях без изменения.
Зашифрованные файлы Encoded.jse и Encoded.vbe можно запускать с помощью cscript.exe или wscript.exe, выполняться они будут точно так же, как и исходные сценарии (рис. 4.1).
Рис. 4.1. Результат выполнения зашифрованного сценария Encoded.jse
Еще одной весьма полезной особенностью сценариев, зашифрованных с помощью Script Encoder, является то, что при запуске такого сценария автоматически производится контроль целостности файла. Например, если в файле Encoded.jse убрать или добавить букву в слово "Привет", то при запуске будет выведено сообщение об ошибке (рис. 4.2) и сценарий выполняться не будет.
Рис. 4.2. Сообщение об ошибке, выводимое при запуске модифицированного файла Encoded.jse
Содержимое зашифрованных сценариев с расширениями jse и vbe можно вставлять в WS-файлы внутрь элементов <script>, при этом в качестве значения аргумента language должно быть указано "JScript.Encode" (зашифрованный сценарий на языке JScript) или "VBScript.Encode" (зашифрованный сценарий на языке VBScript). Пример такого WS-файла Encoded.wsf приведен в листинге 4.5, исходный файл ForEncode.wsf — в листинге 4.6.
►Листинг 4.5. Зашифрованный сценарий Encoded.wsf
<job id="Encoded">
<runtime>
<description>
Имя: Encoded.wsf
Описание: WS-файл с зашифрованными сценариями
</description>
</runtime>
<script language="VBScript.Encode">
#@~^FgAAAA== Um.bwDR21tK~JПриветeJ/gQAAA==^#~@
</script>
<script language="JScript.Encode">
#@~^FgAAAA== Um.bwDR21tKcJПокаeJbiagUAAA==^#~@
</script>
</job>
►Листинг 4.6. Исходный сценарий ForEncode.wsf
<job id="Encoded">
<runtime>
<description>
Имя: Encoded.wsf
Описание: WS-файл с зашифрованными сценариями
</description>
</runtime>
<script language="VBScript.Encode">
WScript.Echo "Привет!"
</script>
<script language="JScript.Encode">
WScript.Echo("Пока!");
</script>
</job>
Однако если попытаться зашифровать исходный файл ForEncode.wsf с помощью команды
screnc ForEncode.wsf Encoded.wsf
то возникнет ошибка, т.к. Script Encoder "не понимает" расширения wsf. Поэтому для шифрования WS-файлов нужно при вызове screnc.exe в командной строке использовать дополнительный ключ:
screnc /е htm ForEncode.wsf Encoded.wsf
Параметр /е htm здесь указывает на то, что исходный файл ForEncode.wsf является файлом с HTML-разметкой (расширение htm), при этом Script Encoder шифрует только содержимое элементов <script>, оставляя весь остальной текст файла без изменения.
Описание других ключей программы Script Encoder, которые могут применяться при шифровании сценариев WSH, приведено в табл. 4.1.
Таблица 4.1. Параметры командной строки screnc.exe
| Параметр |
Описание |
/s |
Подавляет все сообщения программы. Если этот
ключ не указан, то по умолчанию сообщения программы выводятся на
экран |
/f |
Перезаписывает исходный файл (зашифрованный файл
будет иметь то же самое имя, что и исходный сценарий) |
/l defLanguage |
Явно указывает язык сценария в шифруемом файле.
Например, /l Jscript |
Цифровая подпись для сценариев WSH
Сценарии WSH можно защищать с помощью цифровой подписи, используя которую, можно определить происхождение сценария и гарантировать его целостность, т.е. отсутствие в этом сценарии несанкционированных изменений. Если источник, из которого поступил этот сценарий, является надежным (trusted source), т.е. вы доверяете этому источнику, сценарий можно выполнить. В случае же ненадежности создателя или распространителя сценария можно (при соответствующей настройке политик безопасности Windows) отказаться от его запуска.
Таким образом, разработчик должен идентифицировать свои сценарии цифровой подписью, чтобы пользователи, получающие такие сценарии, знали, откуда они к ним попали и кто их создал. После добавления цифровой подписи к сценарию он может свободно запускаться (но не модифицироваться!) всеми, кто указал автора программы как надежного источника сценариев.
Цифровая подпись в Windows создается с помощью цифровых сертификатов, поэтому сначала кратко рассмотрим, каким образом можно получить цифровой сертификат и установить доверие к нему.
Использование цифровых сертификатов в Windows
Цифровой сертификат — это электронный документ, который однозначно идентифицирует его владельца. Сертификаты различных типов широко используются во многих службах безопасности Windows для разных целей, например:
• проверка подлинности пользователей Интернета или Web-сервера (пользователи должны иметь возможность доказать свою подлинность тем, с кем они соединяются в компьютерной сети, и должны иметь возможность проверить подлинность других пользователей);
• шифрование и защита от искажений данных, которые передаются по локальной сети или при помощи электронной почты (при обмене зашифрованными сообщениями электронной почты никто не сможет прочитать сообщение в процессе его доставки, а расшифровать и прочитать сообщение сможет только получатель, которому оно предназначено);
• подписание электронных писем (получатель сообщения может проверить, что сообщение не было изменено в процессе доставки и что сообщение пришло именно от отправителя);
□ проверка подлинности программного обеспечения, которое загружается из Интернета, устанавливается из локальной сети организации или с компакт-диска (неподписанное программное обеспечение, т.е. не имеющее действительного сертификата издателя, может представлять опасность для компьютера и сохраняемой на нем информации).
Способы получения цифрового сертификата
Различаются цифровые сертификаты трех типов: созданные разработчиком, выданные разработчику организацией и полученные от центра сертификации.
Цифровой сертификат, созданный разработчиком, обычно используют те пользователи, которые доверяют этому разработчику. Например, администратор локальной сети может создать свой собственный сертификат для подписи сценариев WSH, которые он создает и распространяет внутри своей организации.
В организации может быть организован свой сервер выдачи цифровых сертификатов (соответствующая служба имеется, например, в операционной системе Windows 2000 Server). Таким образом, организация распространяет сертификаты среди собственных разработчиков, не прибегая к услугам коммерческих центров сертификации.
В Интернете имеются сайты коммерческих центров сертификации, которые выдают сертификаты как организациям, так и частным лицам; одним из самых известных таких центров является VeriSign (http://www.verisign.com). Естественно, большинство услуг центров сертификации являются платными, причем цена на сертификат зависит от цели его приобретения (личный цифровой сертификат для индивидуального распространения программ стоит намного дешевле, чем сертификат для организаций, занимающихся разработкой и продажей программного обеспечения).
Понятно, что для того, чтобы попрактиковаться в применении сертификатов для подписания сценариев WSH, проще всего создать цифровой сертификат самостоятельно, поэтому в дальнейшем мы будем рассматривать только такие сертификаты.
Создание собственного сертификата
Наиболее быстрым способом создания собственного цифрового сертификата является использование программы SelfCert.exe, входящей в состав Microsoft Office 2000/ХР. Запустив эту утилиту, мы получим диалоговое окно, позволяющее задать имя создаваемого сертификата (рис. 4.3). В качестве этого имени можно использовать, например, свое имя или название организации.
Рис. 4.3. Создание нового личного сертификата с помощью SelfCert.exe
Рис. 4.4. Успешное создание личного сертификата "Попов надежный"
Для дальнейших экспериментов нам понадобится создать два сертификата с именами "Попов надежный" и "Попов ненадежный". После нажатия кнопки OK в случае успешного создания сертификата на экран выводится диалоговое окно с информацией об этом (рис. 4.4).
Управление сертификатами с помощью ММС
Для того чтобы посмотреть свойства созданных сертификатов, нам потребуется запустить консоль управления Microsoft Management Console (ММС) — инструмент для создания, сохранения и открытия средств администрирования (называемых консолями (Snap-in) ММС), которые управляют оборудованием, программными и сетевыми компонентами операционной системы Windows. Для того чтобы загрузить ММС, нужно выполнить команду mmc либо в командной строке, либо с помощью пункта Выполнить (Run) меню Пуск (Start). В результате на экране появится окно новой консоли (рис. 4.5).
Рис. 4.5. Новая консоль ММС
Теперь добавим в консоль оснастку Сертификаты (Certificates). Для этого нужно в меню Консоль (Console) выбрать пункт
Добавить/удалить оснастку (Add/Remove Snap-in), после чего появится диалоговое окно, показанное на рис. 4.6.
Рис. 4.6. Диалоговое окно добавления/удаления оснасток для консоли ММС
После нажатия кнопки Добавить (Add) выводится список всех имеющихся оснасток (рис. 4.7).
Из этого списка нужно выбрать Сертификаты (Certificates) и нажать кнопку Добавить (Add). После этого в новом диалоговом окне отмечаем, что добавляемая оснастка будет управлять сертификатами для своей учетной записи (рис. 4.8) и нажимаем кнопку Готово (Finish).
Никаких других оснасток в окно консоли мы добавлять не будем, поэтому нажимаем кнопку Закрыть (Close) в списке оснасток и кнопку
OK в окне добавления/удаления оснасток. Созданные нами сертификаты будут находиться в разделе Личные\Сертификаты (Personal\Sertificates) (рис. 4.9).
Выделив нужный сертификат в списке и нажав клавишу <Enter>, мы выведем окно с описанием свойств сертификата (рис. 4.10).
Рис. 4.7. Список всех оснасток
Рис. 4.8. Выбор типа сертификатов, которым будет управлять добавляемая оснастка Сертификаты
Рис. 4.9. Расположение личных сертификатов
Рис. 4.10. Свойства сертификата "Попов надежный"
Как мы видим, для обоих новых сертификатов не установлено доверие. Для того чтобы установить доверие к одному из сертификатов ("Попов надежный"), достаточно просто перетащить при помощи мыши этот сертификат в раздел Доверенные корневые центры сертификации | Сертификаты (Trusted Root Certification Authorities) (рис. 4.11).
!
Если при перетаскивании сертификата в новое место держать
нажатой клавишу <Ctrl>, то сертификат будет не перемещен, а
скопирован.
Рис. 4.11. Сертификаты, к которым установлено доверие
Свойства сертификата "Попов надежный" после установки доверия к нему показаны на рис. 4.12.
Выполним теперь экспорт в файл сертификата "Попов ненадежный" (это понадобится нам в дальнейшем при построении политики ограниченного использования программ). Для этого следует выделить нужный сертификат и выбрать в меню Действие | Все задачи (Action | All Tasks) пункт Экспорт (Export), после чего запустится мастер экспорта сертификатов, в котором нужно согласиться со всеми настройками, предлагаемыми по умолчанию, а в качестве имени экспортируемого файла указать "C:\Script\Попов.cer".
Рис. 4.12. Новые свойства сертификата "Попов надежный"
Добавление к сценарию цифровой подписи
Подписать файл со сценарием WSH можно двумя способами. Во-первых, можно использовать программу SignCode.exe, с помощью которой производится подпись любого исполняемого кода. Однако эта программа не является стандартной частью операционной системы Windows, ее нужно устанавливать отдельно. Поэтому далее мы будем рассматривать второй способ подписи сценариев — с помощью метода
SignFile объекта Scripting.Signer, который регистрируется в системе при установке WSH 5.6.
В листинге 4.7 приведен сценарий SignScript.wsf, с помощью которого мы будем подписывать файлы сценариев различных типов, используя личные сертификаты "Попов надежный" и "Попов ненадежный". При запуске этого сценария нужно указать два именных параметра командной строки: /file для задания пути к подписываемому файлу и /cert, содержащий название цифрового сертификата, на основе которого будет создаваться подпись. Эти параметры в сценарии подставляются в качестве аргументов метода
SignFile объекта Scripting.Signer:
//Создаем объект Scripting.Signer
Signer = WScript.CreateObject("Scripting.Signer");
File = WScript.Arguments.Named("file"); //Имя файла
Cert = WScript.Arguments.Named("cert"); //Название сертификата
Signer.SignFile(File, Cert); //Подписываем файл
!
В методе SignFile может быть указан третий
необязательный параметр, задающий путь к хранилищу сертификатов. В сценарии
SignScript.wsf этот параметр не используется, т.к. для создания подписи
применяются личные сертификаты, находящиеся на локальной машине.
►Листинг 4.7. Сценарий SignScript.wsf
<job>
<runtime>
<named name="file" helpstring="Путь к файлу сценария" required="true" type="string"/>
<named name="cert" helpstring="Имя цифрового сертификата" required="true" type="string"/>
<description>
Имя: SignScript.wsf
Описание: Добавление цифровой подписи к файлам
со сценариями WSH
</description>
<example>
Пример:
SignScript.wsf /file:Signed.wsf /cert:"Попов надежный"
</example>
</runtime>
<script language="JScript">
var Signer, File, Cert, Store;
if (!(WScript.Arguments.Named.Exists("cert") && WScript.Arguments.Named.Exists("file"))) {
WScript.Arguments.ShowUsage();
WScript.Quit();
}
Signer = WScript.CreateObject("Scripting.Signer");
File = WScript.Arguments.Named("file");
Cert = WScript.Arguments.Named("cert");
Store = "";
Signer.SignFile(File, Cert);
</script>
</job>
Цифровые подписи добавляются в конец файлов, содержащих сценарии, причем в обычных JScript- и VBScript-файлах подпись находится в блоке комментария, а в WS-файлах — внутри элемента <signature>. Это делает возможным запуск подписанных сценариев в предыдущих версиях WSH, т.к. здесь закомментированные или находящиеся внутри <signature> части сценариев будут при выполнении проигнорированы.
В листингах 4.8–4.10 приведены примеры сценариев различных типов, которые были подписаны с использованием сертификата "Попов надежный".
►Листинг 4.8. Подписанный JScript-файл
/*******************************************************************/
/* Имя: Signed.js */
/* Язык: JScript */
/* Описание: Сценарий с цифровой подписью */
/*******************************************************************/
WScript.Echo("Привет!");
// SIG // Begin signature block
// SIG // MIIEMAYJKoZIhvcNAQcCoIIEITCCBB0CAQExDjAMBggq
// SIG // hkiG9w0CBQUAMGYGCisGAQQBgjcCAQSgWDBWMDIGCisG
// SIG // AQQBgjcCAR4wJAIBAQQQEODJBs441BGiowAQS9NQkAIB
// SIG // AAIBAAIBAAIBAAIBADAgMAwGCCqGSIb3DQIFBQAEENmN
// SIG // vsHhmXojm79+NmBDE0qgggJIMIICRDCCAa2gAwIBAgIQ
// SIG // sGqcGTDiWZBINKde3DiDqDANBgkqhkiG9w0BAQQFADAn
// SIG // MSUwIwYDVQQDHhwEHwQ+BD8EPgQyACAEPQQwBDQENQQ2
// SIG // BD0ESwQ5MB4XDTAxMTIzMTIwMDAwMFoXDTA3MTIzMTIw
// SIG // MDAwMFowJzElMCMGA1UEAx4cBB8EPgQ/BD4EMgAgBD0E
// SIG // MAQ0BDUENgQ9BEsEOTCBnzANBgkqhkiG9w0BAQEFAAOB
// SIG // jQAwgYkCgYEAsNlPby/9ax7Ky75RO8xI+jrNU/u842T2
// SIG // 6Md730yxbVD9+54SVNtsCoYOR7OYgQMb9TtiirFpk0bJ
// SIG // PH7WuCjGlrMOhDt86Vq++er67d87p0rytm0R7m1/FOkw
// SIG // GxxjycUEKS2w65FXfdpngRKiu3NIDb6tsupKiHex3XEo
// SIG // 1n0O++kCAwEAAaNxMG8wEwYDVR0lBAwwCgYIKwYBBQUH
// SIG // AwMwWAYDVR0BBFEwT4AQ0LHfQjJYgcR4nBGbd2fwEKEp
// SIG // MCcxJTAjBgNVBAMeHAQfBD4EPwQ+BDIAIAQ9BDAENAQ1
// SIG // BDYEPQRLBDmCELBqnBkw4lmQSDSnXtw4g6gwDQYJKoZI
// SIG // hvcNAQEEBQADgYEAi0hytKDNpUwc8/MpidjPFaE3xu9g
// SIG // SSVXbietJ5kW7uJR1IXAA1CaEHDCe0JIxCdHhfKTcWrK
// SIG // Q4t0mG6fBFO180xKHcyOCpVuFywnkMI8AWKzqNYdaDUZ
// SIG // sNtaw4R4XjX9koovYmfFo4i75A9zd4qXB93AaWUJMEt7
// SIG // g+JQ2Blzn4gxggFSMIIBTgIBATA7MCcxJTAjBgNVBAMe
// SIG // HAQfBD4EPwQ+BDIAIAQ9BDAENAQ1BDYEPQRLBDkCELBq
// SIG // nBkw4lmQSDSnXtw4g6gwDAYIKoZIhvcNAgUFAKBsMBAG
// SIG // CisGAQQBgjcCAQwxAjAAMBkGCSqGSIb3DQEJAzEMBgor
// SIG // BgEEAYI3AgEEMBwGCisGAQQBgjcCAQsxDjAMBgorBgEE
// SIG // AYI3AgEVMB8GCSqGSIb3DQEJBDESBBB3QmVqnKzYLdaa
// SIG // EXTFBkJhMA0GCSqGSIb3DQEBAQUABIGAAMkO/8PM8+Ay
// SIG // zG8FeUtsDIUy56sSmYd9W34axmFbGktiseSshNxemfbv
// SIG // 7TucEbZ40zyMFdpaKDqwwCNf1M3k59eu4jk0wX1v1VBd
// SIG // +mwQ3JNg3WpvAL6OFrAko+ksiZ2ndjKJfJXwDUSITFmy
// SIG // aGrGNkC3RYRhp6dPdL8Tb0PVvcU=
// SIG // End signature block
►Листинг 4.9. Подписанный VBScript-файл
'*******************************************************************
' Имя: Signed.vbs
' Язык: VBScript
' Описание: Сценарий с цифровой подписью
'*******************************************************************
WScript.Echo "Привет!"
'************* Конец *********************************************
'' SIG '' Begin signature block
'' SIG '' MIIEMAYJKoZIhvcNAQcCoIIEITCCBB0CAQExDjAMBggq
'' SIG '' hkiG9w0CBQUAMGYGCisGAQQBgjcCAQSgWDBWMDIGCisG
'' SIG '' AQQBgjcCAR4wJAIBAQQQTvApFpkntU2P5azhDxfrqwIB
'' SIG '' AAIBAAIBAAIBAAIBADAgMAwGCCqGSIb3DQIFBQAEELv8
'' SIG '' ImJefHuyhVFY7TYWddigggJIMIICRDCCAa2gAwIBAgIQ
'' SIG '' 75BSQe/4a5lLJ/s5SPVp+zANBgkqhkiG9w0BAQQFADAn
'' SIG '' MSUwIwYDVQQDHhwEHwQ+BD8EPgQyACAEPQQwBDQENQQ2
'' SIG '' BD0ESwQ5MB4XDTAxMTIzMTIwMDAwMFoXDTA3MTIzMTIw
'' SIG '' MDAwMFowJzElMCMGA1UEAx4cBB8EPgQ/BD4EMgAgBD0E
'' SIG '' MAQ0BDUENgQ9BEsEOTCBnzANBgkqhkiG9w0BAQEFAAOB
'' SIG '' jQAwgYkCgYEAsNlPby/9ax7Ky75RO8xI+jrNU/u842T2
'' SIG '' 6Md730yxbVD9+54SVNtsCoYOR7OYgQMb9TtiirFpk0bJ
'' SIG '' PH7WuCjGlrMOhDt86Vq++er67d87p0rytm0R7m1/FOkw
'' SIG '' GxxjycUEKS2w65FXfdpngRKiu3NIDb6tsupKiHex3XEo
'' SIG '' 1n0O++kCAwEAAaNxMG8wEwYDVR0lBAwwCgYIKwYBBQUH
'' SIG '' AwMwWAYDVR0BBFEwT4AQ0LHfQjJYgcR4nBGbd2fwEKEp
'' SIG '' MCcxJTAjBgNVBAMeHAQfBD4EPwQ+BDIAIAQ9BDAENAQ1
'' SIG '' BDYEPQRLBDmCEO+QUkHv+GuZSyf7OUj1afswDQYJKoZI
'' SIG '' hvcNAQEEBQADgYEAe3+Qek5z1V/kzjxcYB4nrGs0jN+5
'' SIG '' uRTY5+PtPyjz85i2y3YbH08HitGUYhZA3ImslbzMOCGg
'' SIG '' vIJAfzvhlIve+kKG5pG9EDFUpJ/eyHEizAmxjSChgZlz
'' SIG '' 2V++7VF6hIevX4VcUKCcCoGXb88Tp/XwY1arFFYzSUZg
'' SIG '' MJl3tYcHVrMxggFSMIIBTgIBATA7MCcxJTAjBgNVBAMe
'' SIG '' HAQfBD4EPwQ+BDIAIAQ9BDAENAQ1BDYEPQRLBDkCEO+Q
'' SIG '' UkHv+GuZSyf7OUj1afswDAYIKoZIhvcNAgUFAKBsMBAG
'' SIG '' CisGAQQBgjcCAQwxAjAAMBkGCSqGSIb3DQEJAzEMBgor
'' SIG '' BgEEAYI3AgEEMBwGCisGAQQBgjcCAQsxDjAMBgorBgEE
'' SIG '' AYI3AgEVMB8GCSqGSIb3DQEJBDESBBDWCooVTqYEryt6
'' SIG '' BNyCqxsxMA0GCSqGSIb3DQEBAQUABIGASPcIufHgECN+
'' SIG '' r9VNOAo4NJnI610cZS73Unu29n27/LISI5zrHqC/AR2n
'' SIG '' ts04Ah3j79usRJEaNJySDdTB3T5CyEue0XBS1FOTj4nt
'' SIG '' kYZBWXVxM0+Z1oGZNCTFJFtqPnEGhI2WwpKMz00luw09
'' SIG '' qnpjkM9dxsgPlumnkf5dpleZtBU=
'' SIG '' End signature block
►Листинг 4.10. Подписанный WS-файл
<job>
<runtime>
<description>
Имя: Signed.wsf
Описание: Сценарий с цифровой подписью
</description>
</runtime>
<script language="JScript">
WScript.Echo("Привет!");
</script>
<signature>
** SIG ** MIIEMAYJKoZIhvcNAQcCoIIEITCCBB0CAQExDjAMBggq
** SIG ** hkiG9w0CBQUAMGYGCisGAQQBgjcCAQSgWDBWMDIGCisG
** SIG ** AQQBgjcCAR4wJAIBAQQQcAVhGs441BGiowAQS9NQkAIB
** SIG ** AAIBAAIBAAIBAAIBADAgMAwGCCqGSIb3DQIFBQAEEANf
** SIG ** TmfjlqP6LHKR3b45MWagggJIMIICRDCCAa2gAwIBAgIQ
** SIG ** 75BSQe/4a5lLJ/s5SPVp+zANBgkqhkiG9w0BAQQFADAn
** SIG ** MSUwIwYDVQQDHhwEHwQ+BD8EPgQyACAEPQQwBDQENQQ2
** SIG ** BD0ESwQ5MB4XDTAxMTIzMTIwMDAwMFoXDTA3MTIzMTIw
** SIG ** MDAwMFowJzElMCMGA1UEAx4cBB8EPgQ/BD4EMgAgBD0E
** SIG ** MAQ0BDUENgQ9BEsEOTCBnzANBgkqhkiG9w0BAQEFAAOB
** SIG ** jQAwgYkCgYEAsNlPby/9ax7Ky75RO8xI+jrNU/u842T2
** SIG ** 6Md730yxbVD9+54SVNtsCoYOR7OYgQMb9TtiirFpk0bJ
** SIG ** PH7WuCjGlrMOhDt86Vq++er67d87p0rytm0R7m1/FOkw
** SIG ** GxxjycUEKS2w65FXfdpngRKiu3NIDb6tsupKiHex3XEo
** SIG ** 1n0O++kCAwEAAaNxMG8wEwYDVR0lBAwwCgYIKwYBBQUH
** SIG ** AwMwWAYDVR0BBFEwT4AQ0LHfQjJYgcR4nBGbd2fwEKEp
** SIG ** MCcxJTAjBgNVBAMeHAQfBD4EPwQ+BDIAIAQ9BDAENAQ1
** SIG ** BDYEPQRLBDmCEO+QUkHv+GuZSyf7OUj1afswDQYJKoZI
** SIG ** hvcNAQEEBQADgYEAe3+Qek5z1V/kzjxcYB4nrGs0jN+5
** SIG ** uRTY5+PtPyjz85i2y3YbH08HitGUYhZA3ImslbzMOCGg
** SIG ** vIJAfzvhlIve+kKG5pG9EDFUpJ/eyHEizAmxjSChgZlz
** SIG ** 2V++7VF6hIevX4VcUKCcCoGXb88Tp/XwY1arFFYzSUZg
** SIG ** MJl3tYcHVrMxggFSMIIBTgIBATA7MCcxJTAjBgNVBAMe
** SIG ** HAQfBD4EPwQ+BDIAIAQ9BDAENAQ1BDYEPQRLBDkCEO+Q
** SIG ** UkHv+GuZSyf7OUj1afswDAYIKoZIhvcNAgUFAKBsMBAG
** SIG ** CisGAQQBgjcCAQwxAjAAMBkGCSqGSIb3DQEJAzEMBgor
** SIG ** BgEEAYI3AgEEMBwGCisGAQQBgjcCAQsxDjAMBgorBgEE
** SIG ** AYI3AgEVMB8GCSqGSIb3DQEJBDESBBC8sjXscmpwRH4l
** SIG ** +m0CC76kMA0GCSqGSIb3DQEBAQUABIGAipV3It04p5Mz
** SIG ** h1Mg/dssx9PjnOTY2AWZjCYnlt8XSaGQTna1P780Krul
** SIG ** uIa3ZNbeqeSELrkZEaQdzhcw6lfUOJxVWOXKdLsss8sM
** SIG ** V9HjQ00ggKeDDtsSC+twoz7TMWqLsvEgHz7ARzL9V6lQ
** SIG ** juR0pw/g4E4cfiBQ7fvtnLh+s9o=
</signature>
</job>
Проверка цифровой подписи сценария
Применяя соответствующие политики безопасности, можно установить режим, при котором все запускаемые сценарии автоматически будут проверяться на предмет корректности их цифровой подписи (процесс настройки подобных политик безопасности описан ниже).
Кроме этого, можно самостоятельно из сценария WSH проверить достоверность цифровой подписи, которой снабжен тот или иной файл, и выяснить, входит ли сертификат создателя подписи в число сертификатов, к которым установлено доверие. Для такой проверки служит метод VerifyFile объекта Scripting.Signer. Данный метод имеет два параметра (File и ShowUI), первый из которых задает имя проверяемого файла, а второй является логическим флагом, позволяющим выводить или не выводить на экран диалоговое окно с информацией о состоянии сертификата, при помощи которого была создана цифровая подпись для этого файла. Если цифровая подпись проверяемого сценария является корректной, содержимое файла после создания подписи не изменялось, а к сертификату создателя сценария установлено доверие, то метод VerifyFile возвращает значение true, в противном случае — false.
В качестве примера в листинге 4.11 приведен сценарий Check.js, который проверяет цифровую подпись файла Signed.js.
►Листинг 4.11. Проверка подлинности цифровой подписи сценария
/*******************************************************************/
/* Имя: Check.js */
/* Язык: JScript */
/* Описание: Проверка цифровой подписи файла Signed.js */
/*******************************************************************/
var Signer, File, ShowUI, FileOK; //Объявляем переменные
//Создаем объект Scripting.Signer
Signer = WScript.CreateObject("Scripting.Signer");
File = "Signed.js"; //Имя проверяемого файла
ShowUI = false;
//Проверяем подпись в файле
FileOK = Signer.VerifyFile(File, ShowUI);
if (FileOK) WScript.Echo("Сценарий "+File+" является надежным.");
else WScript.Echo("Сценарий "+File+" НЕ является надежным.");
/************* Конец *********************************************/
Политики безопасности для сценариев WSH
Процесс организации политики безопасности для сценариев WSH заключается в задании тех или иных ограничений на запуск и выполнение этих сценариев. При этом могут применяться два подхода.
Первый подход может использоваться в операционной системе Windows любой версии, начиная с Windows 95. Смысл здесь состоит в применении специальных параметров системного реестра, которые позволяют:
• запретить выполнение на компьютере сценариев, запускаемых локально или с другой машины;
• задать режим работы WSH, при котором перед запуском всех сценариев проверяется их цифровая подпись и в соответствии с этим принимается решение о возможности выполнения этих сценариев;
• вести в журнале событий аудит успехов и отказов для сценариев WSH.
Второй подход может использоваться только в Windows ХР. Здесь для сценариев WSH, как и для всех других исполняемых программ, может применяться специальная политика ограниченного использования программ (SRP, Software Restriction Policies), с помощью которой можно, например, запретить запуск сценария, имеющего определенное имя или цифровую подпись.
Параметры реестра, влияющие на политику безопасности для WSH
Режим выполнения сценариев WSH зависит от нескольких параметров системного реестра, которые могут быть записаны в двух разделах:
HKLM\Software\Microsoft\Windows Script Host\Settings (А)
или
HKCU\Software\Microsoft\Windows Script Host\Settings (Б)
В разделе (А) хранятся установки WSH для всех пользователей, запускающих сценарии на данной машине, а в разделе (Б) — для текущего пользователя, зарегистрированного в системе. При этом строковый параметр IgnoreUserSettings из раздела (А) определяет, откуда именно будут браться параметры: если IgnoreUserSettings равен 0 или вообще не задан, то на политику безопасности для сценариев WSH будут влиять параметры из раздела (А). Если же IgnoreUserSettings равен 1, то параметры берутся из раздела (Б).
Параметры реестра, определяющие политику безопасности при использовании сценариев WSH, описаны в табл. 4.2.
Таблица 4.2. Параметры реестра для WSH
| Параметр |
Тип |
Описание |
Enabled |
Строковый (REG_SZ) |
Если значение равно 0, то выполнение любых
сценариев WSH запрещено. Если значение равно 1, то на машине могут
выполняться локальные сценарии WSH. Значением по умолчанию является 1 |
Remote |
Строковый (REG_SZ) |
Если значение равно 0, то выполнение удаленных
сценариев WSH запрещено. Если значение равно 1, то на машине могут
выполняться удаленные (т. е. запускаемые с других компьютеров) сценарии
WSH. Значением по умолчанию является 0 |
TrustPolicy |
Целый (REG_DWORD) |
Если значение равно 0, то все сценарии
запускаются без проверки их цифровой подписи. Если значение равно 1, то
перед запуском неподписанных сценариев или сценариев с подписью, которой
соответствует цифровой сертификат, не входящий в число доверяемых, будет
выводиться диалоговое окно с предупреждением о возможной опасности такого
сценария (при этом есть возможность отказаться от выполнения сценария).
Если значение равно 2, то будут запускаться только сценарии, которые
подписаны цифровой подписью, и к сертификату, с помощью которого создана
эта подпись, установлено доверие. Значением по умолчанию является 0 |
UseWINSAFER |
Строковый (REG_SZ) |
В операционных системах Windows 9х/МЕ/ NT/2000
этот параметр не используется. В Windows ХР параметр определяет, следует
ли к сценариям WSH применять политики ограниченного использования программ
(SRP). Если значение равно 0, то к сценариям WSH политики ограниченного
использования программ не применяются, а режим выполнения сценариев
определяется параметром TrustPolicy. Если значение равно 1,
то режим выполнения сценариев задается политикой ограниченного
использования программ, а параметр TrustPolicy игнорируется.
Значением по умолчанию является 0 |
LogSecurityFailures |
Строковый (REG_SZ) |
Если значение равно 1, то информация о всех
ошибках, которые возникают при выполнении сценариев и связаны с вопросами
безопасности, заносится в журнал событий системы (System Event Log).
Другими словами, ведется аудит отказов для сценариев WSH. Если значение
равно 0, то информация об ошибках в сценариях, которые связаны с
нарушениями установленных политик безопасности, не заносится в журнал
событий. Значением по умолчанию является 0 |
LogSecuritySuccesses |
Строковый (REG_SZ) |
Если значение равно 1, то ведется аудит успехов
для сценариев WSH, т.е. в в журнал событий системы (System Event Log)
записывается информация о каждом успешно запущенном сценарии. Если
значение равно 0, то аудит успехов не ведется. Значением по умолчанию
является 0 |
Устанавливая определенным образом значения параметров системного реестра из табл. 4.2, можно настроить политику безопасности при использовании сценариев WSH для конкретного пользователя или рабочей станции (например, можно разрешить выполнение сценариев только администраторам домена). В сетях Windows NT или на автономной машине для этого используется редактор системной политики (Poledit.exe), а в сетях с установленной службой каталогов Active Directory применяется групповая политика (Group Policy), доступная с помощью оснастки Active Directory — пользователи и компьютеры (Active Directory — users and computers) консоли управления ММС. На автономном компьютере с операционной системой Windows ХР/2000 для настройки политики безопасности WSH можно также изменять локальную групповую политику, которая позволяет задать одинаковые параметры безопасности для всех пользователей данного компьютера.
В любом случае для более удобного и безопасного изменения значений параметров реестра следует применять административные шаблоны (administrative templates) — текстовые файлы с расширением adm, позволяющие создавать удобный пользовательский интерфейс для редактирования заданных параметров системного реестра в редакторе системной политики или при работе с оснасткой Групповая политика (Group Policy) в ММС (пример такого adm-файла, позволяющего блокировать выполнение сценариев WSH, приведен в листинге 4.12).
!
Более подробную информацию о редакторе системной политики
Poledit.exe, настройке групповой политики в Windows 2000/ХР и
администраторских шаблонах можно найти в справочной системе Windows ХР и
документации MSDN.
Блокировка локальных и удаленных сценариев WSH. Пример административного шаблона
Как уже было указано в табл. 4.2, за блокировку локальных и удаленных сценариев WSH отвечают соответственно параметры реестра
Enabled и Remote: если Enabled равно "0", то на машине вообще нельзя выполнять сценарии, если Remote равен "0", то нельзя выполнять сценарии, запускаемые с другого компьютера (удаленные сценарии). При такой блокировке устанавливается запрет на выполнение сценариев всех типов — при попытке запуска любого файла с расширениями js, vbs, jse, vbe или wsf будет выведено диалоговое окно, показанное на рис. 4.13, а сценарий выполнен не будет.
В листинге 4.12 приведен административный шаблон wsh.adm, с помощью которого можно запрещать/разрешать выполнение локальных или удаленных сценариев. Как мы видим, в административном шаблоне описывается путь к разделу реестра (параметр KEYNAME), содержащего нужный параметр, название (параметр VALUENAME) и список возможных значений (параметры
VALUEON и VALUEOFF) этого параметра, а также приводятся строки, поясняющие назначение редактируемых параметров (секция
[STRINGS]).
Рис. 4.13. Блокировка выполнения сценариев WSH
►Листинr 4.12. Файл WSH.adm
CLASS MACHINE
CATEGORY "Локальные и удаленные сценарии WSH"
POLICY !!LocalEnabledPolicy
KEYNAME "Software\Microsoft\Windows Script Host\Settings"
EXPLAIN !!LocalEnabledPolicyHelp
VALUENAME Enabled
VALUEON "1" VALUEOFF "0"
END POLICY
POLICY !!MachRemotePolicy
KEYNAME "Software\Microsoft\Windows Script Host\Settings"
EXPLAIN !!MachRemotePolicyHelp
VALUENAME Remote
VALUEON "1" VALUEOFF "0"
END POLICY
POLICY !!IgnoreUserSettingsPolicy
KEYNAME "Software\Microsoft\Windows Script Host\Settings"
EXPLAIN !!IgnoreUserHelp
VALUENAME IgnoreUserSettings
VALUEON "1" VALUEOFF "0"
END POLICY
END CATEGORY
CLASS USER
CATEGORY "Локальные и удаленные сценарии WSH"
POLICY !!LocalEnabledPolicy
KEYNAME "Software\Microsoft\Windows Script Host\Settings"
EXPLAIN !!LocalEnabledPolicyHelp
VALUENAME Enabled
VALUEON "1" VALUEOFF "0"
END POLICY
POLICY !!MachRemotePolicy
KEYNAME "Software\Microsoft\Windows Script Host\Settings"
EXPLAIN !!MachRemotePolicyHelp
VALUENAME Remote
VALUEON "1" VALUEOFF "0"
END POLICY
END CATEGORY
[STRINGS]
LocalEnabledPolicy="Разрешить локальный WSH"
LocalEnabledPolicyHelp="Если значение равно 1, то локальный WSH разрешен"
MachRemotePolicy="Разрешить удаленный WSH"
MachRemotePolicyHelp="Если значение равно 1, то удаленный WSH разрешен"
IgnoreUserSettingsPolicy="Игнорировать установки пользователя"
IgnoreUserHelp="Должен быть установлен для того, чтобы применять ко всем пользователям политику для машины"
Для применения политик безопасности, которые описаны в шаблоне wsh.adm, к различным пользователям и рабочим станциям, можно воспользоваться либо редактором системной политики Poledit.exe (в сетях Windows NT и на автономных машинах), либо оснасткой Групповая политика (Group Policy) в ММС (в сетях с установленной службой каталогов Active Directory и на автономных машинах).
Рассмотрим сначала вариант, связанный с использованием редактора системной политики Poledit.exe. После запуска этой программы надо добавить wsh.adm в список текущих шаблонов политик. Для этого нужно в меню Параметры (Options) выбрать пункт Шаблон политики (Policy Template) и воспользоваться кнопкой Добавить (Add) в диалоговом окне Параметры шаблона политики (Policy Template Options) (рис. 4.14).
Рис. 4.14. Добавление файла wsh.adm в список текущих шаблонов политик
После подключения шаблона wsh.adm можно создать новую политику (пункт Новая политика (New Policy) в меню Файл (File)) (рис. 4.15).
Рис. 4.15. Создание новой системной политики
В свойствах пользователя и компьютера появится новый раздел
Локальные и удаленные сценарии WSH с соответствующими параметрами политики безопасности, которые описаны в wsh.adm (рис. 4.16).
Рис. 4.16. Параметры политики безопасности для WSH, взятые из шаблона wsh.adm
В Windows 2000/ХР, имея соответствующие администраторские права, можно подключить административный шаблон wsh.adm к оснастке Групповая политика (Group Policy) в ММС. Рассмотрим, каким образом это делается для автономного компьютера, не подключенного к сети.
Сначала загрузим ММС, выполнив команду mmc либо в командной строке, либо с помощью пункта Выполнись (Run) меню Пуск (Start). Затем выберем пункт Добавить или удалить оснастку (Add/Remove Snap-in) в меню Консоль (Console) и нажмем кнопку Добавить (Add). В появившемся списке всех имеющихся оснасток нужно выбрать пункт Групповая политика (Group Policy) и нажать кнопку Добавить (Add). После этого запустится мастер групповой политики, в котором нужно указать, что объектом групповой политики является локальный компьютер, и нажать кнопку Готово (Finish) (рис. 4.17).
Рис. 4.17. Мастер групповой политики
Никаких других оснасток в окно консоли мы добавлять не будем, поэтому нажимаем кнопку Закрыть (Close) в списке оснасток и кнопку
OK в окне добавления/удаления оснасток. После этого мы можем в окне консоли изменять групповую политику для локального компьютера (рис. 4.18).
Для того чтобы добавить в оснастку нужный нам административный шаблон, следует выделить раздел Конфигурация компьютера | Административные шаблоны (Computer Configuration | Administrative Templates) и в меню Действие (Action) выбрать пункт Добавление/удаление шаблонов (Add/Remove Templates). После этого на экран будет выведено диалоговое окно со списком всех шаблонов, подключенных к оснастке Политика "Локальный компьютер" (Local Computer Policy) (рис. 4.19).
Для добавления нового административного шаблона в этот список нужно нажать кнопку Добавить (Add) и выбрать нужный файл с расширением adm (в нашем случае это wsh.adm). После этого список подключенных шаблонов следует закрыть. В результате в каждом из разделов Конфигурация компьютера | Административные шаблоны (Computer Configuration | Administrative Templates) и Конфигурация пользователя | Административные шаблоны (User Configuration I Administrative Templates) создастся подраздел Локальные и удаленные сценарии WSH (рис. 4.20).
Рис. 4.18. Настройки групповой политики для локального компьютера
Рис. 4.19. Административные шаблоны, подключенные к оснастке Групповая политика
Рис. 4.20. Новый подраздел Локальные и удаленные сценарии WSH
Рис. 4.21. Параметры фильтрации административных шаблонов политик
Для того чтобы описанные в wsh.adm параметры можно было редактировать, нужно выделить подраздел Локальные и удаленные сценарии WSH, выбрать в меню Вид (View) пункт Фильтрация (Filter), снять флажок Показывать только управляемые параметры политики (Show controlled policy parameters only) в диалоговом окне Фильтрация (Filter) и нажать кнопку OK (рис. 4.21).
После этого в подразделе Локальные и удаленные сценарии WSH будут показаны описанные в wsh.adm параметры политики безопасности для WSH (рис. 4.22).
Рис. 4.22. Параметры политики безопасности для WSH, взятые из шаблона wsh.adm
В правой части окна Консоль1 отображаются состояния локальных и удаленных сценариев WSH. Выбирая соответствующую вкладку, можно переключаться между расширенным и стандартным отображением параметров.
Выбрав с помощью нажатия клавиши <Enter> нужный параметр, можно установить его значение (рис. 4.23).
Рис. 4.23. Изменение значения параметра политики безопасности для WSH
Три режима выполнения сценариев WSH
Для сценариев WSH можно задать один из трех режимов их выполнения:
1. Режим безопасности отключен. Запускаются все сценарии, вне зависимости от того, имеется ли у этих сценариев цифровая подпись или нет.
2. Средний уровень безопасности. Надежные сценарии, т.е. имеющие цифровую подпись, к которой установлено доверие, запускаются сразу, без дополнительных сообщений. При попытке запуска неподписанных сценариев или сценариев, подписанных с помощью цифрового сертификата, к которому не установлено доверие, а также сценариев, содержимое которых было изменено после подписания, выводится диалоговое окно с кратким описанием возникшей ситуации. Данное диалоговое окно позволяет либо проигнорировать предупреждение о возможной небезопасности сценария и запустить его, либо отказаться от выполнения сценария.
3. Сильный уровень безопасности. Надежные сценарии запускаются сразу, без дополнительных сообщений. Всем остальным сценариям будет отказано в запуске.
Как следует из табл. 4.2, для установки той или иной политики безопасности служит параметр реестра целого типа TrustPolicy. Значения этого параметра, равные 0, 1 и 2, соответствуют пунктам 1, 2 и 3 вышеприведенного списка.
!
Для установки политики безопасности WSH с помощью
TrustPolicy, необходимо, чтобы значением параметра
UseWINSAFER был 0 (либо этот параметр не был указан совсем).
В качестве примера запустим сценарий Signed.vbs с подписью, основанной на цифровом сертификате "Попов ненадежный". Если
TrustPolicy равно 1, то на экран выведется диалоговое окно, показанное на рис. 4.24.
Рис. 4.24. Предупреждение о безопасности при запуске ненадежного сценария (TrustPolicy=1)
Рис. 4.25. Отказ при запуске ненадежного сценария (TrustPolicy=2)
Если же установить значение параметра TrustPolicy равным 2 и попытаться выполнить Signed.vbs, то сценарий запущен не будет, а на экран будет выведено диалоговое окно, показанное рис. 4.25.
Протоколирование действий сценариев в журналах событий
При использовании WSH имеется возможность вести аудит успехов и отказов для сценариев, т.е. автоматически заносить в журнал событий системы информацию об успешных или неуспешных (с точки зрения безопасности) попытках запуска сценариев. Для этой цели служат два параметра системного реестра (LogSecuritySuccesses и LogSecurityFailures), которые были описаны в табл. 4.2.
!
Для просмотра журнала событий можно воспользоваться
соответствующей оснасткой в ММС или выбрать в меню Пуск (Start) пункт
Все программы | Администрирование | Просмотр событий (All Programs |
Administrative Tools | Event Viewer).
Рассмотрим пример. Установим режим безопасности так, чтобы для сценариев WSH велся как аудит успехов (LogSecuritySuccesses="1"), так и аудит отказов (LogSecurityFailures="1"). Если теперь заблокировать сценарии WSH (Enabled="0") и попытаться запустить какой-либо сценарий, то в журнал событий системы будет добавлена запись об отказе (рис. 4.26).
Рис. 4.26. Информация об отказе для сценария WSH в журнале событий системы
Разрешим теперь выполнение сценариев WSH (Enabled="1") и установим режим безопасности, при котором будут запускаться только сценарии с цифровыми подписями, для которых установлено доверие (TrustPolicy=2). Если запустить какой-либо сценарий с такой подписью (например, Signed.js с подписью, созданной на основе сертификата "Попов надежный"), то в журнале событий системы появится запись об успехе (рис. 4.27).
Рис. 4.27. Информация об успехе для сценария WSH в журнале событий системы
Применение к сценариям WSH политики ограниченного использования программ
В Windows ХР встроены политики ограниченного использования программ (SRP, Software Restriction Policies), с помощью которых можно управлять возможностью выполнения программного обеспечения на компьютере. Политики SRP могут применяться и к сценариям WSH любого типа, для этого необходимо, чтобы параметр системного реестра UseWINSAFER, который описан в табл. 4.2, имел значение 1.
Для применения политик SRP к сценариям WSH на локальной машине необходимо сначала загрузить в ММС оснастку Политика "Локальный компьютер" (Local Computer Policy) (рис. 4.28).
Рис. 4.28. Установка политик SRP с помощью оснастки
Политика "Локальный компьютер"
!
Процесс загрузки этой оснастки был подробно описан в разд.
"Блокировка локальных и удаленных сценариев WSH. Пример административного
шаблона" этой главы, поэтому здесь мы останавливаться на нем не будем.
После этого нужно перейти в раздел Конфигурация компьютера | Конфигурация Windows | Параметры безопасности | Политики ограниченного использования программ | Дополнительные правила (Computer Configuration | Windows Configuration | Security Settings | Software Restriction Policies | Additional Rules).
Создание и изменение дополнительных правил (Additional Rules) в SRP и является механизмом определения политик безопасности для сценариев WSH.
Блокировка сценария с заданным именем
Для того чтобы, пользуясь SRP, запретить выполнение сценариев с определенными именами, нужно создать новое правило для пути (Path Rule), которое позволяет идентифицировать программы по пути к ним. Рассмотрим, например, каким образом можно запретить выполнение всех сценариев, написанных на языке VBScript (т.е. запретить запуск всех файлов с расширением vbs). Для этого нужно, находясь в разделе Дополнительные правила (Additional Rules), выбрать в меню Действие (Action) пункт Создать правило для пути (New Path Rule), после чего на экран будет выведено диалоговое окно, в котором нужно описать создаваемое правило. Здесь в поле Путь (Path) укажем маску "*.vbs" для всех VBScript-сценариев, а в раскрывающемся списке Уровень безопасности (Security level) выберем значение "Не разрешено" ("Disallowed") (рис. 4.29).
Рис. 4.29. Диалоговое окно для создания нового правила для пути
После ввода такого дополнительного правила SRP на машине нельзя будет запускать сценарии с расширением vbs. При попытке выполнения VBScript- сценария будет выведено диалоговое окно с информацией о невозможности его запуска (рис. 4.30).
Также в разделе Дополнительные правила (Additional rules) имеется возможность создать правило для хеша (хеш — Это серия байтов фиксированной длины, которая рассчитывается по специальному алгоритму и однозначно идентифицирует содержимое файла). С помощью этого правила можно запретить выполнение файла, имеющего заданный хеш. Однако для сценариев, в отличие от компилированных исполняемых модулей, это не является подходящим ограничением, т.к. хеш файла со сценарием можно изменить простым добавлением пустой строки в текст сценария.
Рис. 4.30. Блокировка сценариев WSH с помощью дополнительных правил SRP
Блокировка сценариев с заданной подписью
Еще одним возможным ограничением является запрет на выполнение файлов, подписанных с помощью определенного цифрового сертификата ("Попов ненадежный", например).
Рис. 4.31. Диалоговое окно для создания нового правила для сертификата
Для этого нужно в разделе Дополнительные правила (Additional rules) создать новое правило для сертификата (Certificate Rule) (пункт Создать правило для сертификата (New Certificate Rule) в меню Действие (Action)). В диалоговом окне Создание правила для сертификата (New Certificate Rule) в качестве имени субъекта сертификата (Certificate subject name) укажем с помощью кнопки Обзор (Browse) файл C:\Script\Попов.cer (процесс создания этого файла описан в разд. "Управление сертификатами с помощью ММС"), а в раскрывающемся списке Уровень безопасности (Security level) выберем значение "Не разрешено" ("Disallowed") — рис. 4.31.
После ввода этого дополнительного правила SRP на машине нельзя будет запускать никакие исполняемые файлы (сценарии WSH в том числе), которые подписаны с использованием сертификата "Попов ненадежный".
✖
Глава 4. Безопасность при работе со сценариями WSH