A menudo he leído la opinión de que mantener un puerto RDP (Protocolo de escritorio remoto) abierto a Internet es muy inseguro y no se debe hacer. Pero debes dar acceso a RDP a través de una VPN o sólo desde ciertas direcciones IP "blancas".
Administro varios servidores Windows para pequeñas empresas donde se me ha asignado la tarea de proporcionar acceso remoto a Windows Server para contadores. Ésta es la tendencia moderna: trabajar desde casa. Rápidamente me di cuenta de que atormentar a los contables de VPN es una tarea ingrata y que recopilar todas las IP para la lista blanca no funcionará, porque las direcciones IP de las personas son dinámicas.
Por lo tanto, tomé la ruta más simple: reenvié el puerto RDP al exterior. Para obtener acceso, los contables ahora deben ejecutar RDP e ingresar el nombre de host (incluido el puerto), el nombre de usuario y la contraseña.
En este artículo compartiré mi experiencia (positiva y no tan positiva) y recomendaciones.
Riesgos
¿A qué te arriesgas al abrir el puerto RDP?
1) Acceso no autorizado a datos sensibles
Si alguien adivina la contraseña RDP podrá obtener datos que desea mantener en privado: estado de cuenta, saldos, datos de clientes,…
2) Pérdida de datos
Por ejemplo, como resultado de un virus ransomware.
O una acción deliberada de un atacante.
3) Pérdida de la estación de trabajo
Los trabajadores necesitan trabajar, pero el sistema está comprometido y es necesario reinstalarlo, restaurarlo o configurarlo.
4) Compromiso de la red local
Si un atacante ha obtenido acceso a una computadora con Windows, desde esta computadora podrá acceder a sistemas que son inaccesibles desde el exterior, desde Internet. Por ejemplo, para compartir archivos, para impresoras de red, etc.
Tuve un caso en el que Windows Server detectó un ransomware
y este ransomware primero cifró la mayoría de los archivos en la unidad C: y luego comenzó a cifrar los archivos en el NAS a través de la red. Como el NAS era Synology, con las instantáneas configuradas, restauré el NAS en 5 minutos y reinstalé Windows Server desde cero.
Observaciones y recomendaciones
Superviso servidores Windows usando , que envía registros a ElasticSearch. Kibana tiene varias visualizaciones y también configuro un panel personalizado.
El seguimiento por sí solo no protege, pero ayuda a determinar las medidas necesarias.
He aquí algunas observaciones:
a) RDP será de fuerza bruta.
En uno de los servidores, instalé RDP no en el puerto estándar 3389, sino en el 443; bueno, me disfrazaré de HTTPS. Probablemente valga la pena cambiar el puerto estándar, pero no servirá de mucho. Aquí están las estadísticas de este servidor:
Se puede observar que en una semana hubo casi 400 intentos fallidos de iniciar sesión a través de RDP.
Se puede ver que hubo intentos de iniciar sesión desde 55 direcciones IP (algunas direcciones IP ya estaban bloqueadas por mí).
Esto sugiere directamente la conclusión de que es necesario configurar fail2ban, pero
No existe tal utilidad para Windows.
Hay un par de proyectos abandonados en Github que parecen hacer esto, pero ni siquiera he intentado instalarlos:
También hay servicios públicos pagos, pero no los he considerado.
Si conoce una utilidad de código abierto para este propósito, compártala en los comentarios.
Actualizar: Los comentarios sugirieron que el puerto 443 es una mala 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.
b) Hay ciertos nombres de usuario que los atacantes prefieren
Se puede observar que la búsqueda se realiza en un diccionario con diferentes nombres.
Pero esto es lo que noté: una cantidad significativa de intentos utilizan el nombre del servidor como inicio de sesión. Recomendación: No utilice el mismo nombre para la computadora y el usuario. Además, a veces parece que están intentando analizar el nombre del servidor de alguna manera: por ejemplo, para un sistema con el nombre DESKTOP-DFTHD7C, la mayoría de los intentos de iniciar sesión son con el nombre DFTHD7C:
En consecuencia, si tiene una computadora DESKTOP-MARIA, probablemente intentará iniciar sesión como usuario MARIA.
Otra cosa que noté en los registros: en la mayoría de los sistemas, la mayoría de los intentos de iniciar sesión se realizan con el nombre "administrador". Y esto no en vano, porque en muchas versiones de Windows este usuario existe. Además, no se puede eliminar. Esto simplifica la tarea para los atacantes: en lugar de adivinar un nombre y una contraseña, sólo necesita adivinar la contraseña.
Por cierto, el sistema que detectó el ransomware tenía el usuario Administrador y la contraseña Murmansk#9. Todavía no estoy seguro de cómo se pirateó ese sistema, porque comencé a monitorear justo después de ese incidente, pero creo que es probable que se exagere.
Entonces, si el usuario Administrador no se puede eliminar, ¿qué debe hacer? ¡Puedes cambiarle el nombre!
Recomendaciones de este párrafo:
- no utilice el nombre de usuario en el nombre de la computadora
- asegúrese de que no haya ningún usuario administrador en el sistema
- usar contraseñas seguras
Entonces, he estado observando cómo varios servidores Windows bajo mi control sufren fuerza bruta durante un par de años y sin éxito.
¿Cómo sé que no tuvo éxito?
Porque en las capturas de pantalla anteriores puedes ver que hay registros de llamadas RDP exitosas, que contienen la información:
- de que ip
- desde qué computadora (nombre de host)
- имя пользователя
- Información GeoIP
Y lo reviso periódicamente: no se han encontrado anomalías.
Por cierto, si una IP en particular está siendo sometida a fuerza bruta con especial fuerza, entonces puede bloquear IP individuales (o subredes) de esta manera 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 BlockPor cierto, Elastic, además de Winlogbeat, también tiene , que puede monitorear archivos y procesos en el sistema. También hay una aplicación SIEM (Gestión de eventos e información de seguridad) en Kibana. Probé ambos, pero no vi muchos beneficios: parece que Auditbeat será más útil para los sistemas Linux y SIEM no me ha mostrado nada inteligible todavía.
Bueno, recomendaciones finales:
- Realice copias de seguridad automáticas periódicas.
- instalar actualizaciones de seguridad de manera oportuna
Bonificación: lista de 50 usuarios que fueron utilizados con más frecuencia para intentos de inicio de sesión RDP
"nombre.de.usuario: Descendente"
Contar
dfthd7c (nombre de host)
842941
winsrv1 (nombre de host)
266525
ADMINISTRADOR
180678
administrador
163842
Administrador
53541
michael
23101
servidor
21983
Steve
21936
John
21927
paul
21913
recepción
21909
micro
21899
de familia
21888
escáner
21887
escanear
21867
David
21865
Chris
21860
propietario
21855
gerente
21852
administrateur
21841
Brian
21839
@
21837
marca
21824
como por las investigadoras e investigadores y organizaciones de la región.
21806
ADMIN.
12748
RAÍZ
7772
ADMINISTRADOR
7325
SOPORTE
5577
SOPORTE
5418
USUARIO
4558
Admin
2832
PROBAR
1928
MySql
1664
Administración
1652
HUÉSPED
1322
USER1
1179
ESCANEAR
1121
ESCANEAR
1032
ADMINISTRADOR
842
ADMINISTRADOR1
525
BACKUP
518
Administrador de MySQL
518
RECEPCIÓN
490
USER2
466
TEMP
452
SQLADMIN
450
USER3
441
1
422
GENERAL
418
PROPIETARIO
410
Fuente: habr.com