Considerações de segurança para comunicação remota do PowerShell usando o WinRM
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 (e 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 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
O FireEye forneceu um bom resumo dos logs de eventos e outras evidências de segurança gerados pelas sessões remotas do PowerShell, disponíveis no white paper Investigando ataques ao 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, assim, representar o servidor.
A autenticação baseada em NTLM é desabilitada por padrão, mas pode ser permitida pela configuração do SSL no servidor de destino ou pela 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. Observe que a adição de um nome de servidor à lista de TrustedHosts não deve ser considerada de nenhuma forma como uma declaração da confiabilidade dos hosts em si, pois o protocolo de autenticação NTLM não pode garantir que você esteja de fato se conectando ao host que pretende acessar. 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. Ao se conectar via HTTPS, o protocolo TLS é usado para negociar a criptografia usada para transportar dados. Ao se conectar via 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 criptografia RC4 com uma chave de 128 bits.
- A criptografia de autenticação Kerberos é determinada pelo
etypeno tíquete TGS. Este é o AES-256 em sistemas modernos. - A criptografia CredSSP usa o pacote de cifras TLS que foi 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.
