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

  • Artigo

A 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 superior. 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?

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

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

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

A comunicação remota do PowerShell (e o WinRM) escutam 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 sob o contexto do usuário, portanto, todos os controles de acesso do sistema operacional aplicados a usuários individuais e grupos continuam a ser aplicados a eles enquanto conectados por meio da comunicação remota do PowerShell.

Em redes privadas, a regra padrão do Firewall do Windows para comunicação remota do PowerShell aceita todas as conexões. Em redes públicas, a regra padrão do Firewall do Windows permite conexões remotas do PowerShell somente de dentro da mesma sub-rede. Você precisa alterar explicitamente essa regra para abrir a comunicação remota do PowerShell 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 externa potencialmente mal-intencionadas. Tenha cuidado ao remover esta 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 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

O FireEye forneceu um bom resumo dos logs de eventos e outras evidências de segurança geradas pelas sessões de comunicação remota do PowerShell, disponíveis em Investigando ataques do PowerShell.

Protocolos de criptografia e transporte

É útil considerar a segurança de uma conexão remota do PowerShell de duas perspetivas: 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 - do 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 do servidor sem enviar nenhum 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 remota 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 delegável. Para provar a identidade do usuário, o protocolo NTLM requer que o cliente e o servidor calculem uma chave de sessão a partir da senha do usuário sem nunca trocar a senha em si. O servidor normalmente não sabe a senha do usuário, então 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. Como acontece com todos os protocolos que usam NTLM para autenticação, um invasor com acesso à conta de máquina de um computador associado a um domínio pode invocar o controlador de domínio para calcular uma chave de sessão NTLM e, assim, representar o servidor.

A autenticação baseada em NTLM é desabilitada por padrão, mas pode ser permitida configurando SSL no servidor de destino ou configurando a configuração 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 (apenas que ele já sabe sua senha), você pode configurar os servidores de destino para usar SSL para comunicação remota do PowerShell. A atribuição de um certificado SSL ao servidor de destino (se emitido por uma Autoridade de Certificação na qual o cliente também confia) permite a autenticação baseada em NTLM que garante a identidade do usuário e a identidade do servidor.

Ignorando erros de identidade do servidor baseado 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 WinRM TrustedHosts . Observe que adicionar um nome de servidor à lista TrustedHosts não deve ser considerado como qualquer forma de declaraçã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 deseja suprimir o erro gerado por não conseguir verificar a identidade do servidor.

Comunicação em curso

Quando a autenticação inicial estiver concluída, o WinRM criptografa a comunicação em andamento. Ao se conectar por HTTPS, o protocolo TLS é usado para negociar a criptografia usada para transportar dados. Ao conectar-se por HTTP, a criptografia no nível da mensagem é determinada pelo protocolo de autenticação inicial usado.

  • A autenticação básica não fornece criptografia.
  • A autenticação NTLM usa uma cifra RC4 com uma chave de 128 bits.
  • A criptografia de autenticação Kerberos é determinada pelo tíquete etype TGS. Este é o AES-256 em sistemas modernos.
  • A criptografia CredSSP usa o pacote de codificação TLS que foi negociado no handshake.

Fazer o segundo salto

Por padrão, a comunicação remota do PowerShell usa Kerberos (se disponível) ou NTLM para autenticação. Ambos os protocolos são autenticados na máquina remota sem enviar credenciais para ela. Essa é a maneira mais segura de autenticar, mas como a máquina remota não tem as credenciais do usuário, ela não pode acessar outros computadores e serviços em nome do usuário. Isso é conhecido como o "problema do segundo salto".

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

Referências