Служба удаленного управления windows winrm применяет протокол ws management для удаленного управления

Время на прочтение9 мин

Количество просмотров9.8K

Идея написать блог о том, как злоумышленники используют для перемещения в инфраструктуре жертвы возможности службы Windows Remote Management (WinRM) (Т1021.006), возникла у Антона Величко, руководителя Лаборатории компьютерной криминалистики компании F.A.C.C.T., еще в январе 2022 года. И виной тому стали не затянувшиеся новогодние праздники и наличие свободного времени, как может показаться, а как раз наоборот. В тот момент криминалисты F.A.C.C.T. столкнулись с очередным «праздничным» всплеском кибератак на российские компании, и в процессе реагирования на инцидент у одного из наших клиентов обнаружили интересный кейс, о котором Антон Величко и его соавтор — Кирилл Полищук захотели подробно рассказать.

Незваные гости

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

После очередной атаки IT-специалисты восстанавливали и перестраивали инфраструктуру, а спустя какое-то время злоумышленники возвращались, и атака повторялась снова. Таким образом, злоумышленники не только планомерно разрушали бизнес-процессы компании, но и превратили в ад жизнь IT-персонала, который любой малейший сбой в том или ином отделе воспринимал как очередной инцидент информационной безопасности и «невидимую руку хакеров».

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

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

Для перемещений по сети злоумышленники преимущественно использовали протокол удаленного рабочего стола (Remote Desktop Protocol), а после того как он был запрещен администраторами, переключились на WinRM. Использование злоумышленниками данной службы и наличие недокументированного и ранее не описанного артефакта, который был впервые обнаружен в ходе нашего реагирования, позволили выявить и дополнить список скомпрометированных узлов и лишить злоумышленников возможности взаимодействовать с сетью клиента.

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

Краткая справка о WinRM

WinRM — это название как службы, так и протокола Windows, разработанного прежде всего для IT-специалистов. Она используется для удаленного управления, администрирования и мониторинга систем. WinRM была впервые представлена в операционной системе Windows Vista в 2006 году и с тех пор интегрирована во все последующие версии Windows.

WinRM является реализацией протокола WS-Management, предназначенного для управления различными устройствами при помощи SOAP-запросов.

Служба WinRM запускается и работает в контексте процесса svchost.exe -k NetworkServices -p -s WinRM.
Начиная с версии 2.0 WinRM, слушатель службы %systemroot%\system32\WsmSvc.dll по умолчанию прослушивает порты 5985/TCP для HTTP-соединений и 5986/TCP для HTTPS-соединений. В Windows Server 2008 / Windows 7 использовались 80/TCP и 443/TCP соответственно.
WinRM поддерживает следующие механизмы аутентификации:
- Basic — для аутентификации клиента и авторизации его запросов к серверу с помощью базовых HTTP-заголовков. Этот механизм аутентификации небезопасный и не рекомендуется к использованию, так как передача учетных данных происходит в явном виде.
- Digest — это механизм аутентификации, который использует HTTP-заголовки для передачи аутентификационных данных между клиентом и сервером с помощью хеш-функции.
- NTLM — для аутентификации клиента по имени пользователя и паролю, если клиент и сервер не являются членами одного домена или если применяется схожий механизм аутентификации.
- Kerberos — для взаимной аутентификации между клиентом и сервером в домене Windows. Клиент и сервер должны быть членами одного домена.
- SSL-сертификаты — для проверки легитимности сервера и клиента при использовании протокола HTTPS. Этот механизм аутентификации обеспечивает безопасность передаваемых данных посредством шифрования.
- CredSSP — для делегирования учетных данных на сервер, который может их использовать для выполнения задач на удаленных компьютерах.
WinRM позволяет создать список доверенных узлов.
WinRM позволяет устанавливать продолжительные интерактивные сеансы с удаленным хостом, выполнять отдельные команды, скрипты, а также запросы WMI (CIM).

Выполнение PSRP, WinRS, CIM over WinRM

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

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

PowerShell Remoting (PSRP)Например:Invoke-Command -ComputerName <RemoteComputer> -Scriptblock {EVIL.exe}Enter-PSSession -ComputerName <RemoteComputer> и др.
Windows Remote Shell (WinRS)Например:winrs -r: <RemoteComputer> EVIL.exe
WMI (CIM) over WinRM (начиная с PowerShell версии 3.0 добавлены командлеты CIM, работа которых осуществляется через WinRM).Например:Invoke-CimMethod -ClassName Win32_Process -MethodName “Create” -ComputerName <RemoteComputer> -Arguments @{CommandLine=’EVIL.exe’} и др.

Процессы, порождаемые PSRP, WinRS, CIM over WinRM

В зависимости от выбранного способа выполнения WinRM передаст управление DCOM-серверу (Distributed Component Object Model), который проведет запуск одного из трех провайдеров:

%systemroot%\system32<b style=»box-sizing: border-box; outline: none; -webkit-tap-highlight-color: transparent; font-weight: bolder;»>wsmprovhost.exe (Microsoft Web Services Management Provider Host);
%systemroot%\system32<b style=»box-sizing: border-box; outline: none; -webkit-tap-highlight-color: transparent; font-weight: bolder;»>winrshost.exe (Microsoft Windows Remote Shell Host);
%systemroot%\system32<b style=»box-sizing: border-box; outline: none; -webkit-tap-highlight-color: transparent; font-weight: bolder;»>wmiprvse.exe (Windows Management Instrumentation Provider Host).

Таким образом, процесс того или иного провайдера будет запущен в контексте процесса svchost.exe -k -DcomLaunch -p, который, в свою очередь, станет родительским для порождаемой полезной нагрузки.

На рис. 1, 2 и 3 представлены цепочки процессов, возникающие при использовании PowerShell Remoting, Windows Remote Shell, а также при выполнении CIM-запросов.

Рис 1. Цепочка процессов при использовании PowerShell Remoting

Рис 2. Цепочка процессов при использовании WinRS

Рис 3. Цепочка процессов при использовании CIM-запросов

Инструменты Red Team

При WinRM-перемещениях по хостам атакуемой инфраструктуры злоумышленники используют не только легитимные средства, но и различные инструменты или фреймворки, в которых реализована возможность взаимодействия с WinRM. Список некоторых инструментов и фреймворков представлен ниже.

Evil-WinRM

Metasploit Framework

Cobalt Strike

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

Теперь рассмотрим небольшую эмуляцию, проделанную при помощи Evil-WinRM, и проведем реконструкцию активности на хосте по записям журналов событий.

В рамках данной эмуляции мы подключились к контроллеру домена, выполнили команды whoami, hostname, загрузили в него файл evil.exe и запустили его (рис. 4).

Рис. 4. Действия с хоста атакующего

В данном случае, при реконструкции действий атакующего, в журналах атакуемой ОС мы обнаружим список характерных событий, указывающих на использование PowerShell Remoting. Наиболее информативные из них, по моему мнению, представлены ниже.

Описание	ID события
1. События с назначенными привилегиями и нового входа с Logon ID, именем пользователя и адресом удаленного хоста	4672, 4624 (Security.evtx)
2. Событие запуска провайдера wsmprovhost.exe и оболочки WS-Man	4688 (Security.evtx) 91 (Microsoft-Windows-WinRM%4Operational.evtx)
3. События запуска процессов whoami.exe, hostname.exe, порождаемых от провайдера (оболочки) wsmprovhost.exe	4688 (Security.evtx) 400, 800 (Windows PowerShell.evtx) 4103, 4104 (Microsoft-Windows-PowerShell%4Operational.evtx)
4. Вызовы командлетов и создание блоков скрипта при доставке полезной нагрузки evil.exe	4103, 4104 (Microsoft-Windows-PowerShell%4Operational.evtx)
5. События запуска процесса evil.exe, порождаемого от провайдера (оболочки) wsmprovhost.exe	4688 (Security.evtx) 800 (Windows PowerShell.evtx) 4103, 4104 (Microsoft-Windows-PowerShell%4Operational.evtx)

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

Ни для кого не секрет, что атакующие для противодействия обнаружению и усложнения задач реагирующему специалисту довольно часто очищают журналы событий. Очистку журналов они могут осуществлять как штатными средствами ОС, так и с помощью функциональных возможностей, реализованных в используемых ими инструментах. И в этих условиях специалист будет вынужден погрузиться в более глубокий анализ различных источников криминалистических данных, таких как AmCache, ShimCache, SRUDB, $MFT и многих других. Но среди них не так много источников, которые позволят нам оттолкнуться и «пойти» в сторону точки входа.

Так, однажды погрузившись в исследование, нами был обнаружен параметр реестра WSManSafeClientList, который позволяет не только выявить технику продвижения, но и ряд потенциально эксплуатируемых атакующими узлов (рис. 5).

Рис.5. Список «безопасных» клиентов

Список «безопасных» клиентов

Параметр реестра WSManSafeClientList появился в системах с момента появления Windows 8 и располагается по пути HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WSMAN\SafeClientList. В него сохраняются IP-адреса успешно подключавшихся с помощью WinRM клиентов. А запись в него осуществляется слушателем службы WsmSvc.dll.

Проведенными исследованиями установлено, что:

параметр WSManSafeClientList отсутствует на хостах, к которым подключения не осуществлялись (в том числе когда служба WinRM сконфигурирована и запущена);
в параметр WSManSafeClientList записываются HEX-значения адресов IPv4 и IPv6, ранее подключавшихся при помощи WinRM;
максимальный размер параметра составляет 160 байт и может содержать до 10 уникальных IP-адресов;
размер каждой записи составляет 16 байт (рис. 6).

Рис. 6. Пример 10 записей параметра WSManSafeClientList и их интерпретация

Запись адресов в параметр WSManSafeClientList осуществляется спустя 15 минут после успешного подключения с адреса, которого нет среди ранее записанных адресов, или в момент остановки службы.

В случае если адрес последнего подключившегося хоста уже имеется в списке, то порядок адресов в параметре не меняется и запись в него не производится.

При превышении количества записей в параметре первый адрес в списке будет удален, а новый — добавлен в конец списка (рис. 7).

Рис. 7. Пример 10 записей параметра WSManSafeClientList после превышения лимита записей

Выводы и рекомендации

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

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

Регулярно осуществляйте установку критических обновлений операционной системы и используемых программных продуктов.
Обеспечьте надежную защиту средств удаленного доступа в ИТ-инфраструктуру, в том числе с помощью мультифакторной аутентификации.
Глубина хранения журналов событий операционной системы и средств защиты информации должна быть не менее 3 месяцев.
Настройте сбор Windows событий:
1. успешных и неуспешных попыток входа;
2. включение/отключение учетных записей, их блокировка;
3. создание локальных и доменных учетных записей;
4. добавление пользователей в группы, особенно предоставляющие повышенные привилегии;
5. создание служб, процессов и задач в планировщике;
6. изменение доменных и локальных политик безопасности;
7. выполнение команд, при помощи различных командных интерпретаторов;
8. критические срабатывания встроенного защитника Windows (Windows Defender);
9. доступа к объектам общей сетевой папки;
10. очистки журналов событий.
Обеспечить защиту конечных устройств поможет решение F.A.C.C.T. Managed XDR, а Attack Surface Management — позволит контролировать уровень информационной безопасности инфраструктуры организации.
Чтобы сформировать надежную, эффективную на практике защиту потребуются не только временные и материальные затраты, но и четкий список того, что необходимо улучшать или строить заново для успешного противостояния современным угрозам. Составить такой перечень поможет комплекс услуг Лаборатории компьютерной криминалистики компании F.A.C.C.T. по оценке готовности компании к реагированию на инциденты, а также проведение киберучений в формате Purple Teaming.

Источник

Эффективное управление ИТ начинается с наличия правильных инструментов для контроля за системами и устройствами, независимо от их местонахождения. Windows Remote Management (WinRM) — это инструмент, который помогает ИТ-администраторам выполнять важные задачи, такие как устранение неполадок, настройка и автоматизация, без физического присутствия.

WinRM встроен в системы Windows, что делает его доступным и мощным вариантом для организаций по поддержанию своей ИТ-инфраструктуры. Обеспечивая безопасную связь и удаленные операции, он играет важную роль в повышении производительности ИТ-команд и обеспечении бесперебойной работы.

В этом блоге объясняются ключевые аспекты WinRM: от его функций и настройки до возникающих проблем.

Что такое удаленное управление Windows (WinRM)?

Windows Remote Management (WinRM) — это протокол на базе Windows, разработанный для упрощения удаленного управления и автоматизации. Он построен на протоколе WS-Management — общедоступном стандарте для удаленного обмена данными управления с любым компьютерным устройством, реализующим этот протокол.

Протокол WS-Management обеспечивает совместимость между устройствами и системами. Он полезен в сочетании с удаленным управлением PowerShell, что позволяет администраторам управлять несколькими устройствами с помощью скриптов и команд.

Цель WinRM

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

Совместимость

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

Почему важен протокол WinRM?

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

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

WinRM — это инструмент командной строки, встроенный в операционные системы Windows, который использует .NET и PowerShell. Это позволяет выполнять удаленные команды и скрипты PowerShell как на отдельных машинах Windows, так и на больших наборах удаленных систем без необходимости использования RDP или прямого входа.

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

Удаленный мониторинг, управление и настройка серверов, операционных систем и клиентских машин.
Общайтесь и взаимодействуйте с хостами по всей сети, включая рабочие станции, серверы и любые операционные системы, поддерживающие WinRM.
Выполнять команды в системах, доступных через сеть, без физического присутствия.

Основные компоненты удаленного управления Windows (WinRM)

Основа WinRM основана на следующих основных компонентах. Эти компоненты работают вместе, чтобы обеспечить удаленное управление системами Windows, облегчить задачи автоматизации и обеспечить безопасное удаленное выполнение команд.

1. Служба WinRM (winrm.exe)

Это основная служба, которая работает на устройствах Windows, позволяя им принимать и отвечать на запросы удаленного управления. Она прослушивает входящие запросы на определенных портах (по умолчанию 5985 для HTTP и 5986 для HTTPS).

2. Прослушиватель WinRM

Прослушиватель отвечает за прием и обработку входящих запросов на удаленное управление. Он прослушивает указанный сетевой порт (5985 для HTTP или 5986 для HTTPS). Каждый прослушиватель привязан к определенному сетевому интерфейсу и протоколу.

3. Инструмент командной строки WinRM (winrm.exe)

Это утилита командной строки, используемая для настройки и управления службой WinRM. Она позволяет администраторам запускать, останавливать или настраивать прослушиватели WinRM, устанавливать политики аутентификации и устранять неполадки в настройках WinRM.

4. Протокол WS-Man (веб-сервисы для управления)

Windows Remote Management основан на протоколе WS-Man, который является стандартом для веб-служб, используемых для управления устройствами. Он позволяет обмениваться данными управления независимо от платформы, обеспечивая связь между компьютерами, устройствами и приложениями независимо от операционных систем.

5. Удаленное взаимодействие PowerShell

PowerShell Remoting построен на WinRM и позволяет администраторам выполнять команды PowerShell на удаленных системах. Он обеспечивает безопасный канал для удаленного выполнения скриптов и команд как на Windows, так и на не-Windows системах (с помощью сторонних инструментов).

6. Аутентификация и шифрование

WinRM поддерживает несколько механизмов аутентификации, включая базовую аутентификацию, Kerberos и NTLM. Он также поддерживает шифрование для безопасного обмена данными между клиентом и сервером, гарантируя защиту конфиденциальных данных во время процесса удаленного управления.

7. Правила брандмауэра

Для правильной работы WinRM необходимо настроить необходимые правила брандмауэра. По умолчанию брандмауэр Windows может блокировать трафик WinRM, поэтому администраторам необходимо разрешить входящий трафик на портах 5985 и 5986 для обеспечения подключения.

Как работает WinRM?

Процесс взаимодействия между клиентом и сервером через удаленное управление Windows обычно состоит из следующих этапов:

Этап 1 — Клиент инициирует запрос: процесс начинается, когда клиент WinRM (например, скрипт PowerShell) отправляет запрос на сервер WinRM. Этот запрос может включать выполнение команды или получение системной информации.

Этап 2 — Аутентификация и авторизация: Сервер должен аутентифицировать клиента перед выполнением любого действия. WinRM поддерживает несколько механизмов аутентификации, включая:

Согласование аутентификации (Kerberos или NTLM)
Базовая аутентификация (учетные данные отправляются в виде обычного текста)
Аутентификация на основе сертификатов (с использованием SSL-сертификатов)

После аутентификации сервер проверяет, есть ли у клиента соответствующие разрешения для выполнения запрошенного действия.

Этап 3 — Обмен данными: Клиент отправляет фактическую команду или запрос после успешной аутентификации. Сервер WinRM обрабатывает этот запрос и возвращает результаты. Данные передаются в формате XML, который понимают как клиент, так и сервер.

Этап 4 — Выполнение команд: Если запрос включает выполнение команды, сервер выполнит команду на удаленной машине. Это может включать вызов скрипта, сбор системной информации или изменение конфигураций.

Этап 5 — Response Sent Back: После завершения задачи сервер отправляет ответ обратно клиенту с результатом операции. Это может включать стандартный вывод выполненных команд, коды ошибок или подтверждение внесенных изменений.

Варианты использования WinRM

1. Удаленное выполнение команд: Системные администраторы могут запускать команды на нескольких удаленных машинах одновременно, что снижает необходимость в физическом доступе.

2. Автоматизированное написание сценариев: WinRM обычно используется в скриптах для автоматизации задач на нескольких компьютерах, таких как установка программного обеспечения, обновления или настройка системы.

3. Управление серверными фермами: WinRM необходим для управления большим количеством серверов в центрах обработки данных, делая управление серверами более эффективным.

4. Аудит безопасности: WinRM можно использовать для сбора данных в целях аудита, например, для проверки системных журналов или просмотра параметров конфигурации.

Преимущества удаленного управления Windows (WinRM)

Удаленное управление Windows (WinRM) обеспечивает ряд существенных преимуществ для ИТ-операций, повышая эффективность, диагностику, экономичность и масштабируемость, особенно в корпоративных средах.

1. Повышенная эффективность

WinRM обеспечивает удаленный доступ к системам, устраняя необходимость в устранении неполадок на месте. Это позволяет ИТ-отделам быстро решать проблемы, сокращая время простоя устройств.

2. Лучшая диагностика

Благодаря подробным возможностям регистрации и мониторинга WinRM помогает быстрее выявлять и решать проблемы. Диагностика в реальном времени минимизирует время простоя, предоставляя ИТ-отделам информацию, необходимую для эффективного устранения неполадок из любого места.

3. Экономически эффективным

WinRM является экономически эффективным решением, сокращая расходы на поездки и оборудование. Удаленная диагностика неисправностей позволяет ИТ-персоналу обрабатывать больше систем с меньшими ресурсами, что сокращает эксплуатационные расходы.

4. Масштабируемость для предприятий

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

Проблемы использования удаленного управления Windows (WinRM)

1. Сложная конфигурация

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

2. Вопросы безопасности

WinRM представляет потенциальные риски безопасности, если не настроен должным образом. Слабые настройки шифрования, неправильная аутентификация или открытые порты могут подвергнуть систему киберугрозам. В ноябре 2024 года Microsoft устранила критические уязвимости в системах Windows, включая те, которые связаны с NTLM и планировщиком заданий. Хотя не все они были напрямую связаны с WinRM, они подчеркивают проблему небезопасных служб удаленного управления.

3. Ограниченная совместимость

WinRM оптимизирован для управления средами Windows, что означает, что он менее эффективен в гетерогенных ИТ-экосистемах, где используются macOS, Linux или мобильные устройства. Хотя существуют обходные пути, такие как использование удаленного PowerShell, они часто добавляют сложности и по-прежнему не полностью решают кросс-платформенное управление, что ограничивает область применения утилиты WinRM.

4. Расходы на устранение неполадок

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

5. Проблемы масштабируемости

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

Scalefusion UEM как лучшая альтернатива — почему?

Хотя Windows Remote Management (WinRM) служит надежным инструментом для управления средами на базе Windows, современные ИТ-технологии требуют более универсальных, масштабируемых и кроссплатформенных решений.

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

1. Кроссплатформенная совместимость

Одним из самых существенных недостатков WinRM является его ограниченная область применения при управлении не-Windows-устройствами. Хотя его можно расширить на некоторые не-Windows-системы с помощью сторонних решений, настройка и управление могут быстро стать громоздкими.

Scalefusion UEM, с другой стороны, предназначен для управления всеми конечными точками, включая Windows, macOS iOS, Android, Linux и ChromeOS с одной платформы. Это делает его гораздо более универсальным решением, особенно в организациях с гетерогенной ИТ-экосистемой.

2. Упрощенная настройка и управление

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

Scalefusion UEM упрощает настройку и предоставляет централизованный и логически организованный интерфейс для управления устройствами, пользователями и политиками. Администраторы могут настраивать политики в одном профиле устройства и применять их к устройствам оптом, что делает управление более эффективным и безошибочным.

3. Повышенная безопасность

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

В отличие от этого, Scalefusion UEM предоставляет расширенные функции безопасности, такие как управление приложениями, настройка шифрования BitLocker, Управление обновлениями и исправлениями ОС, управление браузером, отслеживание местоположения и Geofencing. Он также обеспечивает интеграцию с решениями IAM, такими как OneIdP, и решениями безопасности конечных точек, такими как Veltar. Эти функции гарантируют, что конфиденциальные корпоративные данные и устройства остаются в безопасности на всех устройствах, снижая риск несанкционированного доступа и утечки данных.

4. Масштабируемость для современных предприятий

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

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

5. Эффективное устранение неполадок и удаленная поддержка

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

Scalefusion UEM, с другой стороны, предлагает мощные удаленное устранение неполадок Возможности, такие как удаленная трансляция и управление, вызовы VoIP, передача файлов и подробная информация об устройстве, все в удобном интерфейсе. ИТ-отделы могут быстро выявлять и устранять проблемы с устройством, минимизируя время простоя и повышая общую производительность.

6. Перспективное управление ИТ

Поскольку компании продолжают внедрять новые технологии, Scalefusion UEM предлагает перспективное решение, обеспечивая постоянную поддержку новых устройств и платформ. В отличие от WinRM, который привязан к системам Windows и требует дополнительных настроек для других платформ, Scalefusion UEM изначально разработан для поддержки широкого спектра устройств и технологий. Это делает Scalefusion UEM идеальным выбором для организаций, стремящихся оставаться гибкими и готовыми к будущему в мире все более цифровых технологий.

Вам нужна защищенная и полностью управляемая экосистема Windows?

Здесь ваш поиск заканчивается. Scalefusion UEM для Windows, вы получаете доступ к современным функциям управления, которые делают удаленное управление устройствами более эффективным и быстрым. От управления приложениями до исправления сервера — мы вас обеспечим. Сосредоточьтесь на самом важном — вашем бизнесе — и позвольте нам заняться всем остальным. Управляйте умнее, защищайте лучше и развивайтесь быстрее с ScalefusionUEM!

Свяжитесь с нашими экспертами по продуктам и закажите демонстрацию, чтобы узнать больше о том, как Scalefusion UEM может преобразовать ваше управление конечными точками. Принять участие 14-дневная бесплатная пробная версия Cегодня!

Источник

Это перевод статьи Ondrej Sevecek о настройке удаленного доступа WMI и PowerShell по протоколу WinRM для пользователей без прав администратора.

WinRM, также называемый WSMan, это технология удаленного управления, которая предоставляет для таких средств как WMI, PowerShell, Перенаправление событий (Event Forwarding) и даже Диспетчер сервера (Server Manager) транспорт по протоколу HTTP. WinRM принимает запросы по HTTP или HTTPS протоколу, которые затем передает зарегистрированным в нем провайдерам (плагинам). PowerShell, WMI и Перенаправление событий зарегистрированы в WinRM как соответствующие провайдеры.

Если бы вы были разработчиком клиент-серверного приложения, то вы могли бы создать свой провайдер (плагин) для WinRM, который можно было бы использовать для удаленного управления вашим приложением. Конечно можно и самому написать DCOM или HTTP веб-интерфейс, но WinRM предоставляет стандартный каркас приложения (фреймворк), что облегчает его администрирование.

WinRM поддерживает методы встроенной аутентификации Windows, такие как Kerberos, Negotiate (включая NTLM) и Schannel (сертификаты). Поскольку он использует обычный HTTP, то поддерживаются также методы аутентификации Basic и Digest.

Для удаленного доступа к инструментарию управления Windows (WMI, winmgmt) можно настроить специальный DCOM интерфейс на прием удаленных команд и запросов (WQL), или же использовать WinRM для этого. PowerShell, с другой стороны, не имеет своего собственного сервера, поэтому для приема удаленных команд используются специальные командлеты Enter-PSSession и Invoke-Command, которые передают запросы по WinRM протоколу. PowerShell принимает эти команды, обрабатывает их локально и возвращает ответ по протоколу WinRM.

Таким же образом работает Диспетчер сервера (Server Manager) и Перенаправление событий (Event Forwarding). Хотя у перенаправления событий, есть свой сервис Windows Event Collector (wecsvc), но Microsoft решила использовать WinRM для пересылки сообщений.

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

По умолчанию WinRM запрещает удаленный доступ на системах Windows 2008 R2 и старше. Но его можно включить командой

winrm quickconfig

Начиная с Windows 2012, WinRM разрешает удаленное подключение для аутентифицированных HTTP запросов.

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

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

Дальше будет рассмотрена настройка WinRM 2.0 (входящего в Windows 7 и 2008R2 в составе Windows Management Framework 2.0) и WinRM 3.0 (входящего в Windows 8 и 2012 в WMF 3.0).

Основы WinRM

WinRM является сервисом, запущенным под пользователем NT AUTHORITY\NetworkService. Он принимает запросы от клиентов, аутентифицированных через WIA механизмы: Negotiate, Kerberos, NTLM или Schannel (TLS сертификаты). На серверных ОС сервис стартует автоматически, на клиентских системах его нужно запустить вручную.

Информацию о сервисе можно получить, воспользовавшись командой:

C:\sc query winrm

SERVICE_NAME: winrm
        STATE              : 4  RUNNING

C:\sc qc WinRM

[SC] QueryServiceConfig SUCCESS

SERVICE_NAME: winrm
        TYPE               : 20  WIN32_SHARE_PROCESS
        START_TYPE         : 2   AUTO_START
        ERROR_CONTROL      : 1   NORMAL
        BINARY_PATH_NAME   : C:\Windows\System32\svchost.exe -k NetworkService
        LOAD_ORDER_GROUP   :
        TAG                : 0
        DISPLAY_NAME       : Windows Remote Management (WS-Management)
        DEPENDENCIES       : RPCSS
                           : HTTP
        SERVICE_START_NAME : NT AUTHORITY\NetworkService

C:\sc qsidtype winrm

[SC] QueryServiceConfig2 SUCCESS

SERVICE_NAME: winrm
SERVICE_SID_TYPE:  UNRESTRICTED

Стоит обратить внимание, что сервис работает под собственным пользователем (SID unrestricted), что означает, что можно определять права этому пользователю NT SERVICE\winrm.

Ранее упоминалось, что WinRM использует HTTP протокол, однако напрямую он не взаимодействует с HTTP запросами. Это привело бы к конфликтам с другими веб-сервисами на том же сервере, такими как IIS, SQL Reporting Services или Hyper-V Replication. Поэтому WinRM получает HTTP запросы через системный драйвер HTTP.SYS, также, как и сервисы, указанные выше.

HTTP.SYS это драйвер ядра, который принимает входящий HTTP и HTTPS запрос, обрабатывает некоторые HTTP заголовки (обычно Host Header URL) и перенаправляет запрос к одному из запущенных веб-серверов. HTTP.SYS присутствует в системе независимо от IIS, поэтому когда вы устанавливаете IIS, он регистрирует свои URL в HTTP.SYS. Таким образом, когда HTTP.SYS получает HTTP запрос для одного из зарегистрированных в IIS URL, то он передает его соответствующему рабочему процессу W3SVC пула, если такой запущен, или обращается к Windows Process Activation Service (WAS) для его запуска.

По этой же причине, SQL Server Reporting Services не использует IIS. Он регистрирует свой URL в HTTP.SYS по адресу /Reports и /ReportServer. Другими пользователями HTTP.SYS являются: SSTP VPN сервер (с URL /sra_{BA195980-CD49-458b-9E23-C84EE0ADCD75}) и IPHTTPS сервер (с URL /IPHTTPS).

WinRM регистрирует свой /WSMan URI в HTTP.SYS на нестандартном порту (не 80 TCP).

Посмотреть зарегистрированные в HTTP.SYS URI можно через команду:

C:\netsh http show servicestate

Snapshot of HTTP service state (Server Session View):
-----------------------------------------------------

Server session ID: FF00000320000001
    Version: 1.0
    State: Active
    Properties:
        Max bandwidth: 4294967295
        Timeouts:
            Entity body timeout (secs): 120
            Drain entity body timeout (secs): 120
            Request queue timeout (secs): 120
            Idle connection timeout (secs): 120
            Header wait timeout (secs): 120
            Minimum send rate (bytes/sec): 150
    URL groups:
    URL group ID: FE00000340000001
        State: Active
        Request queue name: Request queue is unnamed.
        Properties:
            Max bandwidth: inherited
            Max connections: inherited
            Timeouts:
                Timeout values inherited
            Number of registered URLs: 1
            Registered URLs:
                http://+:47001/WSMAN/

Request queues:
    Request queue name: Request queue is unnamed.
        Version: 1.0
        State: Active
        Request queue 503 verbosity level: Basic
        Max requests: 1000
        Number of active processes attached: 1
        Process IDs:
            152

Вывод команды показывает настройку WinRM по умолчанию в системе Windows 2008R2. WinRM регистрирует URI /WSMan и привязывает его к порту TCP 47001. Можно посмотреть, что порт действительно прослушивается:

C:\netstat -ano | findstr :47001

  TCP    0.0.0.0:47001          0.0.0.0:0              LISTENING       4
  TCP    [::]:47001             [::]:0                 LISTENING       4

Означает ли это, что WinRM доступен удаленно по этому порту? Если попробовать открыть этот порт в брандмауэре, то подключиться все равно не получится. HTTP.SYS действительно примет запрос пришедший на этот порт, и перенаправит его к WinRM. WinRM проверит, является ли клиент локальным или удаленным, и если клиент удаленный, то WinRM вернет HTTP ошибку со статусом 404 Not Found. Если запрос пришел от локального клиента, то WinRM его примет.

Как было сказано ранее, Windows 2012 принимает по умолчанию удаленные подключения WinRM (параметр AllowRemoteAccess = true в выводе команды ниже). Для удаленных запросов WinRM использует порт TCP 5985, при этом порт 47001 также продолжает прослушиваться. Помимо автоматического запуска сервиса, в брандмауэре открыт доступ на этот порт.

C:\netsh http show servicestate

Snapshot of HTTP service state (Server Session View):
-----------------------------------------------------

Server session ID: FF00000120000001
    Version: 1.0
    State: Active
    Properties:
        Max bandwidth: 4294967295
        Timeouts:
            Entity body timeout (secs): 120
            Drain entity body timeout (secs): 120
            Request queue timeout (secs): 120
            Idle connection timeout (secs): 120
            Header wait timeout (secs): 120
            Minimum send rate (bytes/sec): 150
    URL groups:
    URL group ID: FE00000140000001
        State: Active
        Request queue name: Request queue is unnamed.
        Properties:
            Max bandwidth: inherited
            Max connections: inherited
            Timeouts:
                Timeout values inherited
            Number of registered URLs: 2
            Registered URLs:
                http://+:5985/WSMAN/
                http://+:47001/WSMAN/

Request queues:
    Request queue name: Request queue is unnamed.
        Version: 1.0
        State: Active
        Request queue 503 verbosity level: Basic
        Max requests: 1000
        Number of active processes attached: 1
        Process IDs:
            960

Небольшое уточнение. Существуют два режима работы WinRM: в режиме Service Hosting Model WinRM использует собственный сервис для принятия запросов. Если же запросов становится слишком много, то могут возникнуть проблемы с доступностью. Поэтому существует другой режим работы — через расширение для IIS. Таким образом WinRM становится виртуальной папкой внутри IIS и управляется через IIS (через отдельный рабочий процесс W3SVC). В таком режиме работает Exchange используя WinRM IIS Extension Hosting Model. При запуске удаленных команд, через HTTP.SYS они попадают в виртуальную папку WinRM в IIS на сервере Exchange, и затем в локальный PowerShell.

После HTTP.SYS конфигурации, настало время посмотреть настройки WinRM. Сделать это можно через команду WINRM. Ниже приведены настройки по умолчанию в системе Windows 2008R2:

C:\winrm get winrm/config

Config
    MaxEnvelopeSizekb = 150
    MaxTimeoutms = 60000
    MaxBatchItems = 32000
    MaxProviderRequests = 4294967295
    Client
        NetworkDelayms = 5000
        URLPrefix = wsman
        AllowUnencrypted = false
        Auth
            Basic = true
            Digest = true
            Kerberos = true
            Negotiate = true
            Certificate = true
            CredSSP = false
        DefaultPorts
            HTTP = 5985
            HTTPS = 5986
        TrustedHosts
    Service
        RootSDDL = O:NSG:BAD:P(A;;GA;;;BA)S:P(AU;FA;GA;;;WD)(AU;SA;GWGX;;;WD)
        MaxConcurrentOperations = 4294967295
        MaxConcurrentOperationsPerUser = 15
        EnumerationTimeoutms = 60000
        MaxConnections = 25
        MaxPacketRetrievalTimeSeconds = 120
        AllowUnencrypted = false
        Auth
            Basic = false
            Kerberos = true
            Negotiate = true
            Certificate = false
            CredSSP = false
            CbtHardeningLevel = Relaxed
        DefaultPorts
            HTTP = 5985
            HTTPS = 5986
        IPv4Filter = *
        IPv6Filter = *
        EnableCompatibilityHttpListener = false
        EnableCompatibilityHttpsListener = false
        CertificateThumbprint
    Winrs
        AllowRemoteShellAccess = true
        IdleTimeout = 180000
        MaxConcurrentUsers = 5
        MaxShellRunTime = 2147483647
        MaxProcessesPerShell = 15
        MaxMemoryPerShellMB = 150
        MaxShellsPerUser = 5

Настройки в Windows 2012 немного отличаются правами в RootSDDL:

Config
    MaxEnvelopeSizekb = 500
    MaxTimeoutms = 60000
    MaxBatchItems = 32000
    MaxProviderRequests = 4294967295
    Client
        NetworkDelayms = 5000
        URLPrefix = wsman
        AllowUnencrypted = false
        Auth
            Basic = true
            Digest = true
            Kerberos = true
            Negotiate = true
            Certificate = true
            CredSSP = false
        DefaultPorts
            HTTP = 5985
            HTTPS = 5986
        TrustedHosts
    Service
        RootSDDL = O:NSG:BAD:P(A;;GA;;;BA)(A;;GR;;;IU)S:P(AU;FA;GA;;;WD)(AU;SA;GXGW;;;WD)
        MaxConcurrentOperations = 4294967295
        MaxConcurrentOperationsPerUser = 1500
        EnumerationTimeoutms = 240000
        MaxConnections = 300
        MaxPacketRetrievalTimeSeconds = 120
        AllowUnencrypted = false
        Auth
            Basic = false
            Kerberos = true
            Negotiate = true
            Certificate = false
            CredSSP = false
            CbtHardeningLevel = Relaxed
        DefaultPorts
            HTTP = 5985
            HTTPS = 5986
        IPv4Filter = *
        IPv6Filter = *
        EnableCompatibilityHttpListener = false
        EnableCompatibilityHttpsListener = false
        CertificateThumbprint
        AllowRemoteAccess = true
    Winrs
        AllowRemoteShellAccess = true
        IdleTimeout = 7200000
        MaxConcurrentUsers = 10
        MaxShellRunTime = 2147483647
        MaxProcessesPerShell = 25
        MaxMemoryPerShellMB = 1024
        MaxShellsPerUser = 30

Стоит обратить внимание на настройку портов по умолчанию (DefaultPorts). Она отвечает только за то на каких портах будет прослушивать WinRM при включении удаленного доступа. Но сам удаленный доступ выключен по умолчанию на Windows 2008R2 и включен только для HTTP в Windows 2012.

Пояснение по поводу шифрования. Может показаться, что сообщения в WinRM передаются нешифрованными поскольку включен только HTTP транспорт. Однако это не совсем так, действительно TLS шифрование не применяется, однако сами сообщения все равно шифруются самим WinRM (параметр AllowUnencrypted = false) ключами, полученными из метода аутентификации Windows используемого по умолчанию.

Теперь посмотрим на настройки получателя запросов WinRM:

C:\winrm enumerate winrm/config/listener

Listener
    Address = *
    Transport = HTTP
    Port = 5985
    Hostname
    Enabled = true
    URLPrefix = wsman
    CertificateThumbprint
    ListeningOn = 10.10.0.12

При наличии сертификата с именем машины, можно включить HTTPS доступ к WinRM

winrm create winrm/config/listener?Address=*+Transport=HTTPS @{Port="5986"}

Как упоминалась ранее, WinRM поддерживает плагины для поддержки удаленного доступа к различным приложениям. Посмотреть список зарегистрированных плагинов (DLL) можно командой WINRM, ниже представлен вывод для системы Windows 2008R2:

C:\winrm enumerate winrm/config/plugin -format:pretty

 Event Forwarding Plugin (wevtfwd.dll)
 URI: http://schemas.microsoft.com/wbem/wsman/1/windows/EventLog
 SDDL: O:NSG:BAD:P(A;;GA;;;BA)(A;;GR;;;ER)S:P(AU;FA;GA;;;WD)(AU;SA;GXGW;;;WD)

 microsoft.powershell (pwrshplugin.dll)
 URI: http://schemas.microsoft.com/powershell/microsoft.powershell
 SDDL: O:NSG:BAD:P(A;;GA;;;BA)S:P(AU;FA;GA;;;WD)(AU;SA;GXGW;;;WD)
 
 microsoft.servermanager (pwrshplugin.dll)
 URI: http://schemas.microsoft.com/powershell/microsoft.servermanager
 SDDL: O:NSG:BAD:P(A;;GA;;;BA)S:P(AU;FA;GA;;;WD)(AU;SA;GXGW;;;WD)

 SEL Plugin (wsmselpl.dll)
 URI: http://schemas.microsoft.com/wbem/wsman/1/logrecord/sel
 SDDL: O:NSG:BAD:P(A;;GA;;;BA)(A;;GA;;;S-1-5-80-4059739203-877974739-1245631912-527174227-2996563517)S:P(AU;FA;GA;;;WD)(AU;SA;GXGW;;;WD)

 WMI Provider (wsmwmipl.dll)
 URI: http://schemas.microsoft.com/wbem/wsman/1/wmi
 URI: http://schemas.dmtf.org/wbem/wscim/1/cim-schema
 URI: http://schemas.dmtf.org/wbem/wscim/1/*

Для системы Windows 2012 количество плагинов отличается, также обратите внимание на права в SDDL:

Event Forwarding Plugin (wevtfwd.dll)
 URI: http://schemas.microsoft.com/wbem/wsman/1/windows/EventLog
 SDDL: O:NSG:BAD:P(A;;GA;;;BA)(A;;GR;;;ER)S:P(AU;FA;GA;;;WD)(AU;SA;GWGX;;;WD)

 microsoft.powershell (pwrshplugin.dll)
 URI: http://schemas.microsoft.com/powershell/microsoft.powershell
 SDDL: O:NSG:BAD:P(A;;GA;;;BA)(A;;GA;;;RM)S:P(AU;FA;GA;;;WD)(AU;SA;GXGW;;;WD)
 
 microsoft.powershell.workflow (pwrshplugin.dll)
 URI: http://schemas.microsoft.com/powershell/microsoft.powershell.workflow
 SDDL: O:NSG:BAD:P(A;;GA;;;BA)(A;;GA;;;RM)S:P(AU;FA;GA;;;WD)(AU;SA;GXGW;;;WD)

 microsoft.powershell32 (pwrshplugin.dll)
 URI: http://schemas.microsoft.com/powershell/microsoft.powershell32
 SDDL: O:NSG:BAD:P(A;;GA;;;BA)(A;;GA;;;RM)S:P(AU;FA;GA;;;WD)(AU;SA;GXGW;;;WD)

 microsoft.windows.servermanagementworkflows (pwrshplugin.dll)
 URI: http://schemas.microsoft.com/powershell/microsoft.windows.servermanagerworkflows
 SDDL: O:NSG:BAD:P(A;;GA;;;BA)(A;;GA;;;IU)S:P(AU;FA;GA;;;WD)(AU;SA;GXGW;;;WD)

 SEL Plugin (wsmselpl.dll)
 URI: http://schemas.microsoft.com/wbem/wsman/1/logrecord/sel
 SDDL: O:NSG:BAD:P(A;;GA;;;BA)(A;;GA;;;S-1-5-80-4059739203-877974739-1245631912-527174227-2996563517)S:P(AU;FA;GA;;;WD)(AU;SA;GXGW;;;WD)

 WMI Provider (wsmwmipl.dll)
 URI: http://schemas.microsoft.com/wbem/wsman/1/wmi
 SDDL: O:NSG:BAD:P(A;;GA;;;BA)(A;;GA;;;IU)(A;;GA;;;RM)(A;;GA;;;S-1-5-21-3411848436-3231049841-1657526397-1000)S:P(AU;FA;GA;;;WD)(AU;SA;GXGW;;;WD)
 URI: http://schemas.dmtf.org/wbem/wscim/1/cim-schema
 SDDL: O:NSG:BAD:P(A;;GA;;;BA)(A;;GA;;;IU)(A;;GA;;;RM)(A;;GA;;;S-1-5-21-3411848436-3231049841-1657526397-1000)S:P(AU;FA;GA;;;WD)(AU;SA;GXGW;;;WD)
 URI: http://schemas.dmtf.org/wbem/wscim/1/*
 SDDL: O:NSG:BAD:P(A;;GA;;;BA)(A;;GA;;;IU)(A;;GA;;;RM)(A;;GA;;;S-1-5-21-3411848436-3231049841-1657526397-1000)S:P(AU;FA;GA;;;WD)(AU;SA;GXGW;;;WD)
 URI: http://schemas.dmtf.org/wbem/cim-xml/2/cim-schema/2/*
 SDDL: O:NSG:BAD:P(A;;GA;;;BA)(A;;GA;;;IU)(A;;GA;;;RM)(A;;GA;;;S-1-5-21-3411848436-3231049841-1657526397-1000)S:P(AU;FA;GA;;;WD)(AU;SA;GXGW;;;WD)

У WMI провайдера в Windows 2012 появился свой SDDL, когда провайдер не имеет своего SDDL он использует RootSDDL, который мы видели ранее в выводе команды winrm get winrm/config.

Что же такое SDDL? Это контроль доступа к WinRM и его провайдерам. SDDL расшифровывается как Security Descriptor Definition Language и представляет собой текстовое описание прав доступа к компонентам системы: файлам и папкам, реестру, WMI и самому WinRM.
При приеме запроса WinRM аутентифицирует пользователя, определяет права к провайдеру, к которому хочет подключиться пользователь, и принимает запрос только в том случае, если SDDL провайдера разрешает данному пользователю подключаться. Если у провайдера не указан собственный SDDL, то используется RootSDDL. Важно понимать, что RootSDDL используется только в том случае, если у провайдера нет своего SDDL.

Рассмотрим структуру SDDL:

O:<владелец>D:P<разрешение>S:P<аудит>

Нас интересует секция, начинающаяся с D:P. Она состоит из одной или нескольких записей (Access Control Entry), заключенных в круглые скобки. Первая буква в секции может быть A — разрешить, или D — запретить. Дальше идет уровень доступа:

Сокращение	Полное название
GA	Generic All (Full Control)
GR	Generic Read
GW	Generic Write
GX	Generic Execute

И последним идет идентификатор пользователя или группы (SID):

Сокращение	Полное название
BA	BUILTIN\Administrators
WD	Everyone
ER	BUILTIN\Event Log Readers
IU	NT AUTHORITY\Interactive
RM	BUILTIN\Remote Management Users
S-1-5-21-xxxxxxxxxx-xxxxxxxxxx-xxxxxxxxxx-1000	WinRMRemoteWMIUsers__

Рассмотрим RootSDDL в Windows 2008R2, который применяется к WMI, поскольку у него нет своего SDDL:

O:NSG:BAD:P(A;;GA;;;BA)S:P(AU;FA;GA;;;WD)(AU;SA;GWGX;;;WD)

Единственна строчка доступа, позволяет (A) полный доступ (GA) локальным администраторам (BA).

В Windows 2012 WMI использует собственную SDDL:

O:NSG:BAD:P(A;;GA;;;BA)(A;;GA;;;IU)(A;;GA;;;RM)(A;;GA;;;S-1-5-21-xxxxxxxxxx-xxxxxxxxxx-xxxxxxxxxx-1000)S:P(AU;FA;GA;;;WD)(AU;SA;GXGW;;;WD)

Она состоит из четырех записей доступа. Первая запись, такая же как в Windows 2008R2, вторая для интерактивных пользователей. А вот третья позволяет (A) полный доступ (GA) локальной группе удаленных пользователей (RM — Remote Management Users). Четвертая запись использует конкретный SID от группы WinRMRemoteWmiUsers__. Таким образом может показаться, что достаточно пользователя добавить в группу Remote Management Users или WinRMRemoteWMIUsers__ , что позволит удаленно обращаться к WMI. Но это не совсем так.

Попробуем удаленно подключиться к WMI через WinRM под пользователем из этой группы.

winrm get wmicimv2/Win32_Service?Name=spooler –remote:srv-data1

И получим ошибку доступа.
Fault Code Value = s:Receiver Subcode Value = w:InternalError Reason Text = The WS-Management service cannot process the request. The WMI service returned an 'access denied' error.

Detail MSFT_WmiError CIMStatusCode = 2 CIMStatusCodeDescription = null ErrorSource = null ErrorSourceFormat = 0 ErrorType = 0 Message = The WS-Management service cannot process the request. The WMI service returned an 'access denied' error. MessageID = HRESULT 0x80338104 OtherErrorSourceFormat = null OtherErrorType = null OwningEntity = null PerceivedSeverity = 0 ProbableCause = 0 ProbableCauseDescription = null error_Category = 18 error_Code = 2150859012 error_Type = HRESULT error_WindowsErrorMessage = The WS-Management service cannot process the request. The WMI service returned an 'access denied' error.

Error number: -2147023537 0x8007054F An internal error occurred.

Подключение по WinRM произошло, SDDL провайдера WMI разрешил доступ, но сам WMI запретил доступ.

Заглянув в Просмотр событий, можно увидеть следующее:

Event Viewer Application and Service Logs Microsoft Windows Remote Management правая кнопка мыши View - Show Analytic and Debug Logs правая кнопка мыши Analytic - Enable Log

Подключение к WinRM
User ... authenticated successfuly using Kerberos authentication Authorizing the user Updating quota for the user The authorization of the user was done successfully
Подключение к WMI провайдеру в WinRM
SOAP listener receiving Processing client request for operation GET The WinRM service loaded the following plugin: WMI Provider (WsmWmiPl.dll) Entering plugin for operation Get with Resource URI of ... Authorizing the user
И наконец подключение к самому WMI
Plugin reporting data object for operation Get SOAP listener sending Plugin reporting operation complete for Get

Для того чтобы предоставить удаленный доступ к WMI для пользователей без прав администратора на Windows 2012 и выше нужно:

Добавить пользователя в группу Remote Management Users
В настройке прав пользователей в WMI, дать право удаленного подключения (Remote Enable) группе Remote Management Users

Картинка с сайта: gamelton.wordpress.com

Для того чтобы предоставить удаленный доступ к PowerShell для пользователей без прав администратора на Windows 2012 и выше нужно:

Добавить пользователя в группу Remote Management Users

Поддержать блог

Источник

Discover what WinRM protocol is all about and gain insight on how you can use it to manage your network

Technology Advisor | Cybersecurity Evangelist

Updated: November 19, 2024

Windows Remote Management (WinRM) is Microsoft’s implementation of the Web Services-Management (WS-Management) protocol, which provides a standardized method for systems, both hardware and software, from various vendors to communicate

This protocol facilitates the exchange of management data across an organization’s IT infrastructure, enabling seamless interoperability between diverse systems. By providing a unified framework, WinRM is especially beneficial for IT administrators who need to oversee extensive Windows-based network environments.

WinRM plays a crucial role in simplifying remote management tasks, such as system configuration, monitoring, and troubleshooting, making it an indispensable tool for network administrators. Microsoft first introduced this protocol with WinRM 1.1, which was compatible with Windows XP, Windows Server 2003, Windows Vista, and Windows Server 2008. This initial version laid the groundwork for the more advanced functionalities that followed.

The release of WinRM 2.0 brought significant enhancements, including the ability to execute PowerShell 2.0 scripts and cmdlets on remote systems. This version was included with Windows 7 and Windows Server 2008 R2, further streamlining administrative tasks across multiple machines. In 2012, Microsoft introduced WinRM 3.0, which came pre-installed with Windows 8 and Windows Server 2012. This version featured improved performance and deeper integration, cementing WinRM as a vital component of modern Windows infrastructure management.

Why is the WinRM protocol important?

Why is the WinRM protocol important and why do we need it? With WinRM protocol, the connection between computers or servers can be easily established, so that remote operations can be performed. You can obtain data or manage resources on remote computers as well as the local computer. Connecting to a remote computer in a Windows Remote Management script is very similar to making a local connection. The WinRM protocol is intended to improve hardware management in a network environment with various devices running a variety of operating systems.

As a command-line tool, WinRM is built into Windows operating systems and based on .NET and PowerShell, which allows scripts and remote PowerShell commands to be invoked on Windows-based machines or a large set of remote machines without RDP or log into the remote machine. This method makes it easier for Windows Administrators to manage multiple machines using scripts and cmdlet, and perform tasks such as:

Monitor, manage and configure servers, operating systems, and client machines from a remote location.
Remotely communicate and interface with hosts through readily available channels/ports within your network, including workstations, servers, and any operating system that supports it.
Execute commands remotely on systems that you are not local to you but are network accessible

The Windows Remote Shell (WinRS) command-line tool relies on WinRM to execute remote commands. It leverages WinRM to let you launch processes on remote machines. WinRM is the server component of this remote management application and WinRS is the client component for WinRM, which runs on the remote computer attempting to remotely manage the WinRM server. However, both computers must have WinRM installed and enabled on them for WinRS to work and retrieve information from the remote system.

WinRM architecture and components

The WinRM architecture consists of components on the client and server computers. The diagram in Figure 1.0 below shows the components on both the requesting client and responding server computers, and how they interact with each other, including the protocol that is used to communicate between them.

Figure 1.0 | Diagram showing WinRM architecture and component | credit: Microsoft

Table 1.0 below is a breakdown of the various WinRM components and where they reside.

Component	Description	Residence
WinRM application	WinRM command-line tool that uses the WinRM scripting API to make calls to request data or to execute methods	Client-side
WSMAuto.dll	The Automation layer that provides scripting support	Client and server-side
WsmCL.dl	API layer within the OS	Client and server-side
HTTP API	Provides support for HTTP and HTTPS transport	Client and server-side
WsmSvc.dll	WinRM listener service	Server-side
WsmProv.dll	Provider subsystem	Server-side
WsmRes.dll	Resource file	Server-side
WsmWmiPl.dll	WMI plug-in that allows you to obtain WMI data through WinRM	Server-side
IPMI driver and WMI IPMI provider	Supply any hardware data that is requested using the IPMI (Intelligent Platform Management Interface) classes	Server-side

Table 1.0 | WinRM components and description

WinRM configuration and commands

For the WinRM command-line tool and scripts to run, and perform data operations effectively, Windows Remote Management (WinRM) must be installed and configured. However, the good news is that WinRM is automatically installed with all currently-supported versions of the Windows operating system, including IPMI (Intelligent Platform Management Interface) WMI (Windows Management Instrumentation) provider components.

By default, WinRM is enabled on Windows Server OS since Windows Server 2012, but not on Windows 10 operating system. This means that you need to enable it on Windows 10 machines. To enable WinRM on a Windows 10 machine, open PowerShell and run the following cmdlet:

Enable-PSRemoting -force

If you have a single Windows 10 machine that is not part of an Active Directory domain network, you may need to add the machine you are going to connect from to the trusted host of the Windows 10 machine. The reason we need to add trusted hosts is to be able to connect to a Windows machine using WinRM.

However, in situations where you have 100+ Windows 10 machines in an Active Directory domain network, you may need to use a Group Policy (GPO) to get it working with minimal effort. To use a GPO, create a new one or edit an existing one and modify the following settings and set WinRM to “Enabled”:

Computer Configuration > Policies > Administrative Templates > Windows Components > Windows Remote Management (WinRM) > WinRM Service > Allow remote server management through WinRM

Remember to apply the GPO to the Organizational Units (OU) that have all your Windows 10 machines. Within a few minutes after applying the GPO to the OU, all your hosts will get the policy update. In this case, there is no need to modify the trusted hosts’ list.

The table below is a collection of some WinRM commands you can use to execute remote operations. Please note that these commands work best when you are on an Active Directory domain network. For workgroup machines, the WinRM service may require additional configuration such as modifying the trusted hosts’ list.

Description	Command	Remark
Locate listeners and the addresses	winrm e winrm/config/listener
Check the state of configuration settings	winrm get winrm/config
Quickly configure the WS-Man service	winrm QuickConfig	Run from an Elevated Command prompt
Quickly delete the WS-Man listener	winrm invoke Restore winrm/Config @{}	Run from an Elevated Command prompt
Display your machine’s basic hardware info	winrm enumerate wmicimv2/Win32_ComputerSystem	Run from an Elevated Command prompt
Display your operating system properties	winrm get wmicimv2/Win32_OperatingSystem	Run from an Elevated Command prompt
Output your OS info in XML	winrm get wmicimv2/Win32_OperatingSystem -format:pretty	Run from an Elevated Command prompt
Test WS-Man access to a remote machine	winrm id -remote:	Run from an Elevated Command prompt
Grab a remote machine’s WS-Man config	winrm get winrm/Config -r:	Run from an Elevated Command prompt
Grab a remote machine’s CPU load	winrm g wmicimv2/Win32_Processor?DeviceID=CPU0 -fragment:LoadPercentage -r:	Run from an Elevated Command prompt
Grab a remote machine’s free memory	winrm g wmicimv2/Win32_OperatingSystem -fragment:FreePhysicalMemory -r:	Run from an Elevated Command prompt
Stop a service on a remote machine	winrm invoke stopservice wmicimv2/Win32_Service?name=w32time -r:	Run from an Elevated Command prompt
Start a service on a remote machine	winrm invoke startservice wmicimv2/Win32_Service?name=w32time -r:	Run from an Elevated Command prompt
Reboot a remote machine	winrm invoke reboot wmicimv2/Win32_OperatingSystem -r:	Run from an Elevated Command prompt
Run a command on a remote machine (this uses winrS, not winrM)	winrs -r: ipconfig /all	Run from an Elevated Command prompt
Use PowerShell to grab the WS-Man Win32_OperatingSystem XML output	[xml]$osInfo = winrm get wmicimv2/Win32_OperatingSystem /format:pretty	Run from PowerShell
Display the OS version property	$osInfo.Win32_OperatingSystem.Version	Run from PowerShell
Display the last boot time	$osInfo.Win32_OperatingSystem.LastBootupTime.DateTime	Run from PowerShell
Put free memory metric into an XML variable	[xml]$freemem = cmd /c “winrm get wmicimv2/Win32_OperatingSystem -fragment:FreePhysicalMemory -f:pretty -r:”	Run from PowerShell
Display the free memory value	$freemem.XMLFragment.FreePhysicalMemory	Run from PowerShell

Table 2.0 | Common WinRM commands and description

WinRM security

By default, WinRM uses Kerberos for authentication. This means that Windows never sends the actual credentials to the system requesting validation instead of relying on features such as hashing and tickets to connect.

WinRM listens on TCP port 80 (HTTP) by default, it doesn’t mean traffic is unencrypted. Traffic by default is only accepted by WinRM when it is encrypted using the Negotiate or Kerberos SSP. WinRM also includes helper code that lets the WinRM listener share port 80 with the Microsoft IIS web server or any other application that may need to use that port. Although WinRM listeners can be configured to encrypt all communications using HTTPS, with the use of Kerberos, even if unencrypted HTTP is used, all communication is still encrypted using a symmetric 256-bit key after the authentication phase completes.

You can manually configure WinRM to use HTTPS. The purpose of configuring WinRM for HTTPS is to encrypt the data being sent across the network. This allows for additional security by ensuring server identity via SSL/TLS certificates thereby preventing an attacker from impersonating it. To configure WinRM to use HTTPS, a local computer Server Authentication certificate with a CNAME matching the hostname is required to be installed. To install certificates for the local computer, follow the steps below:

Select Start and then select Run (or using keyboard combination press Windows key+R)
Type MMC and then press Enter
Select File from menu options and then select Add or Remove Snap-ins
Select Certificates and select Add
Go through the wizard selecting the Computer account
Install or view the certificates under Certificates (Local computer) >> Personal >> Certificates.

Once the certificate is successfully installed, use the following command to configure WRM to listen on HTTPS: winrm quickconfig -transport:https

Notable applications of WinRM

SolarWinds Server & Application Monitor software (SAM) enables remote access for PowerShell with WinRM. It utilizes a WinRM server on monitored servers for its PowerShell integration.
Thycotic Secret Server—privileged access management (PAM) solution, relies on WinRM components to run PowerShell scripts.
Ansible—an agentless open-source software provisioning and deployment tool, leverages WinRM to communicate with Windows servers and run PowerShell scripts and commands. Ansible is agentless because of its ability to remotely connect via WinRM, thereby allowing remote PowerShell execution to do its tasks.
CloudBolt—a hybrid cloud management platform, leverages WinRM as part of Blueprints, Server Actions, and CB Plugins to execute remote scripts on Windows servers using the python pywinrm module.

Windows Remote Management FAQs

Is WinRM the same as RDP?

WinRM and RDP are two different systems, although both were developed by Microsoft. WinRM is designed for the remote management of Windows computers. RDP stands for Remote Desktop Protocol and it provides a view of the Desktop of a remote Windows computer. There are also RDP clients available for Linux, Unix, macOS, Android, and iOS.

What is the difference between WinRM and WMI?

WinRM is the Windows Remote Management system. WMI is the Windows Management Instrumentation system. WMI collects status reports on the services that are integrated into the Windows system. WinRM is a remote protocol. In truth, WinRM extracts WMI data from remote computers, so it uses WMI as a local agent.

Is WinRM enabled by default?

WinRM isn’t enabled by default in Windows Server versions up to 2012. From Windows Server 2012 R2, WinRM is enabled by default.

Источник

Windows Remote Management (WinRM) service implements the WS-Management protocol for remote management. WS-Management is a standard web services protocol used for remote software and hardware management. The WinRM service listens on the network for WS-Management requests and processes them. The WinRM Service needs to be configured with a listener using winrm.cmd command line tool or through Group Policy in order for it to listen over the network. The WinRM service provides access to WMI data and enables event collection. Event collection and subscription to events require that the service is running. WinRM messages use HTTP and HTTPS as transports. The WinRM service does not depend on IIS but is preconfigured to share a port with IIS on the same machine. The WinRM service reserves the /wsman URL prefix. To prevent conflicts with IIS, administrators should ensure that any websites hosted on IIS do not use the /wsman URL prefix.

This service also exists in Windows 10, 7, 8 and Vista.

Startup Type

Windows 11 version	Home	Pro	Education	Enterprise
21H2	Manual	Manual	Manual	Manual
22H2	Manual	Manual	Manual	Manual
23H2	Manual	Manual	Manual	Manual
24H2	Manual	Manual	Manual	Manual

Default Properties

Display name:	Windows Remote Management (WS-Management)
Service name:	WinRM
Type:	share
Path:	%WinDir%\System32\svchost.exe -k NetworkService -p
File:	%WinDir%\system32\WsmSvc.dll
Error control:	normal
Object:	NT AUTHORITY\NetworkService
Privileges:	SeAssignPrimaryTokenPrivilege SeAuditPrivilege SeChangeNotifyPrivilege SeCreateGlobalPrivilege SeImpersonatePrivilege

Default Behavior

The Windows Remote Management (WS-Management) service is running as NT AUTHORITY\NetworkService in a shared process of svchost.exe. Other services might run in the same process. If Windows Remote Management (WS-Management) fails to start, the error is logged. Windows 11 startup proceeds, but a message box is displayed informing you that the WinRM service has failed to start.

Dependencies

Windows Remote Management (WS-Management) is unable to start, if at least one of the following services is stopped or disabled:

HTTP Service
Network Store Interface Service
Remote Procedure Call (RPC)

Restore Default Startup Type for Windows Remote Management (WS-Management)

Automated Restore

1. Select your Windows 11 edition and release, and then click on the Download button below.

2. Save the RestoreWindowsRemoteManagementWSManagementWindows11.bat file to any folder on a local drive such as SSD or a hard disk.

3. Right-click the downloaded batch file and select Properties.

4. Check the Unblock checkbox and click OK.

5. Right-click the batch file again and select Run as administrator.

6. Restart the computer to save changes.

Note. Make sure that the WsmSvc.dll file exists in the %WinDir%\system32 folder. If this file is missing you can try to restore it from your Windows 11 installation media.

Yea, though I walk through the valley of the shadow of death, I will fear no evil: for thou art with me; thy rod and thy staff they comfort me.

Источник