Hardening MikroTik: guía para proteger tu RouterOS

Si operas una red de misión crítica sobre MikroTik —un ISP con miles de abonados, un core empresarial o un puñado de routers de borde expuestos a internet— el equipo que sacaste de la caja no viene listo para producción. RouterOS trae por defecto servicios de administración abiertos, descubrimiento de vecinos activo en todas las interfaces y ninguna política de firewall que proteja al propio router. El hardening MikroTik es el proceso de cerrar esa superficie de ataque de forma metódica: decidir quién puede llegar al plano de control, por qué protocolo y desde qué direcciones. No es una casilla que se marca una vez; es una línea base que se documenta y se audita. En esta guía repasamos el hardening de RouterOS con comandos reales de RouterOS v7, en el orden en que conviene aplicarlos.

Por qué el hardening MikroTik no es opcional en producción

La mayoría de los incidentes que vemos en terreno no son exploits sofisticados: son routers con Winbox o la API expuestos a internet, credenciales por defecto y descubrimiento MNDP anunciando el equipo a media red. Un atacante que alcanza el plano de control no necesita romper tu enrutamiento BGP ni tu MPLS; le basta con entrar. Por eso el hardening arranca por lo aburrido y efectivo: usuarios, servicios de administración y la protección del propio router en la cadena input del firewall.

Conviene separar mentalmente dos planos. El tráfico que atraviesa el router (chain forward) es lo que proteges para tus clientes o tus usuarios. El tráfico dirigido al router (chain input) es lo que proteges para ti: acceso a Winbox, SSH, API, DNS, NTP. El hardening se concentra sobre todo en este segundo plano, que por defecto está completamente abierto.

Primer frente: usuarios y servicios de administración

El primer paso es dejar de usar el usuario admin por defecto y aplicar el principio de menor privilegio. RouterOS define grupos con policies granulares (read, write, policy, ssh, winbox, ftp, api, entre otras). Ojo con un detalle real: incluso el grupo read incorpora sensitive y reboot, así que no es un grupo "seguro" para entregar a terceros. Para accesos acotados, crea un grupo propio con solo las policies que necesitas.

El segundo paso es apagar todo servicio de administración que no uses y restringir por dirección de origen los que sí. En un router en producción rara vez necesitas Telnet, FTP o el WebFig (www) sin cifrar. Deshabilítalos y deja Winbox, SSH y —si automatizas— la API solo sobre TLS y solo desde tus redes de gestión:

# Crear un usuario administrativo propio y quitar el admin por defecto
/user add name=neteng group=full password="usa-una-clave-larga-y-unica"
/user remove admin

# Apagar los servicios inseguros o que no ocupas
/ip service disable telnet,ftp,www,api

# Restringir los servicios de gestión a la subred de administracion
/ip service set winbox address=10.10.0.0/24 port=8291
/ip service set ssh address=10.10.0.0/24
/ip service set api-ssl address=10.10.0.0/24

La propiedad address de /ip service es una lista blanca a nivel de servicio: si el origen no calza, el router ni siquiera responde. Es una segunda capa que se suma al firewall, no un reemplazo. Cambiar el puerto de Winbox del 8291 por defecto no es seguridad real, pero sí reduce el ruido de escaneo automatizado en los logs.

Cerrar el descubrimiento: MNDP, MAC-server y bandwidth-test

RouterOS anuncia el equipo por su protocolo de descubrimiento de vecinos (MNDP/LLDP) en todas las interfaces por defecto, lo que revela versión, identidad y direcciones a cualquiera en el segmento. También deja el acceso por MAC (MAC-Winbox y MAC-Telnet) abierto en todas las interfaces —útil en el LAB, peligroso de cara a clientes o a internet— y el servidor de bandwidth-test activo. Todo eso se acota a las interfaces de gestión o se apaga:

# Anunciar y descubrir vecinos solo hacia la red de gestion
/interface list add name=mgmt
/interface list member add list=mgmt interface=ether1
/ip neighbor discovery-settings set discover-interface-list=mgmt

# Acceso por MAC solo desde la red de gestion
/tool mac-server set allowed-interface-list=mgmt
/tool mac-server mac-winbox set allowed-interface-list=mgmt
/tool mac-server ping set enabled=no

# Apagar el servidor de bandwidth-test
/tool bandwidth-server set enabled=no

Estos servicios son de los más olvidados en una auditoría y de los que más información entregan sin autenticación. Restringirlos a la interface list de gestión mantiene el equipo operable para tu NOC sin exponerlo al resto de la red.

El corazón del hardening: la cadena input del firewall

Aquí está la pieza central. Por defecto la cadena input acepta todo, así que cualquiera con ruta al router puede tocar sus servicios. La estrategia correcta es default-drop: aceptar explícitamente lo legítimo y descartar el resto al final. El orden de las reglas importa, porque RouterOS las evalúa de arriba hacia abajo.

Un patrón robusto y probado para input: aceptar primero las conexiones ya establecidas y relacionadas (barato en CPU), descartar de inmediato las invalid, permitir ICMP para diagnóstico, permitir el acceso de administración solo desde una address-list de confianza, y cerrar con un drop de todo lo que llega desde la interfaz WAN.

# Address-list con las redes desde las que administras el router
/ip firewall address-list add list=mgmt-admins address=10.10.0.0/24

/ip firewall filter
add chain=input connection-state=established,related action=accept \
    comment="Aceptar trafico ya establecido"
add chain=input connection-state=invalid action=drop \
    comment="Descartar paquetes invalid"
add chain=input protocol=icmp action=accept comment="Permitir ICMP"
add chain=input src-address-list=mgmt-admins action=accept \
    comment="Acceso de administracion confiable"
add chain=input in-interface=ether1-wan action=drop \
    comment="Bloquear todo lo demas desde la WAN"

La documentación de RouterOS es explícita en un punto que mucha gente omite: debes descartar todos los paquetes con connection-state=invalid tanto en input como en forward. Un paquete invalid no tiene estado determinado en connection tracking, no participa en NAT y conserva su IP de origen original al enrutarse; dejarlo pasar es una fuente clásica de comportamiento errático y de fugas. Para el tráfico que atraviesa el router, el mismo principio se complementa con fasttrack-connection sobre las conexiones establecidas para descargar la CPU. Si quieres profundizar en el diseño completo de reglas —zonas, port-knocking, protección contra escaneos— revisa nuestro trabajo de firewall en RouterOS.

Acceso remoto seguro y respaldo de la configuración

Si necesitas administrar el router desde fuera de la red de gestión, la respuesta no es abrir Winbox a internet: es levantar un túnel y administrar por dentro de él. RouterOS v7 soporta WireGuard e IPsec de forma nativa, y con WireGuard la propiedad allowed-address del peer actúa como filtro de qué orígenes pueden hablar por el túnel. La regla práctica es simple: la administración del router siempre entra por la VPN, y la address-list de confianza incluye el rango del túnel, no direcciones públicas. Diseñar bien esa capa de VPN site-to-site y acceso remoto es parte inseparable del hardening.

Cierra la línea base con lo operativo: mantén RouterOS en una versión con soporte de largo plazo (long-term), pensada para producción y no en un release de la rama testing; habilita respaldos automáticos (/export además de /system backup, porque el export es legible y versionable) y registra los eventos de input hacia un syslog externo para tener trazabilidad. Un router endurecido pero sin respaldo ni logging sigue siendo frágil ante un incidente.

Checklist de hardening MikroTik

Área	Acción	Menú RouterOS
Usuarios	Quitar admin, grupo con menor privilegio	/user, /user group
Servicios	Apagar telnet/ftp/www/api; restringir por address	/ip service
Descubrimiento	MNDP y MAC-server solo en interfaces de gestión	/ip neighbor, /tool mac-server
Firewall input	Default-drop, drop invalid, address-list de confianza	/ip firewall filter
Acceso remoto	Administrar solo por VPN (WireGuard/IPsec)	/interface wireguard
Operación	Versión LTS, backups automáticos, logging externo	/system, /system logging

Ninguno de estos pasos es exótico, y esa es justamente la trampa: el hardening MikroTik funciona por acumulación de medidas simples aplicadas de forma consistente en cada equipo del parque, no por un truco aislado. Un CCR de core, un router de borde PPPoE y un CPE de cliente comparten la misma línea base, adaptada a su rol. Documentar esa base y auditarla periódicamente es lo que separa una red que resiste de una que solo no ha sido atacada todavía.

En MikroTik Chile diseñamos y aplicamos líneas base de hardening reproducibles para parques completos de RouterOS —firewall, gestión de acceso, VPN y monitoreo— y las dejamos documentadas para que tu equipo las mantenga. Si necesitas endurecer tu red o auditar la configuración actual de tus routers, conversemos con nuestro equipo de soporte.