Y por último hablaremos de la protección avanzada de MikroTik, que se basa en una pregunta importante: quién puede comunicarse con el propio enrutador y por qué protocolos. Ahí está la principal diferencia de RouterOS frente a muchos dispositivos domésticos. Aquí no basta con activar un par de opciones básicas; se puede recortar todo lo innecesario con bastante precisión. Claro que hay otra cara: una regla mal formulada y el enrutador deja de responder incluso a usted. Por eso lo que sigue no trata del primer arranque ni de cosas básicas como la contraseña inicial, sino de una configuración más profunda.
MikroTik tiene otra característica que conviene mencionar desde el principio. En WinBox y WebFig los nombres de secciones y parámetros suelen usarse tal como los proporciona el fabricante, sin una interfaz oficial completamente traducida al español. Por eso en el artículo los elementos de menú y las propiedades de RouterOS aparecen tal como los llama el propio fabricante. De lo contrario no sería ayuda, sino una reescritura con traducciones caseras que luego sería imposible encontrar en la ventana real de configuración.
Cómo cerrar la superficie de administración y no exponer el enrutador más de lo necesario
La medida avanzada más útil en RouterOS no está relacionada con Wi‑Fi ni con la velocidad, sino con la cadena input. Es justamente la que controla el tráfico dirigido al propio enrutador. Para un escenario doméstico o de pequeña oficina la lógica es simple: desde la lista WAN hacia el dispositivo no debería llegar casi nada, salvo excepciones estrictamente permitidas. MikroTik, en sus ejemplos para apertura por secuencia de puertos y en los materiales sobre protección parte del esquema donde las conexiones entrantes desde el exterior se descartan por defecto y el acceso necesario se abre puntualmente. Si no se hace así, el enrutador se convierte en un objetivo para escaneos automáticos e intentos de intrusión, y esos encuentros normalmente no terminan bien.
El siguiente nivel que a menudo se subestima en MikroTik es el acceso por MAC. RouterOS soporta MAC Telnet, MAC WinBox y MAC Ping. ¿Es cómodo? Sí, especialmente cuando la IP aún no se ha configurado. Pero una vez en producción no conviene mantener ese acceso por todas partes. En la documentación oficial, MikroTik muestra los parámetros allowed-interface-list para /tool mac-server y /tool mac-server mac-winbox. El sentido práctico es muy simple: o bien restringir el acceso MAC sólo a interfaces de confianza, por ejemplo un bridge interno, o bien poner none. Para uso doméstico es una de las medidas de protección más infravaloradas.
Por la misma razón conviene ordenar el Neighbor Discovery. Por defecto esta función es muy útil para detectar dispositivos en un mismo dominio de broadcast, pero junto con la comodidad muestra a los vecinos el modelo, direcciones y otros datos. MikroTik recomienda desactivar la detección en todas las interfaces mediante discover-interface-list=none si esa visibilidad no es necesaria. Una opción más suave, práctica en la vida real, es dejar la detección sólo en una lista interna de interfaces LAN y no publicar el dispositivo hacia el exterior. Para una red de apartamento, una oficina y especialmente para espacios públicos, es una configuración sensata, no paranoia.
Conviene revisar también todos los servicios que RouterOS escucha por sí mismo. En la documentación de MikroTik sobre protección se enumeran servicios que en un entorno de producción es mejor mantener desactivados salvo necesidad: Bandwidth Server, Proxy, Socks, UPnP y también IP Cloud si no se precisa el DDNS integrado ni la actualización de hora. La lógica no tiene sorpresas: cuantas menos funciones adicionales haya en el enrutador, menos puntos vulnerables habrá. Esto es especialmente importante en equipos donde RouterOS se usa no sólo como enrutador, sino también como banco de pruebas.
Si hace falta acceso remoto al propio MikroTik, la vía más prudente no es simplemente abrir WinBox o WebFig en una dirección pública. Es mucho más seguro permitir la administración sólo desde direcciones de confianza y, mejor aún, hacerlo sobre una VPN. En RouterOS v7 ya existe WireGuard. Y si se quiere un esquema muy cuidadoso, MikroTik describe oficialmente también el port knocking, donde el acceso se abre sólo tras la secuencia correcta de accesos a puertos y la adición de la dirección en address-list. Para una red doméstica la medida no es obligatoria, pero para administración remota es razonable.
| Configuración | Dónde buscar | Qué aporta |
|---|---|---|
| Cadena input e Interface Lists | IP → Firewall → Filter Rules, Interfaces → Interface List | Separa el acceso al enrutador del tráfico de tránsito habitual |
| MAC WinBox / MAC Telnet | Tools → MAC Server | Restringe u desactiva el acceso al enrutador por dirección MAC |
| Neighbor Discovery | IP → Neighbors | Elimina visibilidad innecesaria del enrutador en el segmento local |
| IP Cloud | IP → Cloud | Desactiva el DDNS integrado si no se necesita un nombre remoto |
| Bandwidth Server | Tools → Bandwidth Server | Elimina el servicio de prueba de capacidad de la red del entorno productivo |
Qué parámetros avanzados suelen ofrecer protección real
Un aspecto muy útil en RouterOS está relacionado con SSH. En MikroTik el servidor SSH viene habilitado por defecto y en las propiedades existe el parámetro strong-crypto. En la documentación oficial el fabricante recomienda habilitar configuraciones SSH más estrictas con /ip ssh set strong-crypto=yes. Esto está relacionado con la protección contra fuerza bruta y los riesgos de ataques automáticos contra autenticaciones débiles. Para un enrutador que se gestiona por consola, es una de las mejoras más sensatas, sobre todo si el acceso viene no sólo desde la red local. Además, SSH tiene el parámetro password-authentication, y si el acceso ya se ha migrado a claves, es mejor no mantener la autenticación por contraseña sin motivo.
El siguiente aspecto, que sorprendentemente se subestima, es DNS. En RouterOS el parámetro allow-remote-requests determina si el enrutador responderá a consultas DNS de clientes remotos. MikroTik advierte por separado: si este modo está activado, el acceso a los puertos TCP y UDP 53 debe limitarse sólo a nodos conocidos. En la práctica la idea es sencilla. DNS requiere protección, y si el enrutador no debe funcionar como caché DNS para clientes, esa función es mejor no activarla. Y si debe hacerlo, el acceso hay que recortarlo con reglas del cortafuegos y no convertir el equipo en un servicio DNS público para cualquiera.
Para protegerse contra intentos de fuerza bruta MikroTik ofrece una solución práctica basada en address-list. En el ejemplo oficial de prevención de fuerza bruta se muestra un esquema para proteger SSH acumulando direcciones por etapas y luego colocando la fuente en una lista negra. No es un botón mágico ni reemplaza una limitación de acceso adecuada, pero como capa adicional funciona bien. Especialmente en escenarios donde SSH debe estar accesible desde el exterior para un conjunto restringido de direcciones.
Otro punto que incluso usuarios experimentados suelen pasar por alto son los permisos de las cuentas. En MikroTik el grupo estándar read no es tan inofensivo como sugiere el nombre. En la documentación de RouterOS se indica que incluso ese grupo incluye las políticas sensitive, reboot y otras importantes, por lo que no conviene asignarlo a usuarios no confiables. Si alguien necesita acceso limitado para ver parámetros concretos, es más seguro crear un grupo propio con el conjunto exacto de permisos en lugar de fiarse del nombre read.
Y por último existe la tentación muy microtikiana de activar todo de una vez: RoMON, API, REST API, sniffer, contenedores, proxy, servicios de red adicionales. RouterOS lo permite, y por eso en MikroTik es especialmente importante seguir una regla simple. Cada mecanismo activo debe responder a la pregunta de por qué está ahí. Si en la red no hay un sistema de gestión externo, no hace falta REST API. Si nadie monitoriza el enrutador por SNMP, no tiene sentido mantener servicios adicionales sólo porque “algún día” podrían servir. En MikroTik la seguridad suele ser menos magia compleja y más la aburrida pero útil habilidad de decir a tiempo que una función no tiene cabida aquí.
- Deje la administración del enrutador sólo por interfaces y direcciones de confianza.
- Restrinja u desactive MAC WinBox y MAC Telnet después de poner el equipo en producción.
- No mantenga Neighbor Discovery activado en la cara externa.
- Active strong-crypto para SSH y elimine el acceso por contraseña si ya usa claves.
- No active allow-remote-requests en DNS sin una necesidad clara y reglas de filtrado.
- Cuidado con el grupo read. Para acceso limitado es mejor crear un grupo de permisos propio.
- Port knocking es útil donde se necesita acceso remoto esporádico, no un WinBox abierto permanentemente.
- Address-list sirve no sólo para bloqueos, sino también para listas blancas ordenadas.
- IP Cloud, Proxy, Socks, UPnP y Bandwidth Server no deberían permanecer activos sin una finalidad.
FAQ
¿Tiene RouterOS una interfaz oficial completamente traducida al español?
En el uso diario WinBox y WebFig emplean los nombres originales en inglés de secciones y parámetros, por lo que es más seguro guiarse por esos nombres.
¿Es necesario desactivar Neighbor Discovery?
En las interfaces externas sí; es una buena práctica. En la cara interna se puede dejar sólo para una lista de interfaces de confianza si la función realmente es necesaria.
¿Debería mantener MAC WinBox activado permanentemente?
Normalmente no. Tras poner el enrutador en servicio conviene limitarlo al segmento interno o desactivarlo por completo.
¿Cuándo es necesario allow-remote-requests en DNS?
Sólo si el enrutador debe atender consultas DNS de clientes. En cualquier otro caso es mejor dejar el parámetro desactivado.
¿Cuál es el mecanismo de protección avanzado más práctico en MikroTik?
En la práctica funcionan mejor no los trucos exóticos, sino la combinación de una cadena input estricta, restricciones por Interface Lists, un SSH bien configurado, listas de direcciones y la desactivación de servicios innecesarios.
