Protegendo o RDP para servidores internos

Question

Histórico: Atualmente, gerenciamos nossos servidores por meio de um IP KVM, mas estamos slooooowly migrando para o VMWare ESXi. A interface KVM é desajeitada e o gerenciamento de usuários é um pouco complicado e eu gostaria de manter as pessoas longe do Console VIC, se possível. O RDP não é permitido em nossa rede, pois todo o tráfego deve passar pelo VIC ou pelo KVM, que possuem certificados de uma autoridade de certificação interna.

Pergunta: Estou usando essa transição para avançar em direção ao RDP para gerenciamento interno de servidores. Eu gostaria de fazer o meu caso para o RDP, mas a segurança (mesmo que esses servidores não estejam voltados para a Internet) ainda é uma preocupação. Eu olhei para TS Gateway, mas parece que é para a Internet para o servidor remoto, não do cliente interno para o servidor interno. Eu sei que isso é muito amplo e, por favor, sinta-se à vontade para pedir esclarecimentos, mas qual é a melhor maneira de implementar com segurança o RDP em servidores internos.

    

Answer 1

Como com qualquer tecnologia - limite sua área de superfície. Não deixe o RDP aberto para o mundo. Exigir uma VPN ou algum outro tipo de autenticação de passagem de um fornecedor confiável (gateway web-ssl, etc.).

Para uso interno - as políticas de gerenciamento de senha padrão devem estar em vigor com o bloqueio configurado. Configure o RDP para usar a segurança de nível mais alto (force o RDP a usar a criptografia de 128 bits via GPO). O RDP é pelo menos tão seguro quanto o VIC ou a maioria dos KVMs. Milhões de pessoas usam o Citrix ou o Terminal Services diariamente. O VIC e um KVM simplesmente não possuem esse número de dispositivos instalados ou pessoas tentando explorá-los. Dadas duas tecnologias maduras concorrentes sem nenhuma exploração conhecida, eu consideraria aquela com muitas magnitudes a base instalada mais segura do que aquela com uma base de instalação limitada tipicamente encoberta dentro de uma rede privada com ferramentas proprietárias de um fornecedor .

Para clientes externos, eu consideraria um gateway SSLVPN seguro de terceiros com autenticação de certificado de cliente, se você quiser esse nível de segurança.

Se você não confia seriamente em RDP, mas confia, digamos, SSH ... existe um aplicativo RDP sobre SSH comercial chamado WiSSH que pode implementar dois fatores de autenticação, juntamente com duas camadas separadas de segurança.

O RDP tem sido uma opção em todas as instalações do Windows XP Professional e Windows Server desde 2000. É a ferramenta de gerenciamento de acesso remoto para Windows Servers e tem visto muito poucas vulnerabilidades nos últimos 9 anos . Mesmo a WindowsSecurity.com lista de sugestões é banal em sua complexidade e reflete as melhores práticas de qualquer outro sistema de gerenciamento.

    

Answer 2

A maior parte disso já foi mencionada, mas pensei em esclarecer algumas coisas. O NLA foi suportado (com um nome diferente) pelo RDP desde pelo menos um dos service packs do Windows 2003. A execução do RDP na configuração de "alta segurança" associada à execução de RDP sobre TLS é igualmente segura para a maioria das soluções alternativas de gerenciamento remoto disponível para janelas. Eu tenho assegurado minhas sessões RDP por TLS por muitos anos e o cliente XP definitivamente suportou a conexão com o RDP sobre TLS por um período de muitos anos.

Eu também usei o TS-Gateway como uma forma de proteger ainda mais o acesso entre as redes do escritório e as redes de servidores internos. Ele geralmente requer regras de firewall / roteamento entre as duas redes, mas se você quiser proteger ainda mais seu ambiente para adicionar um requisito de autenticação adicional e um ponto de entrada em túnel, o TS-Gateway ainda poderá ser muito útil. Mas, ao contrário do RDP sobre TLS, o suporte ao TS-Gateway é muito limitado da perspectiva do cliente.

    

Answer 3

No que diz respeito ao uso do próprio RDP, você está muito limitado pelo suporte ao cliente e ao servidor e há apenas algumas versões. Com Win2008, Windows 7, Vista (e aparentemente XP SP3 também) link , rede A autenticação de nível melhorou a segurança do RDP, mas, na medida em que protege o protocolo em si, sua única opção é exigir o NLA no cliente e no servidor.

Saindo do próprio RDP, você usa sua arquitetura de rede para restringir o acesso aos seus servidores. Coloque seus servidores em sua própria sub-rede, coloque seus PCs administrativos em outro e coloque usuários regulares em outro. Só permita que a sub-rede admin chegue à sub-rede do servidor por RDP em seu firewall / roteador e permita que a sub-rede do usuário regular acesse a sub-rede do servidor somente nas portas necessárias (ou tudo exceto RDP). É uma boa ideia ter seus servidores em uma sub-rede separada para limitar a difusão entre os clientes e os servidores.