Considerações de segurança para comunicação remota do PowerShell usando o WinRM

2025-05-20

Comunicação remota do PowerShell é a maneira recomendada de gerenciar sistemas Windows. A comunicação remota do PowerShell é habilitada por padrão no Windows Server 2012 R2 e posterior. Este documento aborda questões de segurança, recomendações e práticas recomendadas ao usar a Comunicação Remota do PowerShell.

O que é a comunicação remota do PowerShell?

O PowerShell Remoting usa o WinRM (Gerenciamento Remoto do Windows) para permitir que os usuários executem comandos do PowerShell em computadores remotos. O WinRM é a implementação da Microsoft do protocolo Web Services for Management (WS-Management). Você pode encontrar mais informações sobre como usar o PowerShell Remoting em Executando Comandos Remotos.

A comunicação remota do PowerShell não é a mesma que usar o parâmetro ComputerName de um cmdlet para executá-lo em um computador remoto, que usa a Chamada de Procedimento Remoto (RPC) como seu protocolo subjacente.

Configurações padrão de comunicação remota do PowerShell

A comunicação remota do PowerShell com o WinRM opera nas seguintes portas:

HTTP: 5985
HTTPS: 5986

Por padrão, a Comunicação Remota do PowerShell só permite conexões de membros do grupo Administradores. As sessões são iniciadas no contexto do usuário, portanto, todos os controles de acesso do sistema operacional aplicados a usuários e grupos individuais continuam a ser aplicados a eles enquanto estão conectados pela Comunicação Remota do PowerShell.

Em redes privadas, a regra de Firewall do Windows padrão para Comunicação Remota do PowerShell aceita todas as conexões. Em redes públicas, a regra de Firewall do Windows padrão permite conexões remotas do PowerShell somente de dentro da mesma sub-rede. Você precisa alterar explicitamente essa regra para abrir PowerShell Remoting para todas as conexões em uma rede pública.

Aviso

A regra de firewall para redes públicas destina-se a proteger o computador contra tentativas de conexão externas potencialmente mal-intencionadas. Tenha cuidado ao remover essa regra.

Isolamento do processo

A comunicação remota do PowerShell usa o WinRM para comunicação entre computadores. O WinRM é executado como um serviço na conta do Serviço de Rede e gera processos isolados em execução como contas de usuário para hospedar instâncias do PowerShell. Uma instância do PowerShell em execução como um usuário não tem acesso a um processo que executa uma instância do PowerShell como outro usuário.

Logs de eventos gerados pela comunicação remota do PowerShell

Pesquisadores do Mandiant apresentaram uma sessão na conferência BlackHat que fornece um bom resumo dos logs de eventos e outras evidências de segurança geradas pelas sessões de Comunicação Remota do PowerShell. Para obter mais informações, consulte Como investigar ataques do PowerShell.

Protocolos de criptografia e transporte

É útil considerar a segurança de uma conexão de Comunicação Remota do PowerShell de duas perspectivas: autenticação inicial e comunicação contínua.

Independentemente do protocolo de transporte usado (HTTP ou HTTPS), o WinRM sempre criptografa toda a comunicação remota do PowerShell após a autenticação inicial.

Autenticação inicial

A autenticação confirma a identidade do cliente para o servidor e, idealmente, o servidor para o cliente.

Quando um cliente se conecta a um servidor de domínio usando seu nome de computador, o protocolo de autenticação padrão é Kerberos. O Kerberos garante a identidade do usuário e a identidade do servidor sem enviar qualquer tipo de credencial reutilizável.

Quando um cliente se conecta a um servidor de domínio usando seu endereço IP ou se conecta a um servidor de grupo de trabalho, a autenticação Kerberos não é possível. Nesse caso, a comunicação remoto do PowerShell depende do protocolo de autenticação NTLM. O protocolo de autenticação NTLM garante a identidade do usuário sem enviar qualquer tipo de credencial delegada. Para provar a identidade do usuário, o protocolo NTLM exige que o cliente e o servidor computem uma chave de sessão da senha do usuário sem nunca trocar a senha em si. O servidor normalmente não conhece a senha do usuário, portanto, ele se comunica com o controlador de domínio, que sabe a senha do usuário e calcula a chave de sessão para o servidor.

No entanto, o protocolo NTLM não garante a identidade do servidor. Assim como acontece com todos os protocolos que usam NTLM para autenticação, um invasor com acesso à conta de computador de um computador ingressado no domínio pode invocar o controlador de domínio para calcular uma chave de sessão NTLM e representar o servidor.

A autenticação baseada em NTLM está desabilitada por padrão. Você pode habilitar o NTLM configurando o SSL no servidor de destino ou definindo a configuração do WinRM TrustedHosts no cliente.

Usando certificados SSL para validar a identidade do servidor durante conexões baseadas em NTLM

Como o protocolo de autenticação NTLM não pode garantir a identidade do servidor de destino (somente que ele já conhece sua senha), você pode configurar servidores de destino para usar o SSL para comunicação remota do PowerShell. Atribuir um certificado SSL ao servidor de destino (se emitido por uma Autoridade de Certificação em que o cliente também confia) habilita a autenticação baseada em NTLM que garante a identidade do usuário e a identidade do servidor.

Ignorando erros de identidade de servidor baseados em NTLM

Se a implantação de um certificado SSL em um servidor para conexões NTLM for inviável, você poderá suprimir os erros de identidade resultantes adicionando o servidor à lista TrustedHosts do WinRM. A adição de um nome de servidor à lista TrustedHosts não deve ser considerada como qualquer forma de instrução da confiabilidade dos próprios hosts, pois o protocolo de autenticação NTLM não pode garantir que você esteja de fato se conectando ao host ao qual pretende se conectar. Em vez disso, você deve considerar a configuração TrustedHosts como a lista de hosts para os quais você deseja suprimir o erro gerado por não conseguir verificar a identidade do servidor.

Comunicação contínua

Depois que a autenticação inicial for concluída, o WinRM criptografará a comunicação em andamento. Quando você se conecta via HTTPS, o WinRM usa o protocolo TLS para negociar a criptografia usada para transportar dados. Quando você se conecta via HTTP, o WinRM usa a criptografia no nível da mensagem negociada pelo protocolo de autenticação inicial.

A autenticação básica não fornece criptografia.
A autenticação NTLM usa uma criptografia RC4 com uma chave de 128 bits.
etype no tíquete TGS determina a criptografia de autenticação Kerberos. Este é o AES-256 em sistemas modernos.
A criptografia CredSSP usa o conjunto de cifras TLS negociado no aperto de mão.

Fazendo o segundo salto

Por padrão, a Comunicação Remota do PowerShell usa Kerberos (se disponível) ou NTLM para autenticação. Esses dois protocolos são autenticados no computador remoto sem enviar credenciais para ele. Essa é a maneira mais segura de autenticar, mas como o computador remoto não tem as credenciais do usuário, ele não pode acessar outros computadores e serviços em nome do usuário. Isso é conhecido como o problema do segundo salto.

Há várias maneiras de evitar esse problema. Para obter descrições desses métodos e os prós e contras de cada um, consulte Dando o segundo salto na Comunicação Remota do PowerShell.