MSTSC RDP pela Internet pública

2

Minha primeira pergunta então seja gentil:)

Eu tenho um cliente que está insistindo que eles precisam permitir que o fornecedor de terceiros ofereça suporte ao acesso ao servidor diretamente da Internet via RDP.

Nossa política não permite acesso direto à infraestrutura de fora do datacenter para administração, exceto por uma conexão VPN aprovada e, depois, pela área de trabalho virtual nos servidores.

Estou agora na situação em que devo dar boas razões pelas quais é perigoso usar o RDP na Internet pública.

qualquer ajuda seria apreciada

Obrigado antecipadamente

Stuart

    
por stuart Brand 18.08.2009 / 11:24

6 respostas

3

Não se esqueça de que um intruso que comprometa esse servidor também pode usá-lo como um trampolim para atacar as instalações de outros clientes por trás do firewall. Assim, o risco de segurança não se limita apenas aos ativos do primeiro cliente.

Obtenha alguma justificativa do fornecedor para saber por que eles não podem usar a VPN. Se realmente não houver alternativa à conexão RDP direta ao servidor, eles precisarão assumir a responsabilidade por quaisquer violações de segurança por meio dessa conexão. Lembre-se de que o fornecedor acabou de admitir falhas de segurança em sua arquitetura de aplicativos, afirmando que há algo no aplicativo que impede o uso da VPN.

Tornar o acesso condicionado à assinatura de um contrato, indenizando você contra qualquer dano causado por uma violação de segurança por meio da conexão RDP. Além disso, você deve exigir que eles obtenham indenização profissional adequada ou cobertura de responsabilidade ou forneçam prova de cobertura existente com os termos que cobririam essa situação.

Em resumo, faça o fornecedor provar que pode pagar por quaisquer danos e condicionar seu acesso a uma obrigação contratual de fazê-lo.

    
por 18.08.2009 / 12:11
2

A maioria das pessoas que tem um problema em permitir o RDP diretamente da Internet tem um conjunto específico de preocupações em torno da ideia de que intrusos estão consultando diretamente seu diretório / SAM para autenticação. Sem auditoria adequada, isso muitas vezes não é percebido. Depois de obterem um par de logon único, eles têm acesso desinibido ao seu ambiente. A resposta da Microsoft para isso veio com o Windows 2008 na forma de TS-Gateway. Os serviços de Gateway TS criam um ponto de túnel não tão diferente de estabelecer um túnel VPN SSL. O serviço do Gateway TS, embora ainda esteja compartilhando o mesmo diretório ou o SAM para autenticação, fornece um conjunto separado de regras de autorização que não existiam antes. As regras de nível de usuário e de computador podem ser configuradas para controlar quais recursos você tem disponível para você, uma vez autenticado no TS-Gateway. Portanto, você não precisa configurar mapeamentos externos de nomes de DNS para todos os seus servidores internos e você pode restringir usuários específicos (grupos de usuários) a sistemas específicos.

Também fiz implementações em que os usuários de acesso do TS-Gateway são uma conta separada daqueles que têm acesso aos servidores internos. Com uma expiração de senha e bloqueio muito maiores nas contas do TS-Gateway. Isso fornece mais uma camada para aqueles paranóicos sobre a passagem direta por meio de autorização. Ele também funciona bem para grupos com diretivas de negócios específicas em relação aos sistemas DMZ que são membros de um domínio interno.

Meu maior problema (assim como em outros) com o TS-Gateway até agora é a falta de suporte para opções de autenticação de dois fatores para a conexão inicial do gateway. O segundo maior é a falta de suporte ao cliente para o TS-Gateway.

No entanto, no seu caso, supondo que seu fornecedor externo concorde em usar um cliente RDP 6.1 em conformidade e tome cuidado ao configurar um servidor TS-Gateway adequado, deve haver pouca razão para que a solicitação represente uma ameaça.

    
por 21.08.2009 / 00:00
0

Mesmo que o RDP esteja configurado para usar criptografia, você ainda permite um acesso direto ao seu servidor. Se você tiver um firewall e só permitir que o IP do seu fornecedor se conecte à porta RDP, tudo estará OK, mas se você deixá-lo aberto de qualquer IP, será perigoso se houver um problema de segurança por dia no RDP.

Eu recomendo usar um gateway de VPN como um Cisco ASA com um acesso WEB SSL VPN. O portal da Web permite então encaminhar a porta para o servidor remoto ou, ainda melhor, você pode executar um applet RDP (directx ou java) no portal. Essa solução é mais segura e funciona sem nenhum cliente vpn instalado no computador do fornecedor. Só precisa de um navegador que suporte SSL e Java ou DirectX

    
por 18.08.2009 / 12:08
0

Eu sei que a pergunta foi respondida, mas aqui estão algumas orientações, se você é obrigado a passar por isso. Primeiro, se você tiver a opção, considere o uso de um gateway TS. Info aqui neste artigo da KB:

Conexão de área de trabalho remota (Terminal Services Client 6.0)

Outra opção é mapear a porta usando seu firewall para que não seja o TCP / 3389, uma porta bem conhecida. Você quer evitar as portas bem conhecidas que serão atingidas por varreduras típicas.

Como alterar a porta de escuta da Área de Trabalho Remota

    
por 21.08.2009 / 03:15
0

Ouvi dizer que há uma nova tecnologia apenas para o Windows 2008 R2, que é chamada de "Acesso Direto". Trata-se essencialmente de uma VPN sobre SSL no sistema operacional, eu acho que requer Windows 2008 R2 e Windows 7 como cliente, mas é outra opção e pode ser mais barato do que investir em outra solução como a F5 ou a Cisco.

Visão geral técnica

    
por 07.09.2009 / 21:05
-1

Tanto quanto você está usando pelo menos RDP 6.0, não vejo mal nisso. Alguns dos meus servidores TS são acessíveis abertamente da Internet, mas só permitem segurança 6.0 ou superior (com TLS também no XP).

    
por 18.08.2009 / 11:44