Como proteger um servidor de área de trabalho remota voltado para o público?


16

Estou precisando expor meu Servidor de Área de Trabalho Remota (Serviços de Terminal) para ser acessado de fora da nossa rede. No momento, ele só pode ser acessado de dentro da nossa rede.

Sei que é fácil abrir o firewall e encaminhar a porta.

No entanto, como faço para proteger a própria máquina e quais são as melhores práticas para isso? Minha preocupação é que os hackers possam trabalhar para invadir isso.

Qualquer orientação / recomendação de melhores práticas seria muito apreciada.


Editar:

Pergunta sobre um produto que encontrei:

Filtrar conexões RDP de entrada por IP, endereço MAC, nome do computador e muito mais

Alguém pode comentar sobre a segurança disso? Parece que eu também poderia usá-lo para limitar o acesso pelo nome da máquina / mac? Alguém mais usou?


11
Acho que você está perguntando não apenas como proteger esta máquina e qualquer conexão RDP, mas também como reduzir o risco para o resto da sua rede, caso ela seja comprometida. Isso está certo?
dunxd

Sim, correto, devido à nossa pequena dimensão, existe apenas um servidor RDP e ele precisa de acesso total à área de trabalho / recursos de rede para os usuários internos.
me2011

Respostas:


14

Isso pode ser mais do que você deseja fazer, mas eis como usamos o RDP para usuários remotos que não estão usando VPN.

Recentemente, começamos a usar o Gerenciador de Gateway RD com Serviços de Área de Trabalho Remota, uma função do Windows 2008. Nós o configuramos para passar pelo servidor TMG e diretamente na máquina do usuário. Ele usa o NLA como mencionado acima. A conexão do usuário deve ser um membro do grupo AD certo e um membro do grupo local direito para ter acesso permitido. Dependendo de como você deseja configurá-lo, você pode conectar-se através de uma página da Web que abre o mstsc e insere a configuração de proxy para o Gateway RD, ou você pode definir manualmente as configurações na sua máquina para que, toda vez que a abrir, tente acessar através desse proxy. Até agora, funcionou muito bem e parece ser seguro.


3
+1 para isso. Também uso o RD Gateway com grande sucesso e você só precisa expor a porta 443 à Internet para que ela funcione. O RD Gateway não estava suscetível a esse bug do MS12-020 de algumas semanas atrás que ameaçava o RDP.
perfil completo de Ryan Ries

+1 também há muito menos bots atacando gateways RD do que RDP direto.
Grant

8

Como a história recente nos mostrou, há riscos inerentes à exposição do protocolo. Mas, existem algumas etapas que você pode executar para proteger o sistema:

  • Impor autenticação no nível da rede.
  • Aplicar criptografia de conexão.
  • Restrinja os usuários com permissão para fazer logon nos Serviços de Terminal ao mínimo absoluto e não permita contas "especiais" como a Administratorconta de domínio padrão ou, idealmente, quaisquer outras contas de alto privilégio.
  • Verifique se as senhas são fortes nas contas com permissão para efetuar login. Depende de quantos usuários e como suas políticas são exibidas no momento, mas despeja os hashes e tenta decifrá-los, aumentando os limites no tamanho da senha ou simplesmente educando os usuários boas abordagens.

6

Eu sugiro fortemente o uso do serviço de gateway da Área de Trabalho Remota. Ele fornece um local onde você pode aplicar políticas sobre quem pode se conectar a quê e de onde. Ele fornece um bom local para o log, para que você possa ver quem está tentando fazer o login sem inspecionar os logs de eventos dos servidores individuais em seu farm.

Se você ainda não o fez, verifique se as políticas de bloqueio de conta estão bem fortes. O RDP, mesmo com o NLA e um gateway, oferece às pessoas algo para tentar usar senhas de força bruta. Uma forte política de bloqueio dificulta bastante as tentativas de força bruta.

Configure certificados SSL válidos nos sistemas, para que o cliente notifique os usuários finais se alguém estiver tentando executar algum tipo de ataque MITM.


3

Isso não é muito seguro, porém, existem algumas maneiras de fortalecer a segurança.

Proibir o acesso à Internet desse servidor. Muitos dos malwares mais graves tentam se comunicar de volta ao servidor de comando e controle quando isso compromete o sistema. A configuração de uma regra de acesso ao firewall para proibir o acesso de saída por padrão e uma regra para permitir o acesso de saída apenas a redes internas / conhecidas e sub-redes RFC 1928 podem atenuar o risco.

Use cartões inteligentes ou algum outro tipo de autenticação de dois fatores. Isso geralmente é caro e é encontrado predominantemente em grandes organizações, no entanto, as opções estão melhorando (o PhoneFactor vem à mente). Observe que a exigência de cartões inteligentes pode ser feita por servidor, como uma opção para configurá-lo no nível da conta.

Configure uma rede de perímetro, coloque o servidor de área de trabalho remota no perímetro e use uma VPN barata para fornecer o acesso. Um exemplo seria Hamachi. Observe que proibir o acesso à Internet a partir de uma rede de perímetro também é uma boa prática.

Se possível, não forneça uma área de trabalho completa, mas publique os aplicativos de que precisam. Se alguém precisar acessar apenas um único aplicativo, também é possível configurar um "programa inicial", que pode ser um simples shell wrapper que pode impor um logoff quando o aplicativo é fechado.


1

Eu sugeriria as seguintes medidas:

  1. Alterar a porta usada para a conexão de área de trabalho remota
  2. Não use nomes de usuário genéricos, mas uma política de nomeação mais complicada
  3. Requisitos de senhas altas
  4. Feche qualquer outra porta não utilizada de fora (entrada)

Opcional

  1. Use uma VPN (CISCO, Open VPN etc.) e conecte-se ao servidor usando IP interno.
  2. Use o logon do cartão inteligente, se possível

Costumo alterar a porta no firewall, não no servidor (fazê-lo no servidor requer alterações no registro). Geralmente, é mais fácil configurar uma porta para a frente no roteador e mais segura (sem registro no registro).
JohnThePro

Sim :), acabei de dizer isso porque algumas pessoas não têm acesso ou conhecimento ao encaminhamento de porta do usuário. Embora seja recomendável não alterar o registro, a menos que seja necessário, nunca tive problemas. O único problema que você pode encontrar é se você mudar para uma porta já usada.
21712 Alex H

Sim, quero dizer que não é o maior negócio do mundo, e quem conhece o regedit provavelmente é inteligente o suficiente para ter cuidado ... mas você não pode saber disso. :)
JohnThePro

1

Você pode executar o WinSSHD na porta 22 e, em seguida, usar o cliente Tunnelier para criar um túnel para você e abrir automaticamente uma sessão de serviços de terminal através do túnel com um clique. Isso também oferece uma ótima opção de FTP seguro, bem como para a transferência de arquivos.


1

Eu uso o encaminhamento de porta ssh para essas coisas e só permito autenticação no nível do usuário com base em chave pública. Todas as chaves privadas dos usuários também devem ser criptografadas. No Windows Putty, isso funciona bem e o concurso facilita o carregamento da chave pelos usuários. Se você não executar nenhum servidor Linux / BSD que possua ssh por padrão, poderá usar o OpenSSH no Cygwin para fazer isso.

Eu recomendo um servidor shell remoto dedicado com um firewall local que bloqueie coisas que você não deseja que as pessoas remotem, pois permitir o encaminhamento de porta no SSH está basicamente abrindo qualquer servidor / porta interna para os usuários que você deseja.


1

O Bitvise SSH é um bom SSH gratuito para Windows.

Eu usaria uma terminação VPN SSL barata do perímetro do cliente para o gateway da Internet para algo além do uso casual (Commercial In-Trust, por exemplo).

As postagens acima sobre como proteger o RDP também são boas práticas e sempre devem ser feitas se você não desejar compartilhar seus computadores com os carregadores de carga.


0

não é realmente a melhor prática, mas alguns pensamentos aleatórios:

  • mantenha seu sistema atualizado - permita atualizações automatizadas, não use produtos que estão no fim da vida útil,
  • use senhas longas / complicadas para todas as contas do sistema
  • Eu serei repreendido aqui por sugerir a 'segurança através da obscuridade', mas não causará nenhum dano se você:
    • altere a porta 3389 / tcp padrão para outra coisa como 26438 / tcp
    • adicione batida de porta [se possível] no nível do firewall para que o usuário potencial do rdp primeiro visite uma página da web e só então possa fazer o rdp no servidor.
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.