Рекомендации по безопасности для удаленного взаимодействия PowerShell с помощью WinRM

Статья
12/20/2024

Удаленное взаимодействие PowerShell — это рекомендуемый способ управления системами Windows. Удаленное взаимодействие PowerShell включено по умолчанию в Windows Server 2012 R2 и более поздних версиях. В этом документе рассматриваются вопросы безопасности, рекомендации и передовой опыт при использовании удаленного взаимодействия PowerShell.

Что такое удаленное управление PowerShell?

Удаленное взаимодействие PowerShell использует удаленное управление Windows (WinRM), чтобы позволить пользователям выполнять команды PowerShell на удаленных компьютерах. WinRM — это реализация протокола веб-служб для управления (WS-Management). Дополнительные сведения об использовании удаленного взаимодействия PowerShell можно найти в разделе "Выполнение удаленных команд".

Удаленное взаимодействие PowerShell не то же самое, что использование параметра ComputerName командлета для его выполнения на удаленном компьютере, который использует удаленный вызов процедур (RPC) в качестве базового протокола.

Параметры удаленного взаимодействия PowerShell по умолчанию

PowerShell и WinRM удаленно слушают следующие порты:

HTTP: 5985
HTTPS: 5986

По умолчанию удаленное взаимодействие PowerShell разрешает подключения только для членов группы "Администраторы". Сеансы запускаются в контексте пользователя, поэтому все элементы управления доступом к операционной системе, применяемые к отдельным пользователям и группам, продолжают применяться к ним при подключении к удаленному взаимодействию PowerShell.

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

Предупреждение

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

Изоляция процессов

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

Журналы событий, созданные с помощью удаленного взаимодействия с PowerShell

FireEye предоставил хорошую сводку по журналам событий и другим доказательствам безопасности, созданным сеансами PowerShell Remoting, доступным в разделе Исследование атак PowerShell.

Протоколы шифрования и транспорта

Полезно рассмотреть безопасность подключения удаленного взаимодействия PowerShell с двух точек зрения: начальная проверка подлинности и текущая связь.

Независимо от используемого протокола транспорта (HTTP или HTTPS), WinRM всегда шифрует все удаленное взаимодействие PowerShell после первоначальной проверки подлинности.

Начальная проверка подлинности

Проверка подлинности подтверждает личность клиента серверу и, в идеале, сервер клиенту.

Когда клиент подключается к серверу домена по имени компьютера, протоколом аутентификации по умолчанию является Kerberos. Kerberos гарантирует идентификацию пользователя и удостоверение сервера без отправки каких-либо повторно используемых учетных данных.

Когда клиент подключается к домену с помощью IP-адреса или подключается к серверу рабочей группы, проверка подлинности Kerberos невозможна. В этом случае удаленное взаимодействие PowerShell зависит от протокола проверки подлинности NTLM. Протокол проверки подлинности NTLM гарантирует удостоверение пользователя без отправки каких-либо делегированных учетных данных. Чтобы подтвердить удостоверение пользователя, протокол NTLM требует, чтобы клиент и сервер вычислили ключ сеанса из пароля пользователя, не обмениваясь самим паролем. Сервер обычно не знает пароль пользователя, поэтому он взаимодействует с контроллером домена, который знает пароль пользователя и вычисляет ключ сеанса для сервера.

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

Проверка подлинности на основе NTLM отключена по умолчанию, но может быть разрешена путем настройки SSL на целевом сервере или путем настройки параметра WinRM TrustedHosts на клиенте.

Использование SSL-сертификатов для проверки удостоверения сервера во время подключений на основе NTLM

Так как протокол проверки подлинности NTLM не может гарантировать удостоверение целевого сервера (только то, что он уже знает пароль), можно настроить целевые серверы для использования SSL для удаленного взаимодействия PowerShell. Назначение SSL-сертификата целевому серверу (если оно выдано центром сертификации, которому клиент также доверяет), обеспечивает проверку подлинности на основе NTLM, которая гарантирует как удостоверение пользователя, так и удостоверение сервера.

Игнорировать ошибки идентификации сервера на основе NTLM

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

Текущее взаимодействие

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

Обычная проверка подлинности не обеспечивает шифрование.
Проверка подлинности NTLM использует шифр RC4 с 128-разрядным ключом.
Шифрование аутентификации Kerberos определяется значением etype в билете TGS. Это AES-256 в современных системах.
Шифрование CredSSP использует набор шифров TLS, который был согласован при рукопожатии.

Совершение второго перескока

По умолчанию удаленное взаимодействие PowerShell использует Kerberos (если доступно) или NTLM для проверки подлинности. Оба этих протокола проходят проверку подлинности на удаленном компьютере без отправки учетных данных в него. Это самый безопасный способ проверки подлинности, но так как удаленный компьютер не имеет учетных данных пользователя, он не может получить доступ к другим компьютерам и службам от имени пользователя. Это называется "проблемой второго прыжка".

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

Поделиться через