News
Guia de Segurança do Device-Mode MikroTik
Aprenda como o device-mode do RouterOS restringe ferramentas de risco, por que existe e como planejar o provisionamento e adoção do MKController.
Resumo O device-mode é o portão persistente de capacidades do RouterOS para subsistemas de alto risco — fetch, scheduler, proxy SOCKS, bandwidth-test, containers e mais. Ele opera abaixo das permissões de usuário, então mesmo um administrador completo não consegue habilitar certas ferramentas sem confirmação física por botão ou ciclo de energia. Este guia explica como funciona, por que a MikroTik o introduziu após a era da botnet Mēris, como evoluiu da v7.4 à v7.22 do RouterOS, e como planejar o provisionamento para que a adoção do MKController seja tranquila.
O que é o device-mode do RouterOS?
O device-mode é um estado de segurança persistente do RouterOS que decide o que o próprio sistema operacional pode fazer, independentemente de qual usuário esteja logado. Ele opera abaixo das permissões de usuário: mesmo uma sessão de admin completo não consegue habilitar certas ferramentas de alto risco a menos que a política de device-mode permita, e a fronteira de segurança passa a ser “sua senha mais prova física de que alguém pode tocar no equipamento.”
O device-mode é diferente do Safe Mode. O Safe Mode protege você de bloqueios de configuração durante alterações interativas (ele reverte se a sessão desconecta). O device-mode é uma política de capacidades de longa duração que sobrevive a reinícios e atualizações — uma vez que um recurso é bloqueado, todo reboot mantém o bloqueio até que uma confirmação física explícita reverta a decisão.
Por que a MikroTik introduziu o device-mode
Atacantes aprenderam a transformar roteadores de borda em armas em escala de internet. A botnet Mēris foi o ponto de inflexão — dispositivos MikroTik comprometidos foram usados como relés e geradores de tráfego abusando de recursos legítimos para engenheiros de rede mas devastadores quando sequestrados: proxy SOCKS para tunelar tráfego de ataque, bandwidth-test para amplificação, scheduler + fetch para persistência e entrega de payload.
O device-mode aplica o princípio do menor privilégio no nível da plataforma para que uma credencial roubada sozinha não consiga acionar os interruptores mais arriscados. A fronteira de segurança passa a ser “sua senha mais prova física de que alguém pode tocar no equipamento.”
O handshake de confirmação física
Se você tenta transicionar um recurso restrito de no para yes, o RouterOS aceita a solicitação mas a mantém pendente. Você deve confirmar localmente com um pressionar de botão ou um cold reboot dentro do timeout configurado, ou o RouterOS descarta a alteração. Para sites remotos, planeje como o ciclo de energia necessário acontecerá — PDU inteligente, injetor PoE gerenciado, ou mãos no local. O device-mode não substitui o firewall ou permissões de usuário — ele fica abaixo deles como última linha de defesa.
Modos, flags e o que é bloqueado
O device-mode é configurado em /system/device-mode. Internamente é um conjunto de flags booleanas que controlam subsistemas específicos. As flags que aparecem em operações reais:
fetch— bloqueia/tool/fetche qualquer automação dependente dele.scheduler— bloqueia/system/schedulere scripts agendados.socks— bloqueia habilitar o proxy SOCKS.bandwidth-testetraffic-gen— bloqueiam BTest e geração de tráfego.container— bloqueia containers do RouterOS a menos que explicitamente habilitados.partitionserouterboard— bloqueiam mudanças de armazenamento e configuração de boot de baixo nível.install-any-version/allowed-versions— restringem caminhos de downgrade que reintroduzem vulnerabilidades antigas.
Versões mais novas do RouterOS introduziram modos predefinidos que agrupam flags por tier de hardware:
| Modo | Tier de hardware | Postura | Restrições padrão principais |
|---|---|---|---|
| advanced | CCR, 1100, topo de linha | Permissiva | container, traffic-gen, install-any-version |
| home | hAP, cAP, SOHO | Estrita | scheduler, fetch, socks, bandwidth-test, sniffer |
| basic | RB padrão, switches | Equilibrada | socks, bandwidth-test, proxy, zerotier |
| rose | RDS, wireless outdoor | Uso especial | Igual ao advanced mas com container=yes |
Um dispositivo novo pode chegar com uma postura restritiva que quebra sua automação padrão até você planejar para isso.
Evolução de versões
O device-mode expandiu de um controle especializado de container para um framework abrangente. Apareceu pela primeira vez na v7.4beta vinculado ao suporte de containers — o primeiro recurso exigindo /system/device-mode/update container=yes e um pressionar de botão. A v7.13 (e o backport para v6.49.8) introduziu allowed-versions para bloquear ataques de rollback contra CVEs antigas. A v7.17 (início de 2025) trouxe modos predefinidos por tier de hardware com atribuição automática durante upgrade. As v7.19–v7.22 abordaram o “deadlock de automação” — a v7.22rc3 (fevereiro de 2026) adicionou a capacidade de configurar device-mode via Netinstall e FlashFig usando um “mode script,” permitindo que ISPs definam o estado de segurança durante o flashing inicial em vez de pressionar botões em milhares de unidades.
Estado flagged e dor de provisionamento
O RouterOS pode marcar um dispositivo como flagged quando detecta padrões suspeitos (adulteração de arquivos, comportamento tipo persistência) e impõe um estado seguro mais restrito. Um contador de tentativas também trava novas atualizações de device-mode após repetidas tentativas falhadas sem confirmação física. Quando os contadores parecem inesperados, investigue primeiro — não habilite mais recursos para “fazer funcionar.”
O padrão de deadlock de provisionamento: o roteador inicia em modo restritivo, script de primeiro boot precisa de /tool/fetch para baixar config, fetch está bloqueado, bootstrap falha, dispositivo nunca alcança o estado onde correção remota é possível. Workflows de provisionamento mais novos corrigem isso através de mode scripts do Netinstall/FlashFig. Note que /system/reset-configuration NÃO reseta o device-mode em muitos modelos — suposições do tipo “reset igual a fábrica” podem surpreender você.
Como habilitar com segurança um recurso necessário
Quando você legitimamente precisa de uma capacidade controlada, use um procedimento previsível:
-
Verifique o estado atual:
/system/device-mode/print -
Solicite a mudança com um timeout:
/system/device-mode/update fetch=yes activation-timeout=10m -
Realize a confirmação física — pressione o botão Mode/Reset (depende do modelo) ou execute um cold reboot.
-
Verifique:
/system/device-mode/print
Se o timeout expira antes da confirmação, o RouterOS descarta a alteração pendente e mantém a política antiga.
Matriz de habilitação baseada em risco
| Capacidade | Necessidade legítima típica | Risco principal | Abordagem mais segura |
|---|---|---|---|
fetch | Buscar configs, renovar certs | Entrega remota de payload | Permitir só para endpoints HTTPS conhecidos; restringir saída |
scheduler | Backups, jobs de manutenção | Persistência | Manter scripts mínimos; monitorar jobs inesperados |
socks | Tunelamento interno | Relé de botnet | Vincular só à VLAN de gerência; restringir por firewall |
traffic-gen / bandwidth-test | Testes de link | DoS / amplificação | Habilitar só em janelas de manutenção |
container | Rodar serviços no roteador | Persistência de longa duração | Preferir servidores dedicados; endurecer storage e firewall |
Impacto na adoção do MKController
O MKController depende de acesso de gerência previsível; o device-mode pode ser o freio de mão invisível durante o onboarding. Se ele bloqueia uma ação requerida, o fluxo de adoção trava — o sintoma frequentemente parece “o dispositivo está alcançável, mas as tarefas falham.” O guia de solução de problemas do MKController destaca Device-Mode disabled especificamente. Planeje para isso: inclua uma política de device-mode no seu checklist de staging, decida quais flags são permitidas antes do envio, e documente como a confirmação física acontecerá em cada site. Para contexto de segurança relacionado, veja nossos guias boas práticas de segurança Winbox e gerência remota com WireGuard.
Checklist pós-upgrade
Após cada upgrade do RouterOS ou ao receber hardware novo: confirme que o modo atual corresponde à política; valide ferramentas das quais você depende (fetch, scheduler); verifique allowed-versions em ambientes regulados; inspecione attempt-count e estado flagged em busca de anomalias; documente quais sites requerem confirmação física e como.
Dê o próximo passo
O device-mode é infraestrutura de segurança essencial mas adiciona sobrecarga operacional em escala, onde confirmação física em sites remotos não pode ser improvisada. O MKController centraliza inventário, governança de acesso e visibilidade para que você só toque no device-mode quando justificado, e o passo físico seja planejado em vez de reativo.