comment
IRC Chat
play_arrow
Este sitio utiliza cookies propias y de terceros. Si continúa navegando consideramos que acepta el uso de cookies. OK Más Información.

Mikrotik - Prevenir ataques de fuerza bruta a RDP.

  • 0 Respuestas
  • 857 Vistas

0 Usuarios y 3 Visitantes están viendo este tema.

Desconectado xyz

  • *
  • Moderador Global
  • Mensajes: 448
  • Actividad:
    21.67%
  • Reputación 10
    • Ver Perfil
    • Under0cde
« en: Mayo 23, 2018, 04:59:07 pm »
Prevenir en mikrotik ataques de fuerza bruta a un rdp



Es normal, visualizar ataques de fuerza bruta a diferentes protocolos, ssh, ftp, telnet (en alguno casos), mysql, rdp.

El objetivo es entender como se puede prevenir en mikrotik, con pocas reglas.



Antes de comenzar, cabe destacar que en el presente ejemplo, se limitan los intentos por conexiones y a su vez, intentos de login (fuerza bruta).

Analizando tutoriales en internet, viendo diferentes configuraciones, decidí realizar un entorno real de pruebas de fuerza bruta, a ver como previene Mikrotik (cabe destacar que estos scripts) estan pulidos a una necesidad puntual, cada uno, deberá adaptarlos al escenario propuesto.



Agregando reglas en el firewall

Dejo el script de las reglas, para luego ir explicando las diferentes etapas que transcurren.
Todo el script va en: ip -> firewall -> filter

Código: No tienes permisos para ver links. Registrate o Entra con tu cuenta
add action=reject chain=forward log=yes log-prefix=RDP-BF- protocol=tcp reject-with=icmp-network-unreachable src-
address-list=Rdp_Stage_Final

add action=add-src-to-address-list address-list=Rdp_Stage_Final address-list-timeout=1d chain=forward

comment="Stage 3" connection-state=new dst-port=3389 log=yes log-prefix="RDP BRUTEFORCE" protocol=tcp src-address-list=rdp_stage3

add action=add-src-to-address-list address-list=rdp_stage3 address-list-timeout=1m30s chain=forward comment="Stage 2" connection-state=new dst-port=3389 protocol=tcp src-address-list=rdp_stage2

add action=add-src-to-address-list address-list=rdp_stage2 address-list-timeout=30s chain=forward comment="Stage 1" connection-state=new dst-port=3389 protocol=tcp src-address-list=rdp_stage1

add action=add-src-to-address-list address-list=rdp_stage1 address-list-timeout=10s chain=forward comment="Stage 0" connection-state=new dst-port=3389 protocol=tcp

add action=accept chain=forward comment="Forward - RDP" connection-nat-state=dstnat connection-state=new dst-
port=3389 in-interface=TELCO log=yes log-prefix="FWD - RDP ->" nth=2,1 protocol=tcp

Aquí es donde hay que detenerse a comprender el óden de las reglas, y porque no en órden inverso..

Escenario 1.
 Si las reglas van en órden inverso, cuando hay un intento de brute force, pasará del stage1 al stage2/stage3/stage_final con una sola conexion. Ya que ademas, sobre escribirá las listas. Por consecuente, el primer intento de login (sea acertado o no) ingresará a la black_list con el timeout de 24 horas... Algo que debe tenerse en cuenta, si hay accesos que deben permitirse.

Escenario 2.
 Al ir en el órden propuesto, cuando se realiza una conexión al rdp sucederá en el siguiente órden:
  • Ingresará al stage 1 durante 10 segundos (al ser exitoso, pasado los 10 segundos, la Ip saldrá de la lista)
  • Al intentar otro nombre de usuario y contraseña (se genera una nueva conexion - paquete- entonces pasará al
    stage2 - el cual tiene 30 segundos - tiempo útil en un enlace rdp)
  • Al realizar otro acceso con diferentes credenciales, pasará del stage2 al stage3; y como el tiempo es límite,
    automáticamente pasara al stage_final
  • Cuando quieran acceder con otras credenciales, la sesión finalizará con un mensaje que la red esta inaccesible

Con el objetivo completado, la Ip ingresa a una black_list por 24 horas (cabe aclarar, que es posible conjugar
envíos de emails al ingresar a una black_list).

Escenario ideal.
 El usuario al conectarse al Rdp, ingresa las credenciales proporcionadas (hasta 2 intentos), al mismo tiempo, ingresa en el stage0/1/2, al ser correctos los datos proporcionados, no genera nueva conexión, si no que mantiene la conexion establecida y sale automaticamente del stage0/1/2.



La imagen anterior, muestra las reglas (prestar atención, al órden de la regla de reject/drop) és a modo ejemplo la imagen, lo correcto es que la misma, esté sobre los add_src_to_addres_lists.





Aquí es posible visualizar, como al pasar por las diferentes etapas de brute_force, el script es eficiente (en éste escenario)


El inicio de una lista de Ip's que realizan brute_force al rdp, con el correspondiente time-out.


La imagen anterior, muestra el órden correcto de reglas y estableciendo en cero los contadores, para otra prueba.


Como es posible apreciar, las reglas van teniendo efectividad, ya que las conexiones que se están generando, pasan por los diferentes stages de listas.

En dos días, la lista_negra está generada y cada vez que intenten realizar una conexion desde la misma Ip, obtendrán un mensaje que no es posible alcanzar o establecer una conexion con el host.



Las buenas politicas de longitud y complejidad de contraseñas, es útil para reforzar y prevenir accesos no legítimos.

Un saludo .!
« Última modificación: Mayo 23, 2018, 05:02:31 pm por xyz »

 

¿Te gustó el post? COMPARTILO!



Mikrotik - Tercera Parte [ Breaking Chains para el Administrador]

Iniciado por xyz

Respuestas: 0
Vistas: 1537
Último mensaje Marzo 26, 2017, 10:56:45 pm
por xyz
Mikrotik - Segunda Parte [ Interfaz y Configuraciones ]

Iniciado por xyz

Respuestas: 0
Vistas: 1225
Último mensaje Marzo 26, 2017, 10:54:44 pm
por xyz
Mikrotik - Quinta Parte [Balanceo de líneas - ISP]

Iniciado por xyz

Respuestas: 2
Vistas: 4125
Último mensaje Diciembre 13, 2017, 12:20:08 pm
por xyz
Mikrotik - Configuración de Netflow con Ntopng (Monitor de Red)

Iniciado por xyz

Respuestas: 0
Vistas: 212
Último mensaje Septiembre 15, 2018, 11:40:36 pm
por xyz
Mikrotik - Cuarta Parte [ UnderTik - QoS ]

Iniciado por xyz

Respuestas: 0
Vistas: 2345
Último mensaje Marzo 28, 2017, 12:08:24 pm
por xyz