Марсин Полич (Marcin Policht)

В предыдущей статье данной серии был сделан обзор управления заплатами в ОС . В сегодняшней статье мы уделим внимание доступным решениям. Начнем с проверки бесплатных возможностей, которые могут быть сгруппированы в три основные категории:

1. Решения на основе сценариев
2. Улучшения и продукты операционных систем Microsoft
3. Инструменты сторонних производителей

Многие из этих методов дополняют друг друга и могут комбинироваться в полных решениях, что позволяет добиться как обнаружения уязвимостей, так и развертывания заплат. Некоторые объединенные решения уже рассматривались в предыдущей статье (такие как HFNetChk от компании Shavlik Technologies или файл mssecure.xml).

Прежде чем мы окунемся в море возможных решений, давайте сначала рассмотрим общие технические приемы для запроса реестра и запуска процессов на локальной и удаленной системах. Эти функции позволят вам либо разработать индивидуальные решения по управлению заплатами, либо использовать одну из утилит сторонних производителей (которые мы обсудим далее). Обратите внимание, однако, что проверка установки заплат, основанная на одном только реестре (а не на версиях файла или контрольной сумме) может, по ряду причин, ввести в заблуждение. Чтобы обозначать свое присутствие, заплаты создают ключи реестра, но это не гарантирует того, что все важные файлы установлены и не повреждены, особенно в случае индивидуальных установочных процедур. Например, если QCHAIN.EXE применяется для объединения нескольких исправлений в единый пакет без соответствующих предосторожностей, то у вас могут возникнуть проблемы, описанные в статье 296861 Базы Знаний (КВ) Microsoft. Подобным образом, пакеты обновления компонентов безопасности (security rollup) зачастую не включают полного набора ссылок реестра для отдельных заплат, содержащихся в них. Утилиты HFNetChk и MBSA компании Microsoft предоставляют опцию, позволяющую обойтись без проверки реестра и полностью основываться на сравнении версий файлов и контрольных сумм с записями в файле mssecure.xml. С другой стороны, проверка реестра является основным механизмом, используемым Windows Update, поэтому, как минимум, индивидуальные сценарии должны быть также надежны, как механизм управления заплатами по умолчанию компании Microsoft.

В реестре соответствующая информация содержится в двух местах:

Чтобы найти методы для запроса удаленного реестра с помощью сценариев, отсылаю вас к моей серии статей Managing Windows Registry With Scripting (Управление реестром Windows с помощью сценариев). Обратите внимание на то, что эти сценарии зависят от компонентов Windows Management Instrumentation (WMI), присутствующих на целевом компьютере. Это не является проблемой, если имеешь дело с новейшими версиями , поскольку, начиная с 2000, WMI интегрирована в операционную систему. Однако, для рабочих станций и серверов Windows NT 4.0, WMI, возможно, придется устанавливать (список ссылок и инструкций по установке может быть найден здесь).

Локальная или удаленная установка заплаты может быть обработана с помощью возможностей WMI (вызвав метод Create класса Win32_Process WMI). Следующий образец сценария демонстрирует этот подход. В общем, этим способом может быть вызван любой процесс.

Не обращайте внимания на номера в начале каждой строки – я буду ссылаться на них, объясняя код – но они должны быть удалены, если вы решите протестировать этот сценарий.

1       Dim sComputerB '-- имя компьютера, на который устанавливается заплата

2       Dim sComputerC '-- имя компьютера, на котором расположена исполняемая заплата

3       Dim sDomain    '-- домен, в котором находятся эти компьютеры

4       Dim sPatchExe  '-- полный путь к исполняемой заплате

5       Dim sTempDir   '-- рабочая папка на компьютере В (Computer B)

6       Dim oLocator   '-- объект, представляющий класс SWbemLocator

7       Dim oWMISvc    '-- объект, представляющий класс SWbemService

8       Dim oProcess   '-- объект, представляющий класс Win32_Process

9       Dim iResult    '-- целое число, представляющее результат создания процесса

10      Dim iPID       '-- целое число, представляющее PID создаваемого процесса

11      sDomain        = "ServerWatch"

12      sComputerB     = "ComputerB"

13      sComputerC     = "ComputerC"

14      sPatchExe      = "\\" & sComputerC &"\Patches$\q123456_w2k_sp2_x86_en.exe /q"

15      sTempDir       = "%TEMP%"

16      sUserName      = "InstallAdmin"

17      sPassword      = "$w0rdF1sh"

18      Set oLocator   = CreateObject("WbemScripting.SWbemLocator")

19      Set oWMISvc    = oLocator.ConnectServer(sComputerB, "root\cimv2", _ 

                       sDomain & "\" & sUserName, sPassword,, _

                       "kerberos:" & sDomain & "\" & sComputerB)

                       '—Делегируем уровень олицетворения

20      oWMISvc.Security_.ImpersonationLevel = 4

                       '-- привилегию SeShutdown

21      oWMISvc.Security_.Privileges.Add 18 

22      Set oProcess   = oWMIService.Get("Win32_Process")

23      iResult        = oProcess.Create(sPatchExe, sTempDir,, iPID)

24      If iResult = 0 Then

25             WScript.Echo "Создание процесса завершено"

26             WScript.Echo "ID нового процесса - " & iPID

27      Else

28             WScript.Echo "Создание процесса провалилось без возвращаемого значения " & iResult

29      End If

Это сценарий предполагает простейшую схему, в которую вовлечены три компьютера – компьютер А, на котором запускается сценарий, компьютер В, где должна быть установлена заплата и компьютер С, хранящий исполняемую заплату. В этом случае существуют два главных препятствия. Первое из них – способность запускать удаленные процессы в контексте безопасности произвольно выбранной учетной записи – разрешается с помощью метода ConnectServer класса sWbemLocator (строка 19). Метод ConnectServer позволяет пользователю определять альтернативные реквизиты для идентификации (имя в формате domain\username и соответствующий пароль задаются в строках 16 и 17 соответственно). Второе препятствие заключается в том, этот метод использует аутентификацию Kerberos (а не NTLM, являющейся механизмом аутентификации по умолчанию). Причина заключается в том (и это объясняется во всех подробностях в этой статье Базы Знаний (КВ) Microsoft), что подобное подключение к третьему компьютеру (в нашем случае – это компьютер С) требует делегирования полномочий, что невозможно осуществить, используя аутентификацию NTLM). Делегирование устанавливается с помощью задания для ImpersonationLevel значения 4 (строка 20).

В строке 21 мы присваиваем привилегию Shutdown процессу, запускаемому на компьютере В (подобным способом можно перезапустить компьютер после установки заплаты). Исполняемая командная строка определена в строке 14 (для типового синтаксиса установки заплат, адресую вас к статье из Базы Данных (КВ) Microsoft – Summary of Command-Line Syntax for Software Updates. Очевидно, что имена компьютеров, домены, полномочия пользователей и пути для заплат должны быть изменены с соответствие с реалиями вашей среды.

Кроме создания этого сценария, вы должны также сконфигурировать компьютер и учетные записи пользователей, вовлеченных в установку заплат, так, чтобы они могли принять участие в делегировании. Требуемые настройки конфигурируются с помощью оснастки Active Directory Users and Computers. После того, как этот инструмент будет запущен, определите местоположение компьютера В и выберите опцию "Trust this computer for delegation" из диалогового окна Properties (эта настройка находится на вкладке General в версии Windows 2000 этого инструмента и на вкладке Delegation, если вы работаете с доменами Windows 2003). Вы также должны убедиться, что учетная запись пользователя, используемая для установки, является делегированной (эта опция находится в области Account Options вкладки Account окна свойств учетной записи пользователя в Active Directory Users and Computers).

Главной проблемой данного подхода является то, что он применим только к доменам Windows 2000 или 2003 и операционным системам Windows 2000 и выше (и не поддерживается операционными системами и доменами Windows NT 4.0). Кроме того, назначение делегированных привилегий подразумевает потенциальную уязвимость среды.

Существуют некоторые обходные пути, позволяющие преодолеть эти ограничения:

1. Скопируйте заплаты в определенное расположение на целевом компьютере, на котором они должны быть установлены. Вы можете сделать это, запустив отдельный, простой сценарий перед тем, как вызывать тот, что описан выше. Если выбрана папка, для которой пользователи имеют права только на чтение, то файлы могут также распространяться как часть сценария регистрации в системе. При этом вы более не будете зависеть от Kerberos и делегирования, вернувшись к определенной по умолчанию аутентификации NTLM и настройкам олицетворения (impersonation). Тогда строка 19 сценария должна измениться следующим образом:

                       sDomain & "\" & sUserName, sPassword)

      а строка 20 так:

        oWMISvc.Security_.ImpersonationLevel = 3

3.      Строка 14 также должна измениться на локальный путь. Поскольку NTLM и олицетворение работают прекрасно в среде Windows NT 4.0, ни одно из ограничений, описанных выше, не будет действовать. Подобный подход представлен в статье 827227 Базы Знаний (КВ) Microsoft, описывающей как использовать сценарий Visual Basic для установки заплат систем безопасности 824146 (MS03-039) или 823980 (MS03-026) (сценарий включенный в статью, может быть доработан для развертывания и других заплат).

4. Если копирование заплат на удаленные компьютеры не является жизнеспособным решением, в качестве части исходного сценария может быть использовано подключение дисков (drive mapping). Сценарий может подключать диск к общей папке на компьютере С, в которой расположены файлы заплаты, используя определенные полномочия (я НЕ рекомендую жестко прописывать их (полномочия) в сценарии, вместо этого советую представлять их в качестве вводимых из командной строки аргументов при выполнении сценария). При этом подключение к компьютеру С устанавливается в контексте безопасности существующего подключения диска.
5. Более простой опцией является загрузка утилиты PSExec с Web-сайта компании SysInternals. PSExec запускается на компьютере, на котором хранится заплата. При этом заплата копируется на удаленную систему для исполнения с определенными опциями. После того, как установка завершается, этот файл автоматически удаляется с удаленного компьютера.

Следующая статья этой серии продолжит наше изучение бесплатных решений.