Partilhar via

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

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 é o Remoting do PowerShell?

A Comunicação Remota do PowerShell usa 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 Web Services for Management (WS-Management) protocolo. Você pode encontrar mais informações sobre como usar a comunicação remota do PowerShell em Execução de Comandos Remotos.

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

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

A comunicação remota do PowerShell com o WinRM escuta 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.

Advertência

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 de processos

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 pelo PowerShell Remoting

Os pesquisadores da 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 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 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 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 de WinRM TrustedHosts. Adicionar um nome de servidor à lista de TrustedHosts não deve ser considerado de forma alguma uma declaração sobre a confiabilidade dos próprios hosts - uma vez que o protocolo de autenticação NTLM não consegue garantir que o utilizador está realmente a conectar-se ao host que pretende aceder. 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. Quando você se conecta por HTTPS, o WinRM usa o protocolo TLS para negociar a criptografia usada para transportar dados. Quando você se conecta por 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 cifra RC4 com uma chave de 128 bits.
  • O campo etype no bilhete 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.

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 Making the second hop in PowerShell Remoting.

Referências