Вопросы обеспечения безопасности при удаленном взаимодействии PowerShell с использованием WinRM

Статья
11/04/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 выполняется как служба с учетной записью сетевой службы и порождает изолированные процессы, выполняющиеся как учетные записи пользователей, для размещения экземпляров PowerShell. Экземпляр PowerShell, выполняющийся как один пользователь, не имеет доступа к процессу, в котором выполняется экземпляр PowerShell от имени другого пользователя.

Журналы событий, создаваемые удаленным взаимодействием PowerShell

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

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

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

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

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

Проверка подлинности используется для идентификации клиента для сервера и, в идеале, сервера для клиента.

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

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

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

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

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

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

Пропуск ошибок идентификации сервера на основе NTLM

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

Текущий обмен данными

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

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

Выполнение второго перехода

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

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

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