A menudo he leído la opinión de que mantener el puerto RDP (Protocolo de Escritorio Remoto) abierto a Internet es bastante inseguro y no se debería hacer. Se debería permitir el acceso a RDP solo a través de VPN o desde ciertas direcciones IP "blancas".
Administro varios servidores Windows para pequeñas empresas, donde se me ha encargado proporcionar acceso remoto a Windows Server para contadores. Esta es una tendencia moderna: trabajar desde casa. Rápidamente 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ía posible, ya que las direcciones IP de la gente son dinámicas.
Por lo tanto, opté por la solución más 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ña.
En este artículo compartiré mi experiencia (tanto positiva como negativa) y recomendaciones.
Riesgos
¿Qué riesgos corre al abrir el puerto RDP?
1) Acceso no autorizado a datos sensibles
Si alguien adivina la contraseña de RDP, podrá acceder a datos que quiere mantener en privado: saldo de cuentas, balances, datos de clientes, ...
2) Pérdida de datos
Por ejemplo, como resultado de la acción de un virus de cifrado.
O una acción deliberada de un atacante.
3) Pérdida de estación de trabajo
Los empleados necesitan trabajar y el sistema está comprometido, es necesario reinstalar/restaurar/configurar.
4) Compromiso de la red local
Si un atacante obtiene acceso a una computadora con Windows, desde esa computadora podrá acceder a sistemas que no son accesibles desde el exterior, desde Internet. Por ejemplo, a unidades compartidas, impresoras de red, etc.
Tuve un caso en el que un servidor Windows fue infectado por un cifrador
y este cifrador en primer lugar cifró la mayoría de los archivos en el disco C:, y luego comenzó a cifrar archivos en el NAS a través 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é desde cero.
Observaciones y Recomendaciones
Monitoreo mis servidores Windows con , que envían registros a ElasticSearch. En Kibana hay varias visualizaciones, y también configuré un panel personalizado.
El monitoreo en sí no protege, pero ayuda a determinar las medidas necesarias.
Aquí algunas observaciones:
a) El RDP será sometido a ataques de fuerza bruta.
En uno de los servidores, configuré RDP en un puerto que no es el estándar 3389, sino en el 443, para enmascararlo como HTTPS. Cambiar el puerto de estándar, probablemente sea una buena idea, pero la utilidad de esto es mínima. Aquí está la estadística de este servidor:
Se puede ver que en una semana hubo casi 400,000 intentos fallidos de acceder por RDP.
Se observa que los intentos de acceso provinieron de 55,001 direcciones IP (algunas de las cuales ya han sido bloqueadas por mí).
Aquí se plantea la conclusión de que es necesario instalar fail2ban, pero
no hay tal utilidad para Windows.
Hay un par de proyectos abandonados en GitHub que supuestamente hacen esto, pero ni siquiera he intentado instalarlos:
También hay utilidades de pago, pero no las he considerado.
Si conoces una utilidad abierta para este fin, compártela en los comentarios.
mensaje de Update.: En los comentarios me sugirieron que el puerto 443 no es una buena elección, y que es mejor elegir puertos altos (32000+), porque el 443 se escanea con más frecuencia, y reconocer RDP en este puerto no es un problema.
Update: En los comentarios me mencionaron que existe tal utilidad:
b) Hay ciertos nombres de usuario que los atacantes prefieren.
Se puede ver que el ataque se lleva a cabo utilizando un diccionario con diferentes nombres.
Pero lo que he notado es que una cantidad significativa de intentos utiliza el nombre del servidor como nombre de usuario. Recomendación: 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ía de los intentos vienen con el nombre DFTHD7C:
Por lo tanto, si tienes una computadora DESKTOP-MARIA, probablemente habrá intentos de acceder con el usuario MARIA.
Además, lo que he notado en los registros: en la mayoría de los sistemas, la mayoría de los intentos de acceso son con el nombre "administrator". Y esto no es casualidad, porque en muchas versiones de Windows, este usuario existe. Además, no se puede eliminar. Esto facilita la tarea para los atacantes: en lugar de tener que adivinar un nombre y contraseña, solo necesitan adivinar la contraseña.
Por cierto, el sistema que captó al ransomware tenía el usuario Administrator y la contraseña Murmansk#9. Aún no estoy seguro de cómo fue hackeado ese sistema, porque comencé a monitorearlo justo después de ese incidente, pero creo que el brute force es probable.
Entonces, si no se puede eliminar al usuario Administrator, ¿qué se puede hacer? ¡Se puede renombrar!
Recomendaciones de este punto:
- no utilices el nombre de usuario en el nombre de la computadora.
- asegúrate de que no haya usuarios con el nombre Administrator en el sistema
- utiliza contraseñas seguras
De esta manera, he estado observando cómo varios servidores Windows bajo mi control han sido objeto de ataques de fuerza bruta durante aproximadamente un par de años, sin éxito.
¿Cómo sé que no han tenido éxito?
Porque en las capturas de pantalla anteriores se puede ver que hay registros de accesos exitosos por RDP, donde se incluye información:
- desde qué IP
- desde qué computadora (nombre del host)
- nombre de usuario
- información de GeoIP
Y reviso esto regularmente — no he encontrado anomalías.
Por cierto, si desde alguna IP se intenta forzar el acceso con especial ímpetu, se puede bloquear direcciones IP individuales (o subredes) así en 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 BlockAdemás de Winlogbeat, Elastic también tiene , que puede monitorear archivos y procesos en el sistema. También hay una aplicación SIEM (Gestión de Información y Eventos de Seguridad) en Kibana. He probado ambas, pero no he visto mucho beneficio — parece que Auditbeat será más útil para sistemas Linux, y SIEM no me ha mostrado nada claro hasta ahora.
Y las recomendaciones finales:
- realiza copias de seguridad automáticas regularmente.
- instala actualizaciones de seguridad a tiempo.
Bono: lista de 50 usuarios que se han utilizado con mayor frecuencia para intentos de acceso por RDP
"user.name: Descending"
Contar
dfthd7c (nombre del host)
842941
winsrv1 (nombre del host)
266525
ADMINISTRATOR
180678
administrador
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
propietario
21855
manager
21852
administrateur
21841
brian
21839
Administrador
21837
mark
21824
staff
21806
ADMIN
12748
ROOT
7772
ADMINISTRADOR
7325
SUPPORT
5577
SOPORTE
5418
USER
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
A menudo he leído la opinión de que mantener el puerto RDP (Protocolo de Escritorio Remoto) abierto en Internet es bastante inseguro, y que no se debe hacer.
410
Fuente: habr.com
