{"id":41229,"date":"2020-02-06T20:43:00","date_gmt":"2020-02-06T17:43:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/opasno-li-derzhat-otkrytym-rdp-v-internete"},"modified":"2020-02-06T20:43:00","modified_gmt":"2020-02-06T17:43:00","slug":"opasno-li-derzhat-otkrytym-rdp-v-internete","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pt\/blog\/opasno-li-derzhat-otkrytym-rdp-v-internete","title":{"rendered":"\u00c9 perigoso manter o RDP aberto na Internet?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Frequentemente, ou\u00e7o a opini\u00e3o de que manter a porta RDP (Remote Desktop Protocol) aberta na Internet \u00e9 bastante inseguro e que n\u00e3o se deve fazer isso. O acesso ao RDP deve ser fornecido ou atrav\u00e9s de VPN, ou apenas de determinados endere\u00e7os IP 'brancos'.<\/p>\n

<\/p>\n

Administro v\u00e1rios Servidores Windows para pequenas empresas, nas quais me foi dada a tarefa de garantir o acesso remoto ao Windows Server para os contadores. Essa \u00e9 uma tend\u00eancia moderna \u2014 trabalho de casa. Rapidamente percebi que for\u00e7ar os contadores a usarem VPN \u00e9 uma tarefa ingrata, e coletar todos os IPs para a lista branca n\u00e3o ser\u00e1 poss\u00edvel, pois os endere\u00e7os IP das pessoas s\u00e3o din\u00e2micos.<\/p>\n

<\/p>\n

Portanto, segui o caminho mais simples \u2014 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\u00e1rio e a senha.<\/p>\n

<\/p>\n

Neste artigo, compartilharei experi\u00eancias (tanto positivas quanto n\u00e3o t\u00e3o boas) e recomenda\u00e7\u00f5es.<\/p>\n

<\/a><\/noindex><\/p>\n

Riscos<\/h3>\n

<\/p>\n

Quais s\u00e3o os riscos ao abrir a porta RDP?<\/p>\n

<\/p>\n

1) Acesso n\u00e3o autorizado a dados sens\u00edveis<\/b>
\nSe algu\u00e9m descobrir a senha do RDP, poder\u00e1 acessar dados que voc\u00ea deseja manter privados: estado das contas, saldos, dados de clientes, \u2026<\/p>\n

<\/p>\n

2) Perda de dados<\/b>
\nPor exemplo, como resultado da a\u00e7\u00e3o de um v\u00edrus criptografador.
\nOu a a\u00e7\u00e3o deliberada de um invasor.<\/p>\n

<\/p>\n

3) Perda da esta\u00e7\u00e3o de trabalho<\/b>
\nOs funcion\u00e1rios precisam trabalhar, mas o sistema est\u00e1 comprometido, precisando ser reinstalado \/ restaurado \/ configurado.<\/p>\n

<\/p>\n

4) Comprometimento da rede local<\/b>
\nSe um invasor obteve acesso a um computador Windows, ele poder\u00e1 acessar sistemas que n\u00e3o est\u00e3o dispon\u00edveis externamente, pela Internet. Por exemplo, compartilhamentos de arquivos, impressoras de rede etc.<\/p>\n

\nTive um caso em que um Servidor Windows foi infectado por um criptografador<\/b><\/p>\n

e esse criptografador inicialmente criptografou a maioria dos arquivos no disco C:, e depois come\u00e7ou a criptografar arquivos no NAS via rede. Como o NAS era da Synology, com snapshots configurados, consegui restaur\u00e1-lo em 5 minutos, enquanto reinstalei o Servidor Windows do zero.<\/p>\n

<\/p>\n

Observa\u00e7\u00f5es e Recomenda\u00e7\u00f5es<\/h3>\n

<\/p>\n

Monitoro os Servidores Windows atrav\u00e9s de Winlogbeat<\/a><\/noindex>, que envia logs para o ElasticSearch. No Kibana, h\u00e1 v\u00e1rias visualiza\u00e7\u00f5es, e ainda configurei um painel personalizado.
\nA monitoriza\u00e7\u00e3o em si n\u00e3o protege, mas ajuda a determinar as medidas necess\u00e1rias.<\/p>\n

<\/p>\n

Aqui est\u00e3o algumas observa\u00e7\u00f5es:
\na) O RDP ser\u00e1 alvo de ataques de for\u00e7a bruta.<\/b>
\nEm um dos servidores, configurei o RDP n\u00e3o na porta padr\u00e3o 3389, mas na 443 \u2014 para me camuflar como HTTPS. Mudar a porta padr\u00e3o \u00e9, provavelmente, uma boa ideia, mas isso n\u00e3o traz muitos benef\u00edcios. Aqui est\u00e3o as estat\u00edsticas deste servidor:<\/p>\n

\n\"\u00c9<\/p>\n

\u00c9 vis\u00edvel que, em uma semana, houve quase 400.000 tentativas falhadas de acesso via RDP.
\nObserva-se que as tentativas de acesso vieram de 55.001 endere\u00e7os IP (alguns IPs j\u00e1 estavam bloqueados por mim).<\/p>\n

<\/p>\n

Aqui j\u00e1 se pode concluir que \u00e9 necess\u00e1rio instalar o fail2ban, mas <\/p>\n

\nPara Windows, n\u00e3o existe tal utilit\u00e1rio.<\/b><\/p>\n

Existem alguns projetos abandonados no GitHub que supostamente fazem isso, mas sequer tentei instal\u00e1-los:
\nhttps:\/\/github.com\/glasnt\/wail2ban<\/a><\/noindex>
\nhttps:\/\/github.com\/EvanAnderson\/ts_block<\/a><\/noindex><\/p>\n

<\/p>\n

Ainda h\u00e1 utilit\u00e1rios pagos, mas n\u00e3o os considerei.<\/p>\n

<\/p>\n

Se voc\u00ea conhecer um utilit\u00e1rio aberto para esse fim \u2014 compartilhe nos coment\u00e1rios.<\/p>\n

<\/p>\n

Atualizar<\/strong>: Nos coment\u00e1rios, sugeriram que a porta 443 n\u00e3o \u00e9 uma boa escolha, e que seria melhor optar por portas mais altas (acima de 32000), pois a 443 \u00e9 escaneada com mais frequ\u00eancia, e identificar o RDP nessa porta n\u00e3o \u00e9 um problema.<\/p>\n

<\/p>\n

Update:<\/strong> Nos coment\u00e1rios, disseram que existe tal utilit\u00e1rio:
\nhttps:\/\/github.com\/digitalruby\/ipban<\/a><\/noindex><\/p>\n

<\/p>\n

b) Existem certos nomes de usu\u00e1rio que os invasores preferem.<\/b>
\nObserva-se que o ataque \u00e9 feito com uma combina\u00e7\u00e3o de nomes.
\nMas uma coisa que notei: uma quantidade significativa de tentativas usa o nome do servidor como login. Recomenda\u00e7\u00e3o: n\u00e3o use o mesmo nome para o computador e para o usu\u00e1rio. Al\u00e9m 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:<\/p>\n

\n\"\u00c9<\/p>\n

Consequentemente, se voc\u00ea tiver um computador chamado DESKTOP-MARIA, provavelmente haver\u00e1 tentativas de acesso com o usu\u00e1rio MARIA.<\/p>\n

<\/p>\n

Al\u00e9m disso, o que percebi pelos logs: na maioria dos sistemas, a maior parte das tentativas de acesso \u00e9 feita com o nome 'administrator'. E isso n\u00e3o \u00e9 \u00e0 toa, pois em muitas vers\u00f5es do Windows, esse usu\u00e1rio existe. Al\u00e9m disso, n\u00e3o pode ser removido. Isso facilita a tarefa para os invasores: em vez de adivinhar o nome e a senha, \u00e9 necess\u00e1rio apenas adivinhar a senha.
\nPor sinal, o sistema que foi infectado por um ransomware tinha o usu\u00e1rio Administrator e a senha Murmansk#9. N\u00e3o estou certo de como aquela m\u00e1quina foi invadida, porque comecei a monitorar justo depois desse incidente, mas acredito que a for\u00e7a bruta \u00e9 uma possibilidade.
\nEnt\u00e3o, se o usu\u00e1rio Administrator n\u00e3o pode ser removido, o que fazer? Ele pode ser renomeado!<\/p>\n

<\/p>\n

As recomenda\u00e7\u00f5es deste ponto: <\/p>\n

<\/p>\n