{"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\/es\/blog\/opasno-li-derzhat-otkrytym-rdp-v-internete","title":{"rendered":"\u00bfEs peligroso mantener RDP abierto en Internet?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

A menudo he le\u00eddo la opini\u00f3n de que mantener el puerto RDP (Remote Desktop Protocol) abierto en Internet es bastante inseguro y que no se deber\u00eda hacer. Es mejor permitir el acceso a RDP solo a trav\u00e9s de una VPN o \u00fanicamente desde ciertas direcciones IP 'blancas'.<\/p>\n

<\/p>\n

Administro varios servidores Windows para peque\u00f1as empresas, donde se me ha encargado proporcionar acceso remoto a Windows Server para contadores. Esta es una tendencia moderna: trabajar desde casa. R\u00e1pidamente me di cuenta de que hacer sufrir a los contadores con VPN no era una tarea agradecida, y que reunir todas las IPs para la lista blanca no ser\u00eda posible, ya que las direcciones IP de la gente son din\u00e1micas.<\/p>\n

<\/p>\n

Por lo tanto, opt\u00e9 por la soluci\u00f3n m\u00e1s simple: expuse el puerto RDP al exterior. Ahora, para que los contadores puedan acceder, necesitan iniciar RDP e ingresar el nombre del host (incluido el puerto), el nombre de usuario y la contrase\u00f1a.<\/p>\n

<\/p>\n

En este art\u00edculo compartir\u00e9 mi experiencia (tanto positiva como negativa) y recomendaciones.<\/p>\n

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

Riesgos<\/h3>\n

<\/p>\n

\u00bfQu\u00e9 riesgos corre al abrir el puerto RDP?<\/p>\n

<\/p>\n

1) Acceso no autorizado a datos sensibles<\/b>
\nSi alguien consigue adivinar la contrase\u00f1a de RDP, podr\u00e1 acceder a datos que desea mantener en privado: estado de cuentas, balances, datos de clientes, \u2026<\/p>\n

<\/p>\n

2) P\u00e9rdida de datos<\/b>
\nPor ejemplo, como resultado de la acci\u00f3n de un virus de cifrado.
\nO una acci\u00f3n deliberada de un atacante.<\/p>\n

<\/p>\n

3) P\u00e9rdida de estaci\u00f3n de trabajo<\/b>
\nLos empleados necesitan trabajar y el sistema est\u00e1 comprometido, es necesario reinstalar\/restaurar\/configurar.<\/p>\n

<\/p>\n

4) Compromiso de la red local<\/b>
\nSi un atacante obtiene acceso a una computadora con Windows, desde esa computadora podr\u00e1 acceder a sistemas que no son accesibles desde el exterior, desde Internet. Por ejemplo, a unidades compartidas, impresoras de red, etc.<\/p>\n

\nTuve un caso en el que un servidor Windows fue infectado por un cifrador<\/b><\/p>\n

y este cifrador en primer lugar cifr\u00f3 la mayor\u00eda de los archivos en el disco C:, y luego comenz\u00f3 a cifrar archivos en el NAS a trav\u00e9s de la red. Dado que el NAS era un Synology, con snapshots configurados, pude recuperar el NAS en 5 minutos, mientras que el servidor Windows lo reinstal\u00e9 desde cero.<\/p>\n

<\/p>\n

Observaciones y Recomendaciones<\/h3>\n

<\/p>\n

Monitoreo mis servidores Windows con Winlogbeat<\/a><\/noindex>, que env\u00edan registros a ElasticSearch. En Kibana hay varias visualizaciones, y tambi\u00e9n configur\u00e9 un panel personalizado.
\nEl monitoreo en s\u00ed no protege, pero ayuda a determinar las medidas necesarias.<\/p>\n

<\/p>\n

Aqu\u00ed algunas observaciones:
\na) El RDP ser\u00e1 sometido a ataques de fuerza bruta.<\/b>
\nEn uno de los servidores, configur\u00e9 RDP en un puerto que no es el est\u00e1ndar 3389, sino en el 443, para enmascararlo como HTTPS. Cambiar el puerto de est\u00e1ndar, probablemente sea una buena idea, pero la utilidad de esto es m\u00ednima. Aqu\u00ed est\u00e1 la estad\u00edstica de este servidor:<\/p>\n

\n\"\u00bfEs<\/p>\n

Se puede ver que en una semana hubo casi 400,000 intentos fallidos de acceder por RDP.
\nSe observa que los intentos de acceso provinieron de 55,001 direcciones IP (algunas de las cuales ya han sido bloqueadas por m\u00ed).<\/p>\n

<\/p>\n

Aqu\u00ed se plantea la conclusi\u00f3n de que es necesario instalar fail2ban, pero <\/p>\n

\nNo hay tal utilidad para Windows.<\/b><\/p>\n

Hay un par de proyectos abandonados en GitHub que supuestamente hacen esto, pero ni siquiera he intentado instalarlos:
\nhttps:\/\/github.com\/glasnt\/wail2ban<\/a><\/noindex>
\nhttps:\/\/github.com\/EvanAnderson\/ts_block<\/a><\/noindex><\/p>\n

<\/p>\n

Tambi\u00e9n hay utilidades de pago, pero no las he considerado.<\/p>\n

<\/p>\n

Si conoces una utilidad abierta para este fin, comp\u00e1rtela en los comentarios.<\/p>\n

<\/p>\n

mensaje de Update.<\/strong>: En los comentarios me sugirieron que el puerto 443 no es una buena elecci\u00f3n, y que es mejor elegir puertos altos (32000+), porque el 443 se escanea con m\u00e1s frecuencia, y reconocer RDP en este puerto no es un problema.<\/p>\n

<\/p>\n

Update:<\/strong> En los comentarios me mencionaron que existe tal utilidad:
\nhttps:\/\/github.com\/digitalruby\/ipban<\/a><\/noindex><\/p>\n

<\/p>\n

b) Hay ciertos nombres de usuario que los atacantes prefieren.<\/b>
\nSe puede ver que el ataque se lleva a cabo utilizando un diccionario con diferentes nombres.
\nPero lo que he notado es que una cantidad significativa de intentos utiliza el nombre del servidor como nombre de usuario. Recomendaci\u00f3n: no uses el mismo nombre para la computadora que para el usuario. De hecho, a veces parece que intentan parsear el nombre del servidor: por ejemplo, para un sistema con el nombre DESKTOP-DFTHD7C, la mayor\u00eda de los intentos vienen con el nombre DFTHD7C:<\/p>\n

\n\"\u00bfEs<\/p>\n

Por lo tanto, si tienes una computadora DESKTOP-MARIA, probablemente habr\u00e1 intentos de acceder con el usuario MARIA.<\/p>\n

<\/p>\n

Adem\u00e1s, he notado en los logs que en la mayor\u00eda de los sistemas, la mayor\u00eda de los intentos de acceso son con el nombre 'administrator'. Y esto no es casualidad, ya que en muchas versiones de Windows, este usuario existe. Adem\u00e1s, no se puede eliminar. Esto facilita las cosas para los atacantes; en lugar de tener que adivinar un nombre y una contrase\u00f1a, solo tienen que adivinar la contrase\u00f1a.
\nPor cierto, el sistema que capt\u00f3 al ransomware ten\u00eda el usuario Administrator y la contrase\u00f1a Murmansk#9. A\u00fan no estoy seguro de c\u00f3mo fue hackeado ese sistema, porque comenc\u00e9 a monitorearlo justo despu\u00e9s de ese incidente, pero creo que el brute force es probable.
\nEntonces, si no se puede eliminar al usuario Administrator, \u00bfqu\u00e9 se puede hacer? \u00a1Se puede renombrar!<\/p>\n

<\/p>\n

Recomendaciones de este punto: <\/p>\n

<\/p>\n