Tenho lido frequentemente a opinião de que manter uma porta RDP (Remote Desktop Protocol) aberta à Internet é muito inseguro e não deve ser feito. Mas você precisa conceder acesso ao RDP por meio de uma VPN ou apenas de determinados endereços IP “brancos”.
Administro vários Windows Servers para pequenas empresas onde fui encarregado de fornecer acesso remoto ao Windows Server para contadores. Esta é a tendência moderna – trabalhar em casa. Rapidamente percebi que atormentar contadores VPN é uma tarefa ingrata e coletar todos os IPs para a lista branca não funcionará, porque os endereços IP das pessoas são dinâmicos.
Portanto, segui o caminho mais simples - encaminhei a porta RDP para fora. Para obter acesso, os contadores agora precisam executar o RDP e inserir o nome do host (incluindo a porta), nome de usuário e senha.
Neste artigo vou compartilhar minha experiência (positiva e não tão positiva) e recomendações.
Riscos
O que você está arriscando ao abrir a porta RDP?
1) Acesso não autorizado a dados confidenciais
Se alguém adivinhar a senha do RDP, poderá obter dados que você deseja manter privados: status da conta, saldos, dados de clientes, ...
2) Perda de dados
Por exemplo, como resultado de um vírus ransomware.
Ou uma ação deliberada de um invasor.
3) Perda da estação de trabalho
Os trabalhadores precisam trabalhar, mas o sistema está comprometido e precisa ser reinstalado/restaurado/configurado.
4) Comprometimento da rede local
Se um invasor obtiver acesso a um computador Windows, a partir desse computador ele poderá acessar sistemas inacessíveis de fora, da Internet. Por exemplo, para compartilhamentos de arquivos, para impressoras de rede, etc.
Tive um caso em que o Windows Server detectou um ransomware
e esse ransomware primeiro criptografou a maioria dos arquivos na unidade C: e depois começou a criptografar os arquivos no NAS pela rede. Como o NAS era Synology, com snapshots configurados, restaurei o NAS em 5 minutos e reinstalei o Windows Server do zero.
Observações e Recomendações
Eu monitoro servidores Windows usando , que envia logs para o ElasticSearch. O Kibana tem diversas visualizações e também configurei um painel customizado.
O monitoramento em si não protege, mas ajuda a determinar as medidas necessárias.
Aqui estão algumas observações:
a) O RDP será de força bruta.
Em um dos servidores, instalei o RDP não na porta padrão 3389, mas na 443 - bem, vou me disfarçar de HTTPS. Provavelmente vale a pena mudar a porta padrão, mas não adiantará muito. Aqui estão as estatísticas deste servidor:
Percebe-se que em uma semana ocorreram quase 400 mil tentativas malsucedidas de login via RDP.
Percebe-se que houve tentativas de login de 55 endereços IP (alguns endereços IP já foram bloqueados por mim).
Isso sugere diretamente a conclusão de que você precisa definir o fail2ban, mas
Não existe tal utilitário para Windows.
Existem alguns projetos abandonados no Github que parecem fazer isso, mas eu nem tentei instalá-los:
Também existem serviços públicos pagos, mas não os considerei.
Se você conhece um utilitário de código aberto para essa finalidade, compartilhe-o nos comentários.
Atualizar: Os comentários sugeriram que a porta 443 é uma má escolha e é melhor escolher portas altas (32000+), porque 443 é verificada com mais frequência e reconhecer RDP nesta porta não é um problema.
b) Existem certos nomes de usuário que os invasores preferem
Percebe-se que a busca é realizada em um dicionário com nomes diversos.
Mas eis o que notei: um número significativo de tentativas usa o nome do servidor como login. Recomendação: Não use o mesmo nome para o computador e o usuário. Além disso, às vezes parece que eles estão tentando analisar o nome do servidor de alguma forma: por exemplo, para um sistema com o nome DESKTOP-DFTHD7C, a maioria das tentativas de login são com o nome DFTHD7C:
Assim, se você possui um computador DESKTOP-MARIA, provavelmente tentará fazer login como usuário MARIA.
Outra coisa que notei nos logs: na maioria dos sistemas, a maioria das tentativas de login são com o nome “administrador”. E isso não é sem razão, porque em muitas versões do Windows esse usuário existe. Além disso, não pode ser excluído. Isso simplifica a tarefa dos invasores: em vez de adivinhar um nome e uma senha, você só precisa adivinhar a senha.
Aliás, o sistema que capturou o ransomware tinha o usuário Administrador e a senha Murmansk#9. Ainda não tenho certeza de como esse sistema foi hackeado, porque comecei a monitorar logo após o incidente, mas acho que é provável que seja um exagero.
Portanto, se o usuário Administrador não puder ser excluído, o que você deve fazer? Você pode renomeá-lo!
Recomendações deste parágrafo:
- não use o nome de usuário no nome do computador
- certifique-se de que não haja nenhum usuário administrador no sistema
- use senhas fortes
Então, tenho observado vários servidores Windows sob meu controle sendo submetidos à força bruta há cerca de alguns anos, e sem sucesso.
Como posso saber se não teve sucesso?
Porque nas capturas de tela acima você pode ver que existem registros de chamadas RDP bem-sucedidas, que contêm as informações:
- de qual IP
- de qual computador (nome do host)
- username
- Informações GeoIP
E eu verifico lá regularmente - nenhuma anomalia foi encontrada.
A propósito, se um IP específico estiver sendo submetido a força bruta de maneira particularmente difícil, você poderá bloquear IPs individuais (ou sub-redes) como este no PowerShell:
New-NetFirewallRule -Direction Inbound -DisplayName "fail2ban" -Name "fail2ban" -RemoteAddress ("185.143.0.0/16", "185.153.0.0/16", "193.188.0.0/16") -Action BlockAliás, o Elastic, além do Winlogbeat, também tem , que pode monitorar arquivos e processos no sistema. Há também um aplicativo SIEM (Security Information & Event Management) no Kibana. Tentei os dois, mas não vi muitos benefícios - parece que o Auditbeat será mais útil para sistemas Linux, e o SIEM ainda não me mostrou nada inteligível.
Bem, recomendações finais:
- Faça backups automáticos regulares.
- instale atualizações de segurança em tempo hábil
Bônus: lista de 50 usuários usados com mais frequência para tentativas de login RDP
"nome do usuário: descendente"
Contar
dfthd7c (nome do host)
842941
winrv1 (nome do host)
266525
ADMINISTRADOR
180678
administrador
163842
Administrador
53541
michael
23101
servidor
21983
steve
21936
banheiro
21927
paul
21913
recepção
21909
Mike
21899
escritório
21888
digitalizador
21887
digitalização
21867
david
21865
chris
21860
proprietário
21855
Gerente
21852
administrateur
21841
brian
21839
administrador
21837
marca
21824
para
21806
ADMIN
12748
ROOT
7772
ADMINISTRADOR
7325
SUPPORT
5577
APOIO
5418
USUÁRIO
4558
admin
2832
TESTE
1928
MySql
1664
Administrador
1652
GUEST
1322
USUÁRIO1
1179
LEITOR
1121
SCAN
1032
ADMINISTRADOR
842
ADMIN1
525
BACKUP
518
MySqlAdmin
518
RECEPÇÃO
490
USUÁRIO2
466
TEMP
452
SQLADMIN
450
USUÁRIO3
441
1
422
MANAGER
418
PROPRIETÁRIO
410
Fonte: habr.com