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 de 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 é o mesmo que usar o parâmetro
Configurações padrão de comunicação remota do PowerShell
A comunicação remota do PowerShell (e 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
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 de WinRM
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
etypeno tíquete 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 Making the second hop in PowerShell Remoting.
