Atualizar e Corrigir RouterOS MikroTik

Resumo Atualizar o RouterOS MikroTik em uma frota de ISP é um processo controlado, não uma ação de um clique. Escolha um canal de versão que combine com seus SLAs, faça backup de cada dispositivo, valide em um piloto e então implante em ondas conscientes da topologia, com um caminho de rollback claro. Em 2026 isso importa mais do que nunca: uma falha explorável publicamente no RouterOS (CVE-2026-7668) e uma nova versão stable (7.23.1) significam que roteadores de borda sem correção são um risco ativo.

O Que É a Correção do RouterOS para uma Frota de ISP?

A correção do RouterOS é o processo disciplinado de mover uma população de dispositivos MikroTik de uma versão do RouterOS para outra mais recente, a fim de corrigir falhas de segurança, bugs de estabilidade e regressões de comportamento — sem quebrar os serviços que rodam sobre eles. Em um único roteador doméstico, isso é uma tarefa de dois minutos. Em centenas ou milhares de CPEs e roteadores de borda, torna-se um programa operacional: você precisa de uma política de canal de versão, um padrão de backup, uma etapa de staging, uma implantação em fases e um plano de rollback. O objetivo é simples de enunciar e difícil de executar em escala — cada dispositivo termina corrigido e nenhum deles fica fora do ar no processo.

Isso merece um fluxo de trabalho de verdade porque uma atualização toca exatamente aquilo que você não consegue alcançar de novo com facilidade se ela falhar: um roteador na borda do cliente, muitas vezes atrás de CGNAT. Um envio ruim que perca o acesso de gerenciamento vira uma visita técnica. Por isso o fluxo abaixo prioriza segurança e alcançabilidade primeiro, e velocidade depois.

Por Que Corrigir Agora: O Cenário de Segurança de 2026

A cadência de correção fica como uma tarefa silenciosa de fundo até que uma vulnerabilidade force a questão, e 2026 dá motivos concretos para apertá-la. A CVE-2026-7668 é uma leitura fora dos limites no endpoint SCEP do RouterOS, com pontuação CVSS 7.3 (Alta); pode ser disparada remotamente e existe um exploit público. Avisos separados neste ciclo cobrem um problema de controle de acesso impróprio na validação de IP de origem do VXLAN (corrigido no RouterOS 7.20 e posteriores) e uma falha de corrupção de memória no serviço SMB que um atacante não autenticado pode acionar com pacotes manipulados.

A orientação da MikroTik é consistente: mantenha o RouterOS atualizado e atrás de um firewall que bloqueie redes não confiáveis. O ramo stable atual, RouterOS 7.23.1 (lançado em 2 de junho de 2026), também corrige um vazamento de memória do BGP e um problema de estabilidade no DHCPv4-snooping. Esta é a razão comum pela qual frotas precisam de um processo de correção repetível em vez de atualizações improvisadas.

Passo 1 — Escolha o Canal de Versão Certo

O RouterOS oferece mais de um ramo, e a escolha é uma decisão de política, não de preferência. Versões stable saem a cada poucos meses, com recursos e correções testados; versões long-term recebem apenas correções críticas e de segurança, mudando muito menos entre versões. Para frotas de borda e CPE de ISP que valorizam a previsibilidade, o ramo long-term costuma ser o padrão certo, com o stable reservado para hardware ou recursos que o exijam. Independentemente do que você escolher, nunca rode builds testing ou development em produção. Documente o ramo por classe de dispositivo para que a decisão seja repetível em toda a equipe.

Passo 2 — Faça Backup e Exportação Primeiro

Nunca atualize sem um ponto de recuperação. Crie tanto um backup binário (/system backup save) quanto uma exportação de configuração legível por humanos (/export file=), porque a exportação sobrevive a mudanças de versão e permite reconstruir mesmo que um backup binário não restaure em outro build. Retire ambos do dispositivo para o seu sistema de gerenciamento. Confirme que há armazenamento livre suficiente para os novos pacotes antes de começar, e prefira uma conexão cabeada ou de console — atualizar por Wi-Fi ou por um link instável é como roteadores ficam bricados no meio da gravação. Para dispositivos em que o acesso de recuperação é a real preocupação, nosso guia de recuperação com Netinstall é a alternativa quando uma atualização dá errado.

Passo 3 — Teste em um Dispositivo Piloto

Atualize primeiro um roteador representativo e observe-o. Escolha um dispositivo que espelhe uma classe de produção — mesmo modelo, mesmo papel, configuração semelhante — e aplique a versão de destino durante uma janela de manutenção. Depois que ele reiniciar, verifique a versão, confirme que os pacotes estão habilitados e revise o changelog em busca de mudanças de comportamento que afetem sua configuração (semântica de firewall, serviços padrão, nomenclatura de interfaces). Só depois que o piloto estiver limpo você autoriza a implantação mais ampla. Esse único passo previne o modo de falha mais caro: descobrir uma regressão depois que ela já foi enviada a mil clientes.

Passo 4 — Implante em Ondas Conscientes da Topologia

A implantação em massa é sobre ordenação e ritmo, não sobre apertar um botão em todos os lugares ao mesmo tempo. Agrupe os dispositivos por topologia para que roteadores encadeados sejam atualizados em sequência — você não quer um roteador a montante reiniciando antes que um dispositivo a jusante tenha buscado seus pacotes. Defina ondas com suas próprias janelas de manutenção e acompanhe cada dispositivo em uma lista de reconciliação, para que qualquer unidade com problema seja recolocada na fila, e não esquecida. Para reduzir a banda de internet, aponte os dispositivos para um roteador central atuando como espelho local de pacotes; isso também controla qual versão a frota pode buscar.

Uma implantação em fases só funciona se você de fato conseguir alcançar cada dispositivo para confirmar que ele voltou. Esse é o problema operacional com CPE atrás de CGNAT — e onde o gerenciamento centralizado prova seu valor.

Passo 5 — Verifique e Reverta se Necessário

Após cada onda, confirme o resultado: verifique a versão reportada, confirme que o firmware da routerboard também foi atualizado onde aplicável (/system routerboard upgrade) e valide que os serviços que importam estão passando tráfego. Se um dispositivo apresentar problemas, restaure o backup binário anterior, ou reconstrua a partir da exportação RSC, ou reinstale a versão anterior com Netinstall como último recurso. Um programa de correção não está “pronto” quando a nova versão está instalada — está pronto quando cada dispositivo é verificado como saudável e cada exceção é acompanhada até o encerramento.

Dicas para Correção em Escala de Frota

• Padronize uma única baseline endurecida para que as atualizações sejam previsíveis. Nossas boas práticas de segurança do Winbox e o guia de operações de segurança de device-mode definem a baseline a que a maioria dos problemas de atualização remonta.
• Restrinja o acesso de gerenciamento a uma VPN ou a IPs confiáveis antes e depois das atualizações, para que uma frota parcialmente corrigida nunca fique exposta.
• Mantenha o plano de gerenciamento alcançável mesmo atrás de CGNAT, para que verificação e rollback não exijam uma visita ao local.
• Revise os avisos de segurança da MikroTik segundo um cronograma, em vez de esperar por um incidente.

FAQ

Com que frequência devo atualizar o RouterOS? Avalie cada versão em relação à sua política de ramo e corrija fora de banda sempre que um aviso afetar serviços que você expõe. Não há intervalo fixo — apenas uma cadência guiada pelo risco.

Stable ou long-term para uma frota de ISP? Long-term é o padrão mais seguro para borda e CPE; use stable onde precisar de suporte a hardware ou recursos mais novos, após validar em staging.

E se uma atualização bricar um dispositivo remoto? Restaure a partir do backup ou da exportação RSC; se o dispositivo estiver inalcançável, recupere com Netinstall. É por isso que um backup testado e um caminho de gerenciamento alcançável são obrigatórios antes de qualquer onda.

Corrija Toda a Sua Frota Sem as Visitas Técnicas

A parte mais difícil da correção de frota não é a atualização — é alcançar e verificar cada dispositivo depois, especialmente CPE atrás de CGNAT. O MKController centraliza a visibilidade de toda a sua frota MikroTik, e o NATCloud oferece alcançabilidade de dentro para fora sem encaminhamento de portas, para que implantações em fases, verificação e rollback aconteçam todas remotamente.

Comece seu teste gratuito do MKController