Wbem что за программа

Сегодня в сетях многих предприятий используются операционные системы от различных производителей. Для одних задач больше подходят системы Microsoft, для других — семейства UNIX/Linux. Однако и те и другие требуют обслуживания и мониторинга. Для этих целей разработано некоторое количество программных продуктов.

К сожалению, одни порой слишком дороги для небольших организаций, другие бесплатны, но требуют дополнительных усилий, знаний и времени при настройке и не совсем удобны для применения в среде Windows. Между тем все они в своей работе, особенно с выходом Windows Server 2008, задействуют одни и те же механизмы. В данной статье я хотел бы рассмотреть эти механизмы и научить читателей использовать их

При работе над статьей я столкнулся с большим количеством терминов, описывающих нужные нам технологии. Их обилие порой вводит в заблуждение: CIM, CIMOM, WBEM, WMI, WINRM/WINRS, WSMAN, POWERSHELL REMOTING. Давайте, прежде всего, разберем, что такое CIM.

В 1999 году организация по стандартизации Distributed management Task Force (DMTF) разработала и опубликовала набор предложений по удаленному обмену управляющей информацией для систем, сетей и оборудования. Основная идея модели заключается в том, что управляемые сущности описаны при помощи объектов, имеют свойства с данными и методы, которые можно вызвать удаленно и изменить состояние объекта.

Следующим этапом развития этой технологии является инициатива Web-Based enterprise management (WBEM). В ней DMTF предложила набор механизмов, который бы позволил обращаться к данным CIM по протоколу HTTP, используемому в качестве транспортного. Для выполнения операций с CIM был разработан протокол CIM-XML. Эта технология была частично реализована в операционных системах Microsoft.

Однако в качестве протокола транспортного уровня специалисты Microsoft предпочли использовать DCOM, что сделало эту реализацию несовместимой со стандартом. В итоге появилась технология Windows Management Instrumentation (WMI). По сути, это реализация инициатив CIM/WBEM с точки зрения Microsoft.

Но прогресс не стоит на месте, и сравнительно недавно DMTF предложила очередную идею обеспечения удаленного управления системами на базе CIM через HTTP. На этот раз в качестве рабочей лошадки был выбран SOAP, а инициатива была названа WS-Management (WSMAN). Специалисты Microsoft решили не отступать от общепринятого стандарта и реализовали этот механизм в своих системах, назвав его WinRM. В итоге в Windows появилась возможность унифицированного доступа к CIM на различных платформах. В спецификации структура стека протоколов выглядит так, как показано на рисунке 1.

Рисунок 1. Структура стека WS-Management

Однако разработчики Microsoft на этом не остановились. Для обеспечения и упрощения удаленной работы в своем новом инструменте командной строки Powershell они разработали протокол Powershell Remoting Protocol. Структура его функционирования представлена на рисунке 2. Здесь MS-WSMV — это Web Services Management Protocol Extensions for Windows Vista, реализация протокола WS-Management для операционной системы Windows Vista. А MS-PSRP — собственно Powershell Remoting Protocol. Как мы видим, он работает на основе стандарта WS-Management.

Если вы из Украины, то TPS или U4U поможет вам пережить эту жуткую войну

Рисунок 2. Структура стека Powershell Remoting

На платформах UNIX/Linux ситуация выглядит несколько иначе. Для них существует несколько реализаций WBEM на HTTP/CIM-XML, что делает невозможным доступ к CIM из систем Windows при помощи стандартных утилит. В своих тестах я опробовал несколько подобных реализаций — OpenPegasus (http://www.openpegasus.org/) и SBLIM (http://sourceforge.net/apps/mediawiki/sblim/index.php? title=Main_Page). Оба проекта предоставляют возможность доступа к CIM по HTTP или HTTPS.

Аутентификация реализуется либо своими средствами, либо при помощи PAM. Можно подключать внешние классы. Однако при работе с OpenPegasus у меня возникли некоторые проблемы с настройкой, но об этом немного позже. С другой стороны, исходный код OpenPegasus является основой для агентов SCCM, использующихся для мониторинга систем Linux.

Реализация WS-Management для этой платформы тоже существует. В своих экспериментах я использовал Openwsman (http://www.openwsman.org).

Также стоит отметить, что документация к этим проектам довольно скудная, поэтому, для того чтобы добиться от используемых проектов корректной работы, придется потратить довольно много времени. Кроме того, основными типами аутентификации в этих службах являются методы digest и basic, что, конечно, несколько устарело и в случае смешанной среды Windows-Linux требует дополнительных усилий по созданию учетных записей и поддержания их безопасности как минимум в плане политики паролей.

Следующий шаг в развитии этих технологий — инициативы Systems Management Architecture for Server Hardware (SMASH) и Desktop and mobile Architecture for System Hardware (DASH). Эти технологии предназначены для удаленного управления аппаратным обеспечением. Их реализация встроена в аппаратное обеспечение. Таким образом, если ваше оборудование поддерживает эти технологии, возможны такие операции, как включение и выключение питания компьютера удаленно из командной строки без участия операционной системы. Поддержка этих технологий реализована в продуктах Intel (Intel AMT), HP (SMASH CLP в HP iLO2), AMD (AMD DAS 1.0).

Теперь рассмотрим методы, при помощи которых мы можем добраться до данных на различных платформах.

WMI, Windows и PowerShell

На эту тему написано уже очень много. Примеры сценариев можно найти в Интернете, в различных журналах и книгах. Поэтому особо углубляться не будем. Напомню только, что основной командой для работы с wmi является get-wmiobject. Можно использовать псевдоним gwmi. Например, классическое получение списка служб выполняется командой:

gwmi win32_Service | Format-Table -AutoSize

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

gwmi win32_Service -ComputerName localhost | Format-Table -AutoSize

Все это успешно работает в рамках домена, если у вас есть соответствующие права на клиентских компьютерах.

WBEM, Linux и PowerShell

В данном случае все обстоит несколько сложнее. Мы не можем воспользоваться стандартными возможностями PowerShell по причинам, описанным выше. Однако запросить данные мы все же можем. В принципе можно не только запрашивать данные, но и делать все те вещи, которые поддерживает используемый вами сервер WBEM. В нашем случае в качестве примера применяется SBLIM SFCB.

Памятуя о том, что в качестве протокола для запросов используется специальный протокол CIM-XML, в качестве транспорта HTTP напишем простой сценарий, который будет запрашивать определенный набор данных у сервера WBEM.

Принцип работы сценария достаточно прост. Он прочитывает подготовленный запрос в формате xml из файла, подготавливает пакет HTTP с нужными заголовками, оправляет готовый запрос на сервер и получает результат. Затем этот результат можно анализировать, зная схему XML-ответа. Все это выглядит так, как показано в листинге 1. Сам запрос представлен в листинге 2, а ответ — в листинге 3.

Теперь перейдем к WS-Management.

WS-MAN и Windows

В Windows мы можем использовать несколько средств работы с WS-Man. Это, прежде всего, PowerShell, а также утилита winrm. Утилита поддерживает следующие операции: GET, PUT, ENUMERATION, INVOKE. С ее помощью можно:

• перечислять экземпляры классов wmi:

-Winrm enumerate wmicimv2/ Win32_Service

• получать данные конкретного экземпляра:

-Winrm get wmicimv2/Win32_Service? Name=lanmanserver

• обращаться к удаленным системам:

-Winrm get wmicimv2/Win32_Service? Name=lanmanserver -r: remoteHost

• вызывать функции классов wmi на удаленных системах:

-winrm invoke reboot wmicimv2/ Win32_OperatingSystem -r: remoteHost

• запускать службы на удаленных системах

-winrm invoke startservice wmicimv2/ Win32_Service? name=w32 time -r: remoteHost

Следующая возможность — использование команд PowerShell. Их список можно получить с помощью команды

Get-Command *wsman* -CommandType Cmdlet

В инфраструктуре Windows для того, чтобы проверить, возможен ли доступ к удаленной системе при помощи wsman, используется команда

Test-WSMan: Test-WSMan -ComputerName someserver

Более подробно обо всех командах WS-Man можно узнать (см. экран), запросив справку командой:

help about_WS-Management_Cmdlets

Экран. Список команд WS-Management

WS-MAN и Linux

Теперь перейдем к самому интересному разделу — к возможностям получения информации о настройках при помощи WS-Man из систем Linux. Прежде всего рассмотрим архитектуру решения, которое необходимо настроить для этой задачи. Состоит она из трех компонентов.

• openwsman (http://www.openwsman.org/). Серверное программное обеспечение, реализующее коммуникацию с клиентом посредством протокола WS-Management.
• SBLIM SFCB (http://sourceforge.net/apps/mediawiki/sblim/index.php? title=Sfcb). Серверное программное обеспечение, реализующее CIM.
• SBLIM SFCC (http://sourceforge.net/apps/mediawiki/sblim/index.php? title=Sfcc). Клиент для SBLIM SFCB.

В конечном итоге архитектура выглядит так, как показано на рисунке 3. Проще говоря, при обращении по протоколу WS-Management сервер openwsman обрабатывает полученный запрос, при помощи клиента SFCC обращается к серверу SFCB за данными CIM. Затем эти данные преобразуются к нужному виду и отправляются в ответ. С другой стороны, в этой архитектуре мы имеем возможность обратиться к серверу SFCB самостоятельно, но уже по протоколу WBEM/CLI-XML и получить те же данные.

Рисунок 3. Архитектура решения WS-Man для Linux

При настройке я использовал последний доступный дистрибутив CentOS и RPM-пакеты SFCB и Openwsman. Последний уже имеет в своем составе sfcc, поэтому отдельно устанавливать его не нужно. Настройка сервера openwsman и SFCB проста: листинг 4 содержит параметры openwsman, а листинг 5 — параметры sfcb.

Обратите внимание на выделенную запись в листинге 4. Она сообщает openwsman, что он должен использовать sfcc/sfcb для получения данных CIM. Кроме того, вместе с пакетами устанавливаются сценарии генерации ключей для соединений HTTPS. Без сгенерированных и установленных ключей эти серверы не запускаются. Однако и тут не все гладко.

Сценарий для sfcb отказался работать в каталоге, в который он установлен по умолчанию. Нормально он отработал только в корневом каталоге и там же создал нужные файлы сертификатов и ключа. Затем эти файлы необходимо перенести в каталог с файлом конфигурации, поскольку путь к ним прописан именно здесь. Кроме того, нужно сгенерировать файлы паролей для аутентификации basic и digest. Для генерации файлов паролей используются утилиты htpasswd и htdigest соответственно.

Итак, нужное программное обеспечение на системе Linux настроено, соответствующие порты открыты, приступаем к тестам. И вот здесь снова начинаются проблемы. Самая первая — мне не удалось применить аутентификацию digest. При использовании аутентификации basic и http имеем следующее: проверяем наличие WS-Man (листинг 6), получаем данные — листинг 7. Похоже, работает. Однако попытка проверить соединение из PowerShell при помощи

Test-WSMan -ComputerName 192.168.1.35 Authentication Basic -Credential (Get-Credential)

приводит к ошибке аутентификации. То же самое происходит со всеми попытками получить данные. Как же так? Здесь я поломал голову. На этот раз проблема уже на стороне Windows, а именно в реализации команд PowerShell в части аутентификации basic.

Эта проблема существует уже давно и подробно описана (http://blog.whatsupduck.net/2009/09/not-using-PowerShell-v2 to-view-wsman.html). Вкратце, она заключается в том, что внутренняя реализация запроса вставляет перед именем пользователя символ ‘’. К сожалению, эта ошибка до сих пор не исправлена.

Но, несмотря на это, получить данные можно. Для этого задействуем метод, основанный на использовании COM-объекта WSMan.Automation. В этом случае мы вручную создаем объекты подключения и настроек подключения с нужными флагами. Затем устанавливаем соединение и запрашиваем данные. В этом случае аутентификация проходит нормально, и данные возвращаются корректно. Исходный код сценария представлен в листинге 8.

В конечном итоге можно отметить, что Microsoft в некотором смысле идет навстречу ИТ-сообществу, реализуя стандарты, позволяющие организовать мониторинг и управление различными платформами. Справедливости ради надо сказать, что многие крупные производители программного и аппаратного обеспечения стали активно использовать стандарты DMTF в своих продуктах. Это предоставляет широкие возможности для консолидации управления большим количеством программных и аппаратных ресурсов в единой точке. Однако в этом направлении еще предстоит большая работа.

Листинг 1. Сценарий для запроса данных с WBEM-сервера без аутентификации

cls $server = ‘192.168.1.35’ #адрес сервера $port = ‘5988’ # порт сервера [string]$data = Get-Content -Path c:toolsquery5.xml [system.Net.ServicePointManager]::Expect100Continue = $false; #отключаем ненужный заголовок [System.Text.ASCIIEncoding] $ASCIIEncoding = new-object System.Text.ASCIIEncoding [system.byte[]] $bytes = $ASCIIEncoding.GetBytes($data) [System.Net.WebClient]$client = New-Object System.Net.WebClient $client.Headers.Add(«Content-Type»,»application/xml; charset=utf-8″) $client.Headers.Add(«CIMProtocolVersion», «1.0») $client.Headers.Add(«CIMOperation», «MethodCall») $client.Headers.Add(«CIMMethod», «EnumerateInstances») $client.Headers.Add(«CIMObject», «root%2Fcimv2») [System.Byte[]]$b = $client.UploadData(«http://$server`:$port/cimom»,’POST’,$bytes) [System.Text.ASCIIEncoding] $ASCIIEncoding = new-object System.Text.ASCIIEncoding [xml]$MyString = $ASCIIEncoding.GetString($b);
Листинг 2. Запрос EnumerateInstances класса CIM_OperatingSystem

Листинг 3. Разобранный ответ сервера на запрос EnumerateInstances класса CIM_OperatingSystem
PctTotalCPUTime 1 DefaultPageSize 4096 CodeSet ANSI_X3.4-1968 LanguageEdition en-US TransitioningToState 12 TimeOfLastStateChange EnabledDefault 2 RequestedState 2 OtherEnabledState NULL EnabledState 2 PrimaryStatus OperatingStatus DetailedStatus CommunicationStatus HealthState 5 Status NULL InstallDate InstanceID Caption Operating System Description A class derived from OperatingSystem to represents the running Linux OS.

ElementName CentOS release 5.5 (Final) CSCreationClassName Linux_ComputerSystem CSName localhost.localdomain CreationClassName Linux_OperatingSystem Name localhost.localdomain OSType 36 OtherTypeDescription NULL Version CentOS release 5.5 (Final) LastBootUpTime 20101230204002.000000+120 LocalDateTime 20110103225947.000000+120 CurrentTimeZone 120 NumberOfLicensedUsers 0 NumberOfUsers 3 NumberOfProcesses 144 MaxNumberOfProcesses 16384 TotalSwapSpaceSize 2096472 TotalVirtualMemorySize 3131580 FreeVirtualMemory 2504468 FreePhysicalMemory 428692 TotalVisibleMemorySize 1035108 SizeStoredInPagingFiles 2096472 FreeSpaceInPagingFiles 2075776 MaxProcessMemorySize 4294967295 Distributed FALSE MaxProcessesPerUser 16384
Листинг 4. Файл конфигурации openwsman.conf

[server] port = 5985 ipv4 = yes ipv6 = yes ssl_cert_file = /etc/openwsman/servercert.pem ssl_key_file = /etc/openwsman/serverkey.pem digest_password_file = /etc/openwsman/digest.passwd basic_password_file = /etc/openwsman/simple_auth.passwd min_threads = 4 max_threads = 0 max_connections_per_thread=20 [cim] default_cim_namespace = root/cimv2 cim_client_frontend = SfcbLocal vendor_namespaces = OpenWBEM=http://schema.openwbem.org/wbem/wscim/1/cim-schema/ 2,Linux=http://sblim.sf.net/wbem/wscim/1/cim-schema/2,OMC=http://schema.omc-project.org/ wbem/wscim/1/cim-schema/2,PG=http://schema.openpegasus.org/wbem/wscim/1/cim-schema/2
Листинг 5. Файл конфигурации sfcb.cfg

enableHttp: true httpPort: 5988 httpUserSFCB: true httpProcs: 8 httpLocalOnly: false useChunking: true doBasicAuth: false basicAuthLib: sfcBasicPAMAuthentication provProcs: 32 maxMsgLen: 10000000 registrationDir: /var/lib/sfcb/registration providerDirs: /usr/lib/sfcb /usr/lib /usr/lib/cmpi enableInterOp: true providerSampleInterval: 30 providerTimeoutInterval: 60 providerAutoGroup: true validateMethodParamTypes: false providerDefaultUserSFCB: true enableHttps: true httpsPort: 5989 httpsProcs: 8 sslKeyFilePath: /etc/sfcb/file.pem sslCertificateFilePath: /etc/sfcb/server.pem sslClientCertificate: ignore sslClientTrustStore: /etc/sfcb/client.pem certificateAuthLib: sfcCertificateAuthentication
Листинг 6. Проверка наличия WS-Man при помощи winrm
Листинг 7. Результат WS-MAN-запроса к Linux-системе при помощи winrm
Листинг 8. Сценарий для работы с WS-MAN при помощи COM объекта WSMan

Источник: www.osp.ru

Возможности настройки привилегии и безопасности интерфейса WMI

Давным-давно, когда трава была зеленее, а интернет безопаснее, в ИТ родилась инициатива Web Based Enterprise Management (WBEM). Первоначально спонсируемая в 1996 году такими компаниями как Cisco Systems, Intel и Microsoft, она получила широкое распространение и реализацию на различных платформах: от MAC OS до Redhat. WBEM четко документирован, основан на стандартах Интернета и представляет собой иной подход к управлению системами, отличный, например, от SNMP протокола.

Адаптация WBEM для Windows получила название WMI (Windows management interface) и впервые была представлена в Windows XP. Нам известно, что системы обновляются быстрее, чем их компоненты и многие уязвимости, бывшие ранее удобным инструментом управления, кочуют из версии в версию. В этой статье я хочу описать как выполняются задачи WMI и как избежать потенциальных рисков.

В силу своей мощности, WMI позволяет с помощью специальных утилит или сценариев производить различные потенциально опасные действия на ПК, в том числе, остановку критичных для работы служб и даже выключение компьютера. Например, так:

(Get-WmiObject Win32_OperatingSystem -EnableAllPrivileges).Win32Shutdown(5)

(GWMI -Class Win32_Service -Filter «name=’WinRM’» -ComputerName Server).StopService()

Кроме того, на удаленной машине эти действия выполнить так же просто, как на локальной — достаточно написать имя нужной машины в пути к WMI-объекту.

Пространство имен WMI – это раздел репозитория WMI, который призван группировать классы и объекты WMI по назначению, плюс, определять атрибуты безопасности при доступе к классам и объектам в каждом таком контейнере. Все пространства имен начинаются с корня, который в WMI обозначается ключевым словом root. После имени корня через косую черту указывается пространство имен. Пространства имен могут быть вложенными. Большинство интересных классов и объектов размещается в пространстве имен root/CIMv2.

Одно из существующих в Windows пространств имен WMI может быть выбрано по умолчанию. Это означает, что если вы попытаетесь подключиться к этому хосту, не указав пространство имен, то вы автоматически будете подключены к выбранному по умолчанию. В стандартной инсталляции Windows по умолчанию выбрано пространство rootcimv2.

Технология WMI предназначена для администраторов Windows, и вся система безопасности в WMI устроена так, чтобы с помощью сценариев WMI пользователь мог на заданном ПК выполнить лишь те действия, на которые ему даны разрешения/привилегии. Это так называемые привилегии по умолчанию. Так реализуется безопасность WMI на уровне операционной системы: если пользователю на уровне операционной системы не дана привилегия перезагружать компьютер, то и с помощью WMI он и не сможет этого сделать.

Дополнительные политики безопасности в WMI реализованы на уровне пространств имен протокола Distributed СОМ (DCOM) – распределенной объектной модели компонентов. Чтобы более подробно рассмотреть эти типы безопасности WMI, кратко напомню основные общие понятия, связанные с безопасностью в Windows. А основана эта безопасность на именах пользователей и их паролях.

О разрешениях WMI

Когда в Windows создается пользователь, его системной учетной записи присваивается уникальный идентификатор безопасности (Security IDentifier или SID). На основе SID для пользователя формируется маркер доступа (Access Token), в который также добавляется список групп, членом которых является пользователь и список привилегий, которыми он обладает (например, остановка служб или выключение компьютера). Этот маркер доступа присваивается также всем процессам, которые запускает пользователь. В это время каждый объект операционной системы, доступ к которому определяет система безопасности – файл, либо процесс, либо служба или что-то ещё, имеет дескриптор безопасности (Security Descriptor, SD). В этом дескрипторе, в свою очередь, хранится список контроля доступа (Access Control List, ACL) для этого объекта.

Итак, при обращении пользователя или запущенного им процесса к объекту происходит сравнение маркера доступа данного пользователя со списком контроля доступа. В зависимости от результатов выдается или отклоняется разрешение/привилегия на выполнение запрашиваемых действий над объектом.

На уровне пространств имен механизм безопасности WMI соответствует общей модели безопасности Windows. Каждое пространство имен может иметь собственный дескриптор безопасности, на котором хранится список контроля доступа (ACL).

Каждая запись списка контроля доступа (Access Control Entry, АСE) содержит информацию о том, какие разрешения имеет определенный пользователь при выполнении различных операций в этом пространстве имен.

А вот и список разрешений при работе с пространством имен:

Выполнение методов (Execute Methods). Позволяет вызывать методы классов из определенного пространства имен. Будет ли метод выполнен или произойдет отказ, зависит от того, имеет ли пользователь разрешение на выполнение этой операции в системе.

Полная запись (Full Write). Разрешает создавать и модифицировать подпространства имен, системные классы и экземпляры классов.

Частичная запись (Partial Write). Открывает возможность создавать и модифицировать любые статические классы и экземпляры несистемных классов.

Запись поставщика (Provider Write). Позволяет записывать в репозиторий CIM классы провайдеров WMI и экземпляры этих классов.

Включить учетную запись (Enable Account). Предоставляет право чтения пространства имен WMI. Пользователи с этим разрешением, могут запускать на локальном компьютере сценарии, которые читают данные WMI.

Включить удаленно (Remote Enable). Разрешает пользователям получить доступ к пространству имен WMI на удаленном компьютере. По умолчанию этим разрешением обладают только администраторы, обычные пользователи не могут получать данные WMI с удаленных машин.

Прочесть безопасность (Read Security). Дает право читать дескриптор безопасности для пространства имен WMI без возможности его модификации.

Изменение правил безопасности (Edit Security). Позволяет изменять дескриптор безопасности для пространства имен WMI.

Все эти записи списка контроля доступа хранятся в репозитории WMI. Разрешения WMI для конкретного пространства имен применяются ко всем подпространствам имен и классам, которые определены в этом пространстве (наследуются ими). Собственные же разрешения безопасности для отдельного класса WMI определить нельзя.

О настройке по умолчанию

В Windows группа администраторов обладает всеми разрешениями из таблицы выше, а для остальных пользователей включена учетная запись (Enable Account), разрешено вызывать методы (Execute Methods) и записывать в CIM экземпляры классов провайдеров (Provider Write).

Администратор может изменить разрешения для определенных пользователей с помощью утилиты для настройки параметров WMI (оснастка wmimgmt.msc консоли управления ММС).

Скриншот 1.

Для доступа к инфраструктуре WMI на удаленном компьютере используется вышеуказанный протокол DCOM. Пользователь запускает сценарий или подключается к WMI с помощью специальных утилит и выступает в качестве клиента, а объект WMI, к которому идет обращение, является сервером. Чтобы определить, какой маркер доступа будет применяться при работе с WMI на удаленном компьютере, используются стандартные уровни имперсонации протокола DCOM.

Об имперсонации или Impersonation Levels

По-русски звучит несколько коряво. Что такое имперсонация и зачем она нужна? Это метод, при котором для подключения к ресурсу процесс или система должны использовать не свой контекст безопасности, а учетные данные другого субъекта безопасности.

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

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

Еще для этого контекст безопасности службы должен обладать привилегией создания маркеров доступа.

Бывает более сложный вариант имперсонации – делегирование. Этот вариант необходим тогда, когда подключение к конечному ресурсу выполняется не самим субъектом безопасности (в примере выше – службой от лица пользователя), а через посредника (например, промежуточный сервер).

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

В случае с WMI делегирование может выглядеть так: мы, работая на станции администратора, подключаемся по WMI к некому серверу и запускаем на нем процесс с помощью метода Execute класса Win32_Process. Этот процесс не что иное, как другой скрипт WMI, который подключается к ещё одному хосту в сети для того, чтобы совершить какие-то действия. Если мы не воспользуемся делегированием, то на конечной машине скрипт будет запущен в контексте безопасности учетной записи промежуточного сервера, что далеко не всегда желаемо. С другой стороны, подобная ситуация с делегированием в реальной жизни случается достаточно редко.

Об уровнях Impersonation Levels

Анонимный доступ (Anonymous). Объект-сервер не имеет права получить информацию о пользователе или процессе, который обращается к данному объекту (иными словами, объект не может олицетворить клиента). Этот уровень олицетворения в WMI не используется.

Идентификация (Identify). Объект-сервер может запросить маркер доступа, связанный с клиентом, но не может произвести олицетворение.

В сценариях WMI этот уровень олицетворения используется редко, в этом случае нельзя запускать сценарии WMI на удаленных машинах.

Олицетворение (Impersonate). Объект-сервер может пользоваться всеми правами и привилегиями, которыми обладает клиент. В сценариях WMI рекомендуется использовать именно этот уровень олицетворения, ибо в таком случае сценарий WMI на удаленной машине сможет выполнять все действия, которые разрешено осуществлять пользователю, запустившему этот сценарий.

Делегирование (Delegate). Объект на сервере, к которому обращается клиент, может обратиться от имени клиента к другому объекту на другом сервере. Делегирование позволяет сценарию использовать на удаленной машине маркер доступа запустившего его пользователя. Тот же маркер используется для доступа к объектам WMI на других рабочих станциях. Применение данного уровня олицетворения связано с потенциальным риском, делегирование в сценариях WMI следует применять только в случае особой необходимости.

Выбираемый по умолчанию уровень олицетворения зависит от версии WMI на целевом компьютере. В версиях WMI ниже 1.5 по умолчанию используется уровень Идентификация (Identify), в версии WMI 1.5 и выше —Олицетворение (Impersonate). При необходимости можно изменить уровень олицетворения по умолчанию — для этого необходимо записать наименование нужного уровня (например, impersonate или Delegate) в ключ реестра
HKEY_LOCAL_MACHINESoftwareMicrosoftWbemScriptingDefault Impersonation Level.

Скриншот 2.

Протокол DCOM также предоставляет возможность запросить для соединения WMI определенный уровень аутентификации (проверки подлинности) и конфиденциальности:

Отсутствует (None). Проверка подлинности отсутствует.

По умолчанию (Default). Для выбора уровня проверки подлинности используются стандартные настройки безопасности. Рекомендуется использовать именно этот уровень, так как к клиенту будет применен уровень проверки подлинности, который задается сервером.

Подключений (Connect). Клиент проходит проверку подлинности только во время подключения к серверу. После того как соединение установлено, никаких дополнительных проверок не производится.

Вызовов(Call). Клиент проходит проверку подлинности в начале каждого вызова, во время приема запросов сервером. При этом заголовки пакетов подписываются, однако сами данные (содержимое пакетов), передаваемые между клиентом и сервером, не подписываются и не шифруются.

Пакет (Pkt). Проверке подлинности подвергаются все пакеты данных, которые поступают серверу от клиентов. Как и при проверке подлинности на уровне вызовов, заголовки пакетов подписываются, но не шифруются. Сами пакеты не подписываются и не шифруются.

Целостности пакетов (Pktlntegrity). Все пакеты данных проходят проверку подлинности и целостности. Проверяется, что содержимое пакета не было изменено во время передачи от клиента серверу. При этом данные подписываются, но не шифруются.

Привилегии (PktPrivacy). Все пакеты данных проходят проверку подлинности и целостности, при этом данные подписываются и шифруются, что обеспечивает конфиденциальность передаваемых данных.

Администраторам Windows хорошо известны настройки безопасности системы, доступные в консоли безопасности системы и групповых политиках домена и раздел «User Right Assignments» (привилегии пользователей). Ряд действий с операционной системой можно проделать только при наличии у пользователя или группы, куда он входит, той или иной привилегии. К таким действиям, например, относятся: перезагрузка системы (завершение её работы), восстановление состояния системы из резервной копии или смена системного времени.

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

Резюме

Что предлагается сделать для обеспечения безопасности WMI-подключений:

1. Изменить уровень имперсонации для критичных сервисов (Скриншот 2).
2. Настроить разрешения wmimgmt.msc (Скриншот 1).
3. Изменить репозиторий по умолчанию. Это может нарушить сценарий шаблонных атак.

4. Изменить группы лиц с возможностями удаленного запуска и активации WMI через утилиту DCOMCNFG

5. Чтобы запустить WMI пользователь должен быть членом группы administrators либо DCOM users. Также должна быть доступна служба remote registry.

6. Настроить файервол – входящие подключения к DCOM идут по 135 TCP-порту и (имеют?) динамический диапазон RPC.

В заключение хочу сказать следующее: WMI дает скорость, мощь и легкость запуска команд на удаленных хостах, а SQL based-семантика команд делает его легким для освоения.

В интернете очень много информации о взломах и WMI-атаках, ведь они вписываются в нынешний атакующий тренд – использование нативных инструментов взлома системы – наряду с telnet NTP и DNS. Наша задача — этот тренд уловить и найти методы противодействия уже заложенные в систему.

• Блог компании InfoWatch
• Информационная безопасность

Источник: habr.com

Wbem что за программа

Web-Based Enterprise Management ( WBEM ) is a set of management and Internet-related technologies intended to unify the management of enterprise computing environments. Developed by the Distributed Management Task Force ( DMTF ), WBEM enables organizations to deliver an integrated set of standards-based management tools that support and promote World Wide Web technology. The DMTF has developed a set of standards that make up WBEM . This set of standards includes:

Common Information Model ( CIM )

CIM is an object-oriented data model that describes the overall management of information in an enterprise network environment. CIM consists of a CIM specification and a CIM schema:

CIM Specification Consists of the language and methodology that describes management data.

CIM Schema Provides actual model descriptions of systems, applications, large area networks, and devices. The CIM Schema enables applications from different developers on different platforms to describe management data in a standard format. As a result, a variety of management applications can share this information.

CIM Operations Over HyperText Transport Protocol ( HTTP ) 1.1 is a transport mechanism that maps CIM operations to HTTP to allow implementations of CIM to interoperate in an open, standardized manner.

CIM Operations Over HTTP 1.1 uses eXtensible Markup Language ( XML ), which is a markup language that represents management information in textual form.

In addition to the XML representation, CIM information is also represented textually by the managed object format ( MOF ). These MOF representations are typically stored as text files that developers compile into a CIM Object Manager.

WBEM Tools and Services

Tools and services that enable developers to create and Services management applications and instrumentation that manage heterogeneous computer environments include:

* Solaris WBEM Services

* Solaris WBEM Software Development Kit ( SDK )

Solaris WBEM Services

These services consist of a set of value-added Services components. These services make it easier for developers to create management applications that run in the Solaris operating environment. They also make the Solaris operating environment easier to manage. Solaris WBEM Services consists of:

* CIM Object Manager, CIM Repository, and MOF Compiler

* CIM and Solaris Schema, which is an extension schema of CIM . CIM and Solaris Schema is a collection of CIM classes that describe managed elements in the Solaris operating environment. These classes are available from the CIM Object Manager at start up.

* Solaris Providers, which are programs that communicate information between the Solaris operating environment and the CIM Object Manager (providers get and set dynamic information about managed elements, acting as an intermediary between the CIM Object Manager and the managed elements).

Solaris software providers have been developed for a variety of areas: users, roles, file systems, and network configuration, for example. A remote provider is also available to distribute agents away from the CIM Object Manager when required. Because of the incremental development capabilities of the WBEM instrumentation framework, developers can progressively and consistently add more providers for additional Solaris software services.

* SNMP Adapter for WBEM , which enables Simple Network Management Protocol ( SNMP ) management applications to access system management information that is provided by Solaris WBEM Services. Used with the Solstice Enterprise Agent ( SEA ) Master Agent snmpdx (1M), the SNMP Adapter for WBEM maps SNMP requests into equivalent WBEM Common Information Model ( CIM ) properties or instances.

The SNMP Adapter for WBEM also remaps the response from the CIM Object Manager into an SNMP response, which is returned to the management application.

A mapping file contains the corresponding Object Identifier ( OID ), class name, property name, and Abstract Syntax Notation One ( ASN .1) type for each object. Developers can create their own mapping files.

* SNMP Provider, which enables WBEM services to deliver SNMP information.

Solaris WBEM SDK

The Solaris WBEM SDK is a set of application programming interfaces ( API s) that contain the components necessary to write management applications. These applications communicate with WBEM -enabled management devices by using XML and HTTP communication standards.

Solaris WBEM applications request information or services from the Common Information Model ( CIM ) Object Manager through the WBEM API s. These API s represent CIM objects as Java classes. The API s are used to describe managed objects and to retrieve information about managed objects in a system environment. The advantage of modeling managed resources by using CIM is that those objects can be shared across any system that is CIM -compliant.

For more information on the Solaris WBEM SDK , see the Solaris WBEM Developer’s Guide. The Solaris WBEM API documentation is available in Javadoc format with the Solaris OS installation at /usr/sadm/lib/wbem/doc/index.html .

Compatibility of Solaris WBEM Services with Existing Protocols

Adapters and converters enable Solaris WBEM Services of Solaris to work compatibly with existing protocols by mapping WBEM information to these protocols. One such protocol is Simple Network Management Protocol ( SNMP ).

Legacy management applications can administer WBEM -enabled software in the Solaris operating environment. Developers can write agents or providers that convert information from these protocols to WBEM , and they can write adapters that convert WBEM information into these protocols.

ATTRIBUTES

See attributes (5) for descriptions of the following attributes:

ATTRIBUTE TYPE	ATTRIBUTE VALUE
Availability	SPARC and x86
Architecture	SUNWwbapi, SUNWwbcor, SUNWwbcou, SUNWwbdev, SUNWwbdoc, SUNWwbpro
CSI	Enabled

Источник: www.opennet.ru