Tutorial
Guía de Actualización de RouterOS MikroTik
Cómo actualizar y parchear el RouterOS MikroTik en una flota de ISP: canales de versión, despliegue por fases, backups, rollback y los CVE de 2026.
Resumen Actualizar el RouterOS MikroTik en una flota de ISP es un proceso controlado, no una acción de un solo clic. Elige un canal de versión que coincida con tus SLA, haz backup de cada dispositivo, valida en un piloto y luego despliega por oleadas conscientes de la topología, con una ruta de rollback clara. En 2026 esto importa más que nunca: una falla del RouterOS explotable públicamente (CVE-2026-7668) y una nueva versión stable (7.23.1) significan que los routers de borde sin parchear son un riesgo activo.
¿Qué Es el Parcheo de RouterOS para una Flota de ISP?
El parcheo de RouterOS es el proceso disciplinado de mover una población de dispositivos MikroTik de una versión de RouterOS a otra más reciente para corregir fallas de seguridad, errores de estabilidad y regresiones de comportamiento — sin romper los servicios que se ejecutan sobre ellos. En un solo router doméstico esto es una tarea de dos minutos. En cientos o miles de CPE y routers de borde, se convierte en un programa operativo: necesitas una política de canal de versión, un estándar de backup, un paso de staging, un despliegue por fases y un plan de rollback. El objetivo es simple de enunciar y difícil de lograr a escala — cada dispositivo termina parcheado y ninguno se queda sin servicio en el proceso.
Merece un flujo de trabajo de verdad porque una actualización toca lo único que no puedes volver a alcanzar con facilidad si falla: un router en el borde del cliente, a menudo detrás de CGNAT. Un envío malo que pierda el acceso de gestión se convierte en una visita técnica. Por eso el flujo de abajo prioriza la seguridad y la alcanzabilidad primero, y la velocidad después.
Por Qué Parchear Ahora: El Panorama de Seguridad de 2026
La cadencia de parcheo permanece como una tarea silenciosa de fondo hasta que una vulnerabilidad fuerza la cuestión, y 2026 da razones concretas para apretarla. CVE-2026-7668 es una lectura fuera de límites en el endpoint SCEP de RouterOS con puntuación CVSS 7.3 (Alta); puede activarse de forma remota y existe un exploit público. Avisos separados de este ciclo cubren un problema de control de acceso indebido en la validación de IP de origen de VXLAN (corregido en RouterOS 7.20 y posteriores) y una falla de corrupción de memoria en el servicio SMB que un atacante no autenticado puede provocar con paquetes manipulados.
La guía de MikroTik es consistente: mantén RouterOS actualizado y detrás de un firewall que bloquee redes no confiables. La rama stable actual, RouterOS 7.23.1 (lanzada el 2 de junio de 2026), también corrige una fuga de memoria de BGP y un problema de estabilidad de DHCPv4-snooping. Esta es la razón habitual por la que las flotas necesitan un proceso de parcheo repetible en lugar de actualizaciones improvisadas.
Paso 1 — Elige el Canal de Versión Correcto
RouterOS ofrece más de una rama, y la elección es una decisión de política, no una preferencia. Las versiones stable salen cada pocos meses con funciones y correcciones probadas; las versiones long-term reciben solo correcciones críticas y de seguridad, cambiando mucho menos entre versiones. Para flotas de borde y CPE de ISP que valoran la previsibilidad, la rama long-term suele ser el valor por defecto correcto, con stable reservado para hardware o funciones que lo requieran. Sea cual sea tu elección, nunca ejecutes builds testing o development en producción. Documenta la rama por clase de dispositivo para que la decisión sea repetible en todo el equipo.
Paso 2 — Haz Backup y Exportación Primero
Nunca actualices sin un punto de recuperación. Crea tanto un backup binario (/system backup save) como una exportación de configuración legible por humanos (/export file=), porque la exportación sobrevive a los cambios de versión y permite reconstruir incluso si un backup binario no se restaura en otro build. Saca ambos del dispositivo hacia tu sistema de gestión. Confirma que hay suficiente almacenamiento libre para los nuevos paquetes antes de empezar, y prefiere una conexión cableada o de consola — actualizar por Wi-Fi o por un enlace inestable es como los routers terminan bloqueados a mitad de la escritura. Para dispositivos donde el acceso de recuperación es la verdadera preocupación, nuestra guía de recuperación con Netinstall es la alternativa cuando una actualización sale mal.
Paso 3 — Prueba en un Dispositivo Piloto
Actualiza primero un router representativo y obsérvalo. Elige un dispositivo que refleje una clase de producción — mismo modelo, mismo rol, configuración similar — y aplica la versión objetivo durante una ventana de mantenimiento. Después de reiniciar, verifica la versión, confirma que los paquetes están habilitados y revisa el changelog en busca de cambios de comportamiento que afecten tu configuración (semántica del firewall, servicios por defecto, nomenclatura de interfaces). Solo cuando el piloto esté limpio autorizas el despliegue más amplio. Este único paso previene el modo de fallo más caro: descubrir una regresión después de que ya se haya enviado a mil clientes.
Paso 4 — Despliega por Oleadas Conscientes de la Topología
El despliegue masivo trata de orden y ritmo, no de pulsar un botón en todas partes a la vez. Agrupa los dispositivos por topología para que los routers encadenados se actualicen en secuencia — no quieres que un router aguas arriba se reinicie antes de que un dispositivo aguas abajo haya descargado sus paquetes. Define oleadas con sus propias ventanas de mantenimiento y registra cada dispositivo en una lista de reconciliación para que cualquier unidad con problemas se vuelva a encolar, no se olvide. Para reducir el ancho de banda de internet, apunta los dispositivos a un router central que actúe como espejo local de paquetes; esto también controla qué versión puede descargar la flota.
Un despliegue por fases solo funciona si realmente puedes alcanzar cada dispositivo para confirmar que volvió. Ese es el inconveniente operativo con CPE detrás de CGNAT — y donde la gestión centralizada demuestra su valor.
Paso 5 — Verifica y Luego Revierte si Es Necesario
Después de cada oleada, confirma el resultado: comprueba la versión reportada, confirma que el firmware de la routerboard también se actualizó donde corresponda (/system routerboard upgrade) y valida que los servicios que te importan están cursando tráfico. Si un dispositivo falla, restaura el backup binario anterior, o reconstruye desde la exportación RSC, o reinstala la versión anterior con Netinstall como último recurso. Un programa de parcheo no está “terminado” cuando se instala la nueva versión — está terminado cuando cada dispositivo se verifica sano y cada excepción se rastrea hasta su cierre.
Consejos para el Parcheo a Escala de Flota
- Estandariza una única baseline endurecida para que las actualizaciones sean predecibles. Nuestras buenas prácticas de seguridad de Winbox y la guía de operaciones de seguridad de device-mode definen la baseline a la que se remonta la mayoría de los problemas de actualización.
- Restringe el acceso de gestión a una VPN o IPs confiables antes y después de las actualizaciones, para que una flota parcialmente parcheada nunca quede expuesta.
- Mantén el plano de gestión alcanzable incluso detrás de CGNAT, para que la verificación y el rollback no requieran una visita al sitio.
- Revisa los avisos de seguridad de MikroTik según un calendario en lugar de esperar a un incidente.
FAQ
¿Con qué frecuencia debo actualizar RouterOS? Evalúa cada versión frente a tu política de rama y parchea fuera de banda siempre que un aviso afecte a servicios que expones. No hay intervalo fijo — solo una cadencia guiada por el riesgo.
¿Stable o long-term para una flota de ISP? Long-term es el valor por defecto más seguro para borde y CPE; usa stable donde necesites soporte de hardware o funciones más nuevas, tras validar en staging.
¿Y si una actualización bloquea un dispositivo remoto? Restaura desde el backup o la exportación RSC; si el dispositivo es inalcanzable, recupéralo con Netinstall. Por eso un backup probado y una ruta de gestión alcanzable son obligatorios antes de cualquier oleada.
Parchea Toda tu Flota Sin las Visitas Técnicas
La parte más difícil del parcheo de flota no es la actualización — es alcanzar y verificar cada dispositivo después, especialmente CPE detrás de CGNAT. MKController centraliza la visibilidad de toda tu flota MikroTik, y NATCloud te da alcanzabilidad de dentro hacia fuera sin reenvío de puertos, para que los despliegues por fases, la verificación y el rollback ocurran todos de forma remota.