News
Guía de Seguridad Device-Mode MikroTik
Aprende cómo el device-mode de RouterOS restringe herramientas de riesgo, por qué existe y cómo planificar el provisioning y adopción de MKController.
Resumen El device-mode es la puerta persistente de capacidades de RouterOS para subsistemas de alto riesgo — fetch, scheduler, proxy SOCKS, bandwidth-test, contenedores y más. Vive por debajo de los permisos de usuario, por lo que incluso un administrador completo no puede habilitar ciertas herramientas sin confirmación física por botón o ciclo de energía. Esta guía explica cómo funciona, por qué MikroTik lo introdujo tras la era de la botnet Mēris, cómo ha evolucionado de RouterOS v7.4 a v7.22, y cómo planificar el provisioning para que la adopción de MKController sea fluida.
¿Qué es el device-mode de RouterOS?
El device-mode es un estado de seguridad persistente de RouterOS que decide qué puede hacer el propio sistema operativo, independientemente del usuario conectado. Vive por debajo de los permisos de usuario: incluso una sesión de admin completo no puede habilitar ciertas herramientas de alto riesgo a menos que la política de device-mode lo permita, y la frontera de seguridad pasa a ser “tu contraseña más prueba física de que alguien puede tocar el equipo.”
El device-mode es distinto del Safe Mode. El Safe Mode te protege de bloqueos de configuración durante cambios interactivos (revierte si la sesión se desconecta). El device-mode es una política de capacidades de larga duración que sobrevive a reinicios y actualizaciones — una vez que una función queda restringida, cada reinicio la mantiene restringida hasta que una confirmación física explícita revierte la decisión.
Por qué MikroTik introdujo el device-mode
Los atacantes aprendieron a convertir routers de borde en armas a escala de internet. La botnet Mēris fue el punto de inflexión — dispositivos MikroTik comprometidos se usaron como relés y generadores de tráfico abusando de funciones legítimas para ingenieros de red pero devastadoras al ser secuestradas: proxy SOCKS para tunelar tráfico de ataque, bandwidth-test para amplificación, scheduler + fetch para persistencia y entrega de payload.
El device-mode aplica el principio de mínimo privilegio a nivel de plataforma para que una credencial robada por sí sola no pueda accionar los interruptores más arriesgados. La frontera de seguridad se convierte en “tu contraseña más prueba física de que alguien puede tocar el equipo.”
El handshake de confirmación física
Si intentas transicionar una función restringida de no a yes, RouterOS acepta la solicitud pero la mantiene pendiente. Debes confirmar localmente con una pulsación de botón o un cold reboot dentro del timeout configurado, o RouterOS descarta el cambio. Para sitios remotos, planifica cómo ocurrirá el ciclo de energía necesario — PDU inteligente, inyector PoE gestionado o manos en sitio. El device-mode no reemplaza el firewall ni los permisos de usuario — se sitúa por debajo de ellos como última línea de defensa.
Modos, flags y qué se bloquea
El device-mode se configura bajo /system/device-mode. Internamente es un conjunto de flags booleanos que controlan subsistemas específicos. Los flags que aparecen en operaciones reales:
fetch— bloquea/tool/fetchy cualquier automatización que dependa de él.scheduler— bloquea/system/schedulery scripts programados.socks— bloquea habilitar el proxy SOCKS.bandwidth-testytraffic-gen— bloquean BTest y generación de tráfico.container— bloquea contenedores RouterOS a menos que se habiliten explícitamente.partitionsyrouterboard— bloquean cambios de almacenamiento de bajo nivel y configuración de boot.install-any-version/allowed-versions— restringen rutas de downgrade que reintroducen vulnerabilidades antiguas.
Las versiones más nuevas de RouterOS introdujeron modos predefinidos que agrupan flags por nivel de hardware:
| Modo | Nivel de hardware | Postura | Restricciones predeterminadas clave |
|---|---|---|---|
| advanced | CCR, 1100, gama alta | Permisivo | container, traffic-gen, install-any-version |
| home | hAP, cAP, SOHO | Estricto | scheduler, fetch, socks, bandwidth-test, sniffer |
| basic | RB estándar, switches | Equilibrado | socks, bandwidth-test, proxy, zerotier |
| rose | RDS, wireless exterior | Uso especial | Igual que advanced pero con container=yes |
Un dispositivo nuevo puede llegar con una postura restrictiva que rompa tu automatización estándar hasta que lo planifiques.
Evolución de versiones
El device-mode ha evolucionado de un control especializado de contenedores a un marco integral. Apareció por primera vez en v7.4beta vinculado al soporte de contenedores — la primera función que requería /system/device-mode/update container=yes y una pulsación de botón. La v7.13 (y el backport a v6.49.8) introdujo allowed-versions para bloquear ataques de rollback contra CVEs antiguas. La v7.17 (principios de 2025) trajo modos predefinidos por nivel de hardware con asignación automática de modo durante el upgrade. Las v7.19–v7.22 abordaron el “deadlock de automatización” — la v7.22rc3 (febrero de 2026) añadió la capacidad de configurar device-mode vía Netinstall y FlashFig usando un “mode script,” permitiendo a los ISPs definir el estado de seguridad durante el flasheo inicial en lugar de pulsar botones en miles de unidades.
Estado flagged y dolor de provisioning
RouterOS puede marcar un dispositivo como flagged cuando detecta patrones sospechosos (manipulación de archivos, comportamiento tipo persistencia) y aplica un estado seguro más estricto. Un contador de intentos también bloquea futuras actualizaciones de device-mode tras repetidos intentos de cambio fallidos sin confirmación física. Cuando los contadores parecen inesperados, investiga primero — no habilites más funciones para “hacer que funcione.”
El patrón de deadlock de provisioning: el router arranca en modo restrictivo, el script de primer arranque necesita /tool/fetch para descargar config, fetch está bloqueado, el bootstrap falla, el dispositivo nunca alcanza el estado donde la corrección remota es posible. Los workflows de provisioning más nuevos lo arreglan mediante mode scripts de Netinstall/FlashFig. Ten en cuenta que /system/reset-configuration NO resetea device-mode en muchos modelos — las suposiciones de “reset igual a fábrica” pueden sorprenderte.
Cómo habilitar de forma segura una función necesaria
Cuando legítimamente necesitas una capacidad restringida, usa un procedimiento predecible:
-
Verifica el estado actual:
/system/device-mode/print -
Solicita el cambio con un timeout:
/system/device-mode/update fetch=yes activation-timeout=10m -
Realiza la confirmación física — pulsa el botón Mode/Reset (según el modelo) o ejecuta un cold reboot.
-
Verifica:
/system/device-mode/print
Si el timeout expira antes de la confirmación, RouterOS descarta el cambio pendiente y mantiene la política anterior.
Matriz de habilitación basada en riesgo
| Capacidad | Necesidad legítima típica | Riesgo principal | Enfoque más seguro |
|---|---|---|---|
fetch | Traer configs, renovar certificados | Entrega remota de payload | Permitir solo endpoints HTTPS conocidos; restringir egress |
scheduler | Backups, tareas de mantenimiento | Persistencia | Mantener scripts mínimos; monitorizar trabajos inesperados |
socks | Tunelado interno | Relé de botnet | Vincular solo a VLAN de gestión; restringir por firewall |
traffic-gen / bandwidth-test | Pruebas de enlace | DoS / amplificación | Habilitar solo en ventanas de mantenimiento |
container | Ejecutar servicios en el router | Persistencia de larga duración | Preferir servidores dedicados; endurecer storage y firewall |
Impacto en la adopción de MKController
MKController depende de acceso de gestión predecible; el device-mode puede ser el freno de mano invisible durante el onboarding. Si bloquea una acción requerida, el flujo de adopción se estanca — el síntoma suele parecer “el dispositivo es alcanzable, pero las tareas fallan.” La guía de troubleshooting de MKController destaca específicamente Device-Mode disabled. Planifícalo: incluye una política de device-mode en tu checklist de staging, decide qué flags se permiten antes del envío y documenta cómo ocurrirá la confirmación física en cada sitio. Para contexto de seguridad relacionado, consulta nuestras guías de mejores prácticas de seguridad Winbox y gestión remota con WireGuard.
Checklist post-upgrade
Tras cada upgrade de RouterOS o al recibir hardware nuevo: confirma que el modo actual coincide con la política; valida las herramientas de las que dependes (fetch, scheduler); revisa allowed-versions en entornos regulados; inspecciona attempt-count y estado flagged en busca de anomalías; documenta qué sitios requieren confirmación física y cómo.
Da el siguiente paso
El device-mode es infraestructura de seguridad esencial pero añade carga operativa a escala, donde la confirmación física en sitios remotos no se puede improvisar. MKController centraliza inventario, gobernanza de acceso y visibilidad para que solo toques device-mode cuando esté justificado, y el paso físico sea planificado en vez de reactivo.