Muitas vezes li a opinião de que deixar a porta RDP (Remote Desktop Protocol) aberta na Internet é bastante inseguro e que isso não deve ser feito. O acesso ao RDP deve ser fornecido através de VPN ou apenas a partir de determinados endereços IP "brancos".
Administro vários Servidores Windows para pequenas empresas, nas quais me foi dada a tarefa de garantir o acesso remoto ao Windows Server para os contadores. Essa é uma tendência moderna — trabalho de casa. Rapidamente percebi que forçar os contadores a usarem VPN é uma tarefa ingrata, e coletar todos os IPs para a lista branca não será possível, pois os endereços IP das pessoas são dinâmicos.
Portanto, segui o caminho mais simples — redirecionei a porta RDP para fora. Agora, para acessar, os contadores precisam iniciar o RDP e inserir o nome do host (incluindo a porta), o nome de usuário e a senha.
Neste artigo, compartilharei experiências (tanto positivas quanto não tão boas) e recomendações.
Riscos
Quais são os riscos ao abrir a porta RDP?
1) Acesso não autorizado a dados sensíveis
Se alguém descobrir a senha do RDP, poderá acessar dados que você deseja manter privados: saldo de contas, dados de clientes, …
2) Perda de dados
Por exemplo, como resultado da ação de um vírus criptografador.
Ou a ação deliberada de um invasor.
3) Perda da estação de trabalho
Os funcionários precisam trabalhar, mas o sistema está comprometido, precisando ser reinstalado / restaurado / configurado.
4) Comprometimento da rede local
Se um invasor obteve acesso a um computador Windows, ele poderá acessar sistemas que não estão disponíveis externamente, pela Internet. Por exemplo, compartilhamentos de arquivos, impressoras de rede etc.
Tive um caso em que um Servidor Windows foi infectado por um criptografador
e esse criptografador inicialmente criptografou a maioria dos arquivos no disco C:, e depois começou a criptografar arquivos no NAS via rede. Como o NAS era da Synology, com snapshots configurados, consegui restaurá-lo em 5 minutos, enquanto reinstalei o Servidor Windows do zero.
Observações e Recomendações
Monitoro os Servidores Windows através de , que envia logs para o ElasticSearch. No Kibana, há várias visualizações, e ainda configurei um painel personalizado.
A monitorização em si não protege, mas ajuda a determinar as medidas necessárias.
Aqui estão algumas observações:
a) O RDP será alvo de ataques de força bruta.
Em um dos servidores, configurei o RDP não na porta padrão 3389, mas na 443 — para me camuflar como HTTPS. Mudar a porta padrão é, provavelmente, uma boa ideia, mas isso não traz muitos benefícios. Aqui estão as estatísticas deste servidor:
É visível que, em uma semana, houve quase 400.000 tentativas falhadas de acesso via RDP.
Observa-se que as tentativas de acesso vieram de 55.001 endereços IP (alguns IPs já estavam bloqueados por mim).
Aqui já se pode concluir que é necessário instalar o fail2ban, mas
não existe tal utilitário para Windows.
Existem alguns projetos abandonados no GitHub que supostamente fazem isso, mas sequer tentei instalá-los:
Ainda há utilitários pagos, mas não os considerei.
Se você conhecer um utilitário aberto para esse fim — compartilhe nos comentários.
Atualizar: Nos comentários, sugeriram que a porta 443 não é uma boa escolha, e que seria melhor optar por portas mais altas (acima de 32000), pois a 443 é escaneada com mais frequência, e identificar o RDP nessa porta não é um problema.
Update: Nos comentários, disseram que existe tal utilitário:
b) Existem certos nomes de usuário que os invasores preferem.
Observa-se que o ataque é feito com uma combinação de nomes.
Mas uma coisa que notei: uma quantidade significativa de tentativas usa o nome do servidor como login. Recomendação: não use o mesmo nome para o computador e para o usuário. Além disso, algumas vezes, o nome do servidor parece ser analisado de alguma forma: por exemplo, para um sistema chamado DESKTOP-DFTHD7C, houve mais tentativas de acesso com o nome DFTHD7C:
Consequentemente, se você tiver um computador chamado DESKTOP-MARIA, provavelmente haverá tentativas de acesso com o usuário MARIA.
Além disso, o que notei nos logs: na maioria dos sistemas, a maioria das tentativas de acesso fica com o nome "administrator". E isso não é à toa, pois em muitas versões do Windows, esse usuário existe. Além disso, não pode ser removido. Isso facilita a vida dos invasores: ao invés de ter que adivinhar o nome e a senha, precisam apenas adivinhar a senha.
Por sinal, o sistema que foi infectado por um ransomware tinha o usuário Administrator e a senha Murmansk#9. Não estou certo de como aquela máquina foi invadida, porque comecei a monitorar justo depois desse incidente, mas acredito que a força bruta é uma possibilidade.
Então, se o usuário Administrator não pode ser removido, o que fazer? Ele pode ser renomeado!
As recomendações deste ponto:
- não use o nome de usuário no nome do computador
- certifique-se de que não há usuários Administrator no sistema
- use senhas seguras
Dessa forma, eu vejo que vários Windows Server sob meu controle estão sendo atacados por brute force há alguns anos, e sem sucesso.
Como sei que sem sucesso?
Porque nas capturas de tela acima, é possível ver que há logs de acessos bem-sucedidos via RDP, que contêm a informação:
- de qual IP
- de qual computador (hostname)
- nome de usuário
- informações de GeoIP
E eu olho isso regularmente — não foram encontradas anomalias.
Aliás, se algum IP está realizando ataques brute force de forma especialmente intensa, pode-se bloquear IPs (ou sub-redes) específicos assim 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 BlockA propósito, na Elastic, além do Winlogbeat, também existe , que pode monitorar arquivos e processos no sistema. Também existe um aplicativo SIEM (Gerenciamento de Informações e Eventos de Segurança) no Kibana. Eu experimentei ambos, mas não vi muita utilidade — parece que o Auditbeat será mais útil para sistemas Linux, e o SIEM ainda não me apresentou nada claro.
E aqui estão as 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 que foram mais usados nas tentativas de acesso via RDP
"user.name: Descending"
Contagem
dfthd7c (hostname)
842941
winsrv1 (hostname)
266525
ADMINISTRATOR
180678
administrator
163842
Administrator
53541
michael
23101
servidor
21983
steve
21936
john
21927
paul
21913
reception
21909
mike
21899
office
21888
scanner
21887
scan
21867
david
21865
chris
21860
owner
21855
manager
21852
administrateur
21841
brian
21839
administrador
21837
mark
21824
staff
21806
ADMIN
12748
ROOT
7772
ADMINISTRADOR
7325
SUPPORT
5577
SOPORTE
5418
USUÁRIO
4558
admin
2832
TEST
1928
MySql
1664
Admin
1652
GUEST
1322
USER1
1179
SCANNER
1121
SCAN
1032
ADMINISTRATEUR
842
ADMIN1
525
BACKUP
518
MySqlAdmin
518
RECEPTION
490
USER2
466
TEMP
452
SQLADMIN
450
USER3
441
1
422
MANAGER
418
É comum ler a opinião de que deixar a porta RDP (Remote Desktop Protocol) aberta na Internet é bastante inseguro, e não se deve fazer isso.
410
Fonte: habr.com
