Одним из главных преимуществ 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-файлы внутрь элементов

Листинг 4.6. Исходный сценарий ForEncode.wsf

Имя: Encoded.wsf

Описание: WS-файл с зашифрованными сценариями

Однако если попытаться зашифровать исходный файл 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 шифрует только содержимое элементов

Цифровые подписи добавляются в конец файлов, содержащих сценарии, причем в обычных JScript- и VBScript-файлах подпись находится в блоке комментария, а в WS-файлах — внутри элемента . Это делает возможным запуск подписанных сценариев в предыдущих версиях WSH, т.к. здесь закомментированные или находящиеся внутри части сценариев будут при выполнении проигнорированы. 

В листингах 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-файл

Имя: Signed.wsf

Описание: Сценарий с цифровой подписью

** 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=

 

 

Проверка цифровой подписи сценария

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

Кроме этого, можно самостоятельно из сценария 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 заключается в задании тех или иных ограничений на запуск и выполнение этих сценариев. При этом могут применяться два подхода.

Первый подход может использоваться в операционной системе 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

Устанавливая определенным образом значения параметров системного реестра из табл. 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. Выбирая соответствующую вкладку, можно переключаться между расширенным и стандартным отображением параметров.

Выбрав с помощью нажатия клавиши нужный параметр, можно установить его значение (рис. 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 в том числе), которые подписаны с использованием сертификата "Попов ненадежный".