Quando a maioria das pessoas ouve falar em «WinRM sobre HTTP», assume imediatamente que se trata de um desastre de segurança à espera de acontecer. Afinal, há anos que nos dizem que o HTTP é mau e o HTTPS é bom.
Mas, na realidade, a utilização do protocolo Windows Remote Management (WinRM) apresenta algumas nuances. Em muitos ambientes, o HTTP não é significativamente menos seguro do que o HTTPS.
O equívoco sobre a encriptação:
O WinRM sobre HTTP é intrinsecamente inseguro?
O maior equívoco é pensar que o WinRM envia dados via HTTP em texto simples. Não é verdade.
Por predefinição, o WinRM utiliza a autenticação Kerberos ou NT LAN Manager (NTLM) e os segredos são utilizados para encriptar o conteúdo da mensagem na camada de aplicação, independentemente do protocolo de transporte.
No WinRM, o HTTP é apenas o canal de transporte; a encriptação e a autenticação são geridas na camada de aplicação acima dele. Um invasor que esteja a monitorizar a sua rede não verá nem o seu comando nem a resposta. Também não conseguirá fazer a autenticação no ponto de extremidade HTTP do WinRM.
O WinRM foi concebido tendo em conta esta separação, o que o torna fundamentalmente diferente, por exemplo, de um site que funciona através de HTTP, onde a carga útil é, de facto, transmitida em texto simples.
O que é que o HTTPS realmente acrescenta?
O HTTPS protege toda a ligação através do Protocolo de Segurança da Camada de Transporte (TLS), o que oferece duas garantias adicionais:
- encriptação na camada de transporte
- autenticação de servidor baseada em certificado
A encriptação na camada de transporte é, em grande parte, redundante, dado que o WinRM já inclui encriptação de mensagens.
A validação do certificado é realmente importante. Oferece uma garantia mais sólida de que está a comunicar com o servidor que pensa estar a contactar, o que ajuda a proteger contra certos cenários de ataques do tipo «man-in-the-middle» (MiTM) em redes não confiáveis.
No entanto, numa rede interna bem gerida, com controlos adequados de DNS e do Active Directory (AD), essas ameaças já são significativamente mitigadas por outros meios.
Quando o WinRM sobre HTTP é perfeitamente aceitável
Num ambiente integrado ao domínio, o WinRM sobre HTTP oferece três elementos que são realmente importantes para uma gestão remota segura:
- Integridade da mensagem
- Criptografia de mensagens e um
- Um certo grau de autenticação mútua, caso se utilize o Kerberos
Uma observação importante: a autenticação básica deve estar sempre desativada — o que, de facto, acontece por predefinição.
A autenticação básica envia credenciais sem qualquer proteção real e constituiria a única vulnerabilidade genuína do WinRM sobre HTTP, caso permanecesse ativada. Por isso, certifique-se de que permanece desativada.
Muitos ambientes empresariais maduros executam o WinRM sobre HTTP internamente sem qualquer aumento significativo do risco. Além disso, a sobrecarga operacional associada à gestão de certificados para HTTPS pode, na verdade, introduzir riscos se for mal executada; certificados expirados, autoridades de certificação mal configuradas e fluxos de automação com falhas são problemas reais que o HTTP evita por completo.
Quando deve utilizar o HTTPS? Leia isto primeiro
O HTTPS é a escolha certa quando se opera em redes não confiáveis.
No entanto, implementar o WinRM sobre HTTPS sem configurar corretamente um Token de Ligação de Canal (CBT) pode, na verdade, colocar-te numa situação de segurança pior do que a do HTTP.
O CBT vincula o protocolo de autenticação a um canal TLS específico, impedindo que um atacante retransmita credenciais capturadas para se autenticar no WinRM em nome do utilizador em questão.
O HTTPS sem um CBT pode criar uma falsa sensação de segurança. A ligação está encriptada, mas a autenticação pode ainda ser retransmitida, o que cria uma vulnerabilidade crítica. Sem CBTs, a autenticação Kerberos e NTLM através de TLS continua vulnerável a ataques de retransmissão.
Em contrapartida, o WinRM sobre HTTP não é afetado da mesma forma, uma vez que o tráfego é protegido pelo WinRM através dos dados de autenticação do utilizador.
Felizmente, o Windows ativa os CBTs no modo «Relaxed» por predefinição, o que oferece proteção na maioria dos casos.
C:>winrm get winrm/config/service/auth
Auth
Basic = false
Kerberos = true
Negotiate = true
Certificate = false
CredSSP = false
CbtHardeningLevel = Relaxed
No entanto, a configuração recomendada é definir explicitamente os CBTs como «Rigoroso».
C:>winrm set winrm/config/service/auth @{CbtHardeningLevel="Strict"}
Isto garante que apenas sejam aceites tentativas de autenticação devidamente associadas ao canal TLS, eliminando efetivamente a superfície de ataque por retransmissão.
Conclusão: opte deliberadamente pelo WinRM sobre HTTP
As decisões de segurança devem basear-se em modelos de ameaças reais, e não em preferências automáticas de protocolos.
Num ambiente de domínio com Kerberos, a utilização do WinRM sobre HTTP não constitui uma configuração imprudente. O HTTPS é preferível em redes não confiáveis, mas apenas se for configurado corretamente. Uma implementação HTTPS sem que os CBTs estejam definidos, no mínimo, para o valor padrão «Relaxed» — ou, idealmente, «Strict» — é, sem dúvida, mais perigosa do que o HTTP, pois gera uma confiança infundada, deixando ao mesmo tempo aberto um vetor crítico de retransmissão de autenticação.
Compreenda o funcionamento do seu protocolo de autenticação. Compreenda a confiança da sua rede.
