Examinar a funcionalidade de segurança da comunicação remota do Windows PowerShell

Concluído

Por padrão, os pontos de extremidade que o Windows PowerShell cria permitem apenas conexões por membros de um determinado grupo. Começando com o Windows Server 2016 e o Windows 10, esses grupos incluem o grupo de usuários de gerenciamento remoto e o grupo de administradores locais. Em um domínio do AD DS (Active Directory Domain Services), este último também inclui membros do grupo global de domínio de administradores de domínio, uma vez que esse grupo é membro do grupo de administradores local em cada computador conectado ao domínio. Antes do Windows Server 2016 e do Windows 10, por padrão, somente membros do grupo de administradores locais tinham permissão para usar a comunicação remota do PowerShell. No entanto, é possível alterar os padrões. Cada ponto de extremidade tem uma SACL (lista de controle de acesso do sistema) que você pode modificar para controlar exatamente quem pode se conectar com ela.

A comunicação remota do PowerShell e do WinRM escuta nas seguintes portas:

• HTTP: 5985
• HTTPS: 5986

O comportamento de comunicação remota padrão é delegar as suas credenciais de entrada para o computador remoto, embora você tenha a opção de especificar credenciais alternativas ao fazer uma conexão. O computador remoto com o qual você está se conectando usa essas credenciais para representar você e executar as tarefas especificadas usando essas credenciais. Se você tiver habilitado a auditoria, além das tarefas executadas por você, também serão auditadas as tarefas executadas pela comunicação remota do PowerShell em seu nome. Na verdade, a comunicação remota é transparente de segurança e não altera a segurança existente do seu ambiente. Com a comunicação remota, você pode executar todas as mesmas tarefas que executaria enquanto estivesse fisicamente localizado na frente do computador local.

Observação

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

Riscos de segurança e autenticação mútua

Delegar as suas credenciais a um computador remoto envolve alguns riscos de segurança. Por exemplo, se um invasor representar com êxito um computador remoto conhecido, você poderá transmitir credenciais altamente privilegiadas para esse invasor, que poderia usá-las para fins mal-intencionados. Devido a esse risco, a comunicação remota por padrão requer autenticação mútua, o que significa que você deve se autenticar no computador remoto, e o computador remoto também deve se autenticar para você. Essa autenticação mútua garante que você se conecte somente com o computador exato que você pretendia.

A autenticação mútua é um recurso nativo do protocolo de autenticação Kerberos do Active Directory. Quando você se conecta entre computadores de domínio confiáveis, a autenticação mútua ocorre automaticamente. Quando você se conecta com computadores não conectados ao domínio, deve fornecer outra forma de autenticação mútua na forma de um certificado SSL e o protocolo HTTPS que deve ser configurado com antecedência. Outra opção é desativar o requisito de autenticação mútua adicionando o computador remoto à sua lista local de TrustedHosts. No entanto, observe que TrustedHosts usa autenticação NTLM (de Gerente de LAN do Windows NT), o que não garante a identidade do servidor. Assim como acontece com qualquer protocolo que usa o NTLM para autenticação, os invasores que têm acesso à conta confiável de um computador conectado ao domínio podem fazer com que o controlador de domínio crie uma chave de sessão NTLM e, portanto, represente o servidor.

Observação

O protocolo de autenticação NTLM não pode garantir a identidade do servidor de destino; ele só pode garantir que ele já saiba a sua senha. Portanto, você deve configurar servidores de destino para usar o SSL para Comunicação Remota do PowerShell. Obter um certificado SSL emitido por uma Autoridade de Certificação confiável em que o cliente confia e atribuí-lo ao servidor de destino aumenta a segurança da autenticação baseada em NTLM, ajudando a validar a identidade do usuário e a identidade do servidor.

Considerações sobre o nome do computador

Para que a autenticação baseada em AD DS funcione, a comunicação remota do PowerShell deve ser capaz de pesquisar e recuperar objetos de computador do AD DS (Active Directory Domain Services). Isso significa que você precisa se referir a computadores de destino usando seus FQDN (nomes de domínio totalmente qualificados). Endereços IP ou aliases de DNS (Sistema de Nomes de Domínio), por exemplo, não funcionarão, porque não fornecem comunicação remota com a autenticação mútua necessária. Se você precisar consultar um computador por um endereço IP ou um alias DNS, deverá se conectar usando HTTPS, o que significa que o computador remoto deve ser configurado para aceitar esse protocolo. Como alternativa, você deve adicionar o endereço IP ou o alias DNS à sua lista local de TrustedHosts.

Observação

Uma exceção especial é feita para o localhost do nome do computador, que permite que você o use para se conectar com o computador local sem nenhuma outra alteração de configuração. Se o computador local estiver usando um sistema operacional baseado em cliente, o WinRM precisará ser configurado nele.

A lista de TrustedHosts

A lista TrustedHosts é uma configuração configurada localmente que você também pode configurar usando um GPO (Objeto de Política de Grupo). A lista de TrustedHosts enumera os computadores para os quais a autenticação mútua não é possível. Os computadores devem ser listados com o mesmo nome que você usará para se conectar com eles, seja o nome real do computador, um alias DNS ou um endereço IP. Você pode usar curingas para especificar SRV*, que permite que qualquer computador cujo nome ou alias DNS comece com SRV se conecte. No entanto, tenha cuidado com essa lista. Embora a lista de TrustedHosts facilite a conexão com computadores fora do domínio sem precisar configurar HTTPS, ela ignora uma medida de segurança importante. Ela permite que você envie suas credenciais para um computador remoto sem determinar se esse computador é de fato aquele com o qual você pretende se conectar. Você deve usar a lista de TrustedHosts apenas para designar computadores que você sabe que não estão comprometidos, como servidores alojados em um datacenter protegido. Você também pode usar TrustedHosts para habilitar temporariamente conexões com computadores fora do domínio em uma sub-rede de rede controlada, como novos computadores que estão passando por um processo de provisionamento.

Observação

Como prática recomendada, você deve evitar usar a lista de TrustedHosts, a menos que seja absolutamente necessário. Configurar um computador fora do domínio para usar HTTPS é uma solução de longo prazo mais segura.

Privacidade

Por padrão, a comunicação remota usa HTTP, que não oferece privacidade nem criptografia do conteúdo da sua comunicação. No entanto, o Windows PowerShell pode e aplica a criptografia no nível do aplicativo por padrão. Isso significa que as suas comunicações recebem um grau de privacidade e proteção. Em redes internas, essa criptografia no nível do aplicativo geralmente é suficiente para atender aos requisitos de segurança organizacional.

Em um ambiente de domínio que usa o protocolo de autenticação Kerberos padrão, as credenciais são enviadas na forma de tíquetes Kerberos criptografados que não incluem senhas.

Quando você se conecta usando HTTPS, todo o canal é criptografado usando as chaves de criptografia do certificado SSL do computador remoto. Como resultado, mesmo que você use a autenticação Básica, as senhas não são transmitidas em texto claro. No entanto, quando você se conecta usando HTTP e autenticação Básica com um computador que não está configurado para HTTPS, as credenciais (incluindo senhas) serão transmitidas em texto claro. Isso pode ocorrer, por exemplo, quando você se conecta com um computador fora do domínio que você adiciona à sua lista local de TrustedHosts. Isso pode até mesmo ocorrer quando você usa um computador conectado ao domínio especificando o endereço IP dele, em vez do nome do host.

Como as credenciais são transmitidas em texto claro nesse cenário, você deve garantir que você se conecte a um computador fora do domínio somente em uma sub-rede de rede controlada e protegida, como uma que foi designada especificamente para o novo provisionamento de computador. Se você precisar se conectar rotineiramente com um computador fora do domínio, configure-o para dar suporte a HTTPS.