Segurança no Mikrotik RouterOS v7: hardening passo a passo

Segurança no Mikrotik não depende de um script mágico copiado de fórum. Depende de fechar, uma por uma, as portas que o RouterOS deixa abertas de fábrica para facilitar a primeira configuração: usuário admin, Winbox aceitando qualquer origem, MAC server em todas as interfaces, descoberta de vizinhos, servidor de teste de banda e serviços que ninguém usa. Num roteador de casa isso já é risco. Num Mikrotik de borda ou num concentrador PPPoE com IP público, é convite.

Este guia é um checklist de hardening para RouterOS v7, na ordem em que eu aplicaria num equipamento novo. Cada comando de segurança no Mikrotik aqui vem da documentação oficial da MikroTik, com o porquê. Os exemplos usam a rede do NOC 198.51.100.0/24, um bastion em 203.0.113.10 e gerência IPv6 em 2001:db8:100::/48. Troque pelos seus endereços antes de colar.

Resposta rápida: checklist de segurança no Mikrotik

1. Crie um usuário próprio com grupo adequado, limite a origem com address= e desative o admin.
2. Desative telnet, ftp, www, www-ssl, api e api-ssl em /ip service. Restrinja SSH e Winbox à rede de gerência.
3. Desligue MAC server, MAC Winbox, MAC ping, neighbor discovery e bandwidth server nas interfaces de cliente e de trânsito.
4. Monte o firewall input: aceita estabelecidas, descarta inválidas, libera gerência por address-list, libera os protocolos de controle e descarta o resto. Faça o mesmo no IPv6.
5. SSH com strong-crypto, chave pública e chave de host ed25519.
6. Fique no canal long-term num equipamento de produção e atualize o RouterBOOT junto.
7. Guarde backup binário com senha e um /export em texto fora do roteador.

O que a segurança no Mikrotik precisa barrar

Antes dos comandos, vale separar plano de dados e plano de controle. O tráfego dos clientes que atravessa o roteador passa pela chain forward. O que é endereçado ao próprio roteador (Winbox, SSH, SNMP, BGP, DNS, ping) passa pela chain input e vai para a CPU. Hardening é proteger esse segundo caminho: quem fala com o roteador, por qual porta e com qual credencial.

A tabela abaixo resume os ataques mais comuns contra Mikrotik exposto e a camada que resolve cada um. Nenhuma camada sozinha dá conta de tudo. O firewall não ajuda se o usuário admin continua com senha vazia e acesso de qualquer origem pela camada 2.

Usuários e grupos: a primeira camada de segurança no Mikrotik

O RouterOS vem com o usuário admin no grupo full. Todo robô de força bruta tenta esse nome primeiro. A recomendação da MikroTik é criar um usuário seu e desativar o admin. Eu iria além: crie um grupo só de leitura para quem precisa consultar e não configurar, como o pessoal de suporte ou uma ferramenta de monitoramento.

/user group add name=leitura policy=read,ssh,winbox,test
/user add name=op.noc group=full password=SENHA-1
/user add name=leitor group=leitura password=SENHA-2
/user set op.noc address=198.51.100.0/24,2001:db8:100::/48
/user set leitor address=198.51.100.0/24,2001:db8:100::/48
/user settings set minimum-password-length=14 minimum-categories=3
/user disable admin

Linha por linha:

• /user group add cria o grupo leitura com as políticas read, ssh, winbox e test. Sem write, policy e sensitive, o usuário vê a configuração mas não muda nada nem lê senhas.
• O primeiro /user add cria o usuário de operação no grupo full. O /user set ... address= faz o RouterOS recusar o login desse usuário vindo de fora da rede do NOC, em IPv4 e IPv6, mesmo com a senha certa.
• O segundo /user add cria o usuário de consulta no grupo novo, e o segundo /user set prende esse usuário à mesma origem.
• /user settings exige senha com pelo menos 14 caracteres e 3 das 4 categorias (maiúscula, minúscula, número e símbolo). Vale para senhas novas.
• /user disable admin desativa o usuário padrão. Desativar em vez de apagar deixa o caminho de volta se algo der errado, mas só rode depois de testar o login com o usuário novo.

Serviços do /ip service: o que desligar

O /ip service lista os servidores de gerência do RouterOS e as portas padrão: telnet (23), ftp (21), www (80), ssh (22), www-ssl (443), api (8728), winbox (8291) e api-ssl (8729). Cada serviço ligado é mais uma porta para varrer e mais uma coisa para manter. Veja o que está ativo:

/ip service print
/ip service disable telnet,ftp,www,www-ssl,api,api-ssl
/ip service set ssh address=198.51.100.0/24,203.0.113.10/32,2001:db8:100::/48
/ip service set winbox address=198.51.100.0/24,203.0.113.10/32,2001:db8:100::/48

O print mostra a lista com a coluna de endereços permitidos. O disable desliga de uma vez telnet e ftp, que trafegam senha em texto puro, e os serviços web e de API. Se você usa a API REST ou a WebFig, mantenha o www-ssl ligado com certificado e restrinja a origem do mesmo jeito. Se usa a API para automação, prefira api-ssl e libere só o servidor que roda os scripts.

As duas linhas de set ... address= são a parte que mais protege. Com elas, o RouterOS só aceita conexão de SSH e Winbox vindas da rede do NOC, do bastion e do prefixo IPv6 de gerência. Se você não puser o prefixo IPv6 aqui, o acesso por IPv6 é recusado mesmo com o firewall liberando. É uma trava no próprio serviço, independente do firewall. Se um dia alguém apagar uma regra de filtro sem querer, essa trava continua valendo.

Trocar a porta do SSH para 2200, como a documentação mostra em outro exemplo, reduz o barulho de robô no log, mas não protege nada. Quem procura Mikrotik acha a porta nova em minutos. Trate como higiene de log, não como camada de proteção.

MAC server, neighbor discovery e bandwidth test

Esses três recursos são práticos na bancada e um furo em produção. O MAC server permite abrir Winbox e Telnet pelo endereço MAC, sem IP, por qualquer interface onde ele esteja ativo. Num concentrador, isso inclui a interface virada para os clientes. O neighbor discovery (MNDP, CDP e LLDP) anuncia identidade, modelo, versão e endereços para quem estiver no mesmo segmento. O bandwidth server aceita teste de banda de qualquer origem e pode ser usado para carregar a CPU.

/tool mac-server set allowed-interface-list=none
/tool mac-server mac-winbox set allowed-interface-list=none
/tool mac-server ping set enabled=no
/ip neighbor discovery-settings set discover-interface-list=none
/tool bandwidth-server set enabled=no

As duas primeiras linhas desligam o MAC Telnet e o MAC Winbox em todas as interfaces. A terceira desliga a resposta ao MAC ping. A quarta para a descoberta de vizinhos, e a última desliga o servidor de bandwidth test. Quando precisar de um teste de banda, ligue, rode e desligue de novo.

Mantendo uma porta de gerência local

Desligar tudo pode atrapalhar quem precisa entrar no roteador pela bancada quando o IP sumiu. A saída é criar uma interface list só com a porta de gerência física e liberar os recursos de camada 2 apenas nela:

/interface list add name=porta-gerencia
/interface list member add list=porta-gerencia interface=ether8
/tool mac-server mac-winbox set allowed-interface-list=porta-gerencia
/ip neighbor discovery-settings set discover-interface-list=porta-gerencia

A lista porta-gerencia recebe a ether8, que no exemplo é a porta reservada para acesso local. O MAC Winbox e a descoberta passam a funcionar só nessa porta. Em equipamento de borda, onde ninguém pluga notebook, deixar tudo em none é mais simples.

Outros serviços de cliente

A página de segurança da MikroTik lista mais alguns serviços que devem ficar desligados quando você não usa:

/ip dns set allow-remote-requests=no
/ip proxy set enabled=no
/ip socks set enabled=no
/ip upnp set enabled=no
/ip cloud set ddns-enabled=no update-time=no

O allow-remote-requests=no impede que o roteador responda DNS para outros hosts. Num concentrador que entrega o próprio IP como DNS aos clientes, ele precisa ficar em yes, e aí o firewall input tem de descartar consultas vindas da WAN, ou o roteador vira resolvedor aberto para ataques de amplificação. Proxy web, SOCKS, UPnP e o DDNS do IP Cloud raramente têm lugar num roteador de provedor.

Firewall input com address-list de gerência

Este é o centro da segurança no Mikrotik. A lógica é a de qualquer firewall de plano de controle: aceita o que já está estabelecido, descarta o inválido, libera explicitamente quem pode falar com o roteador e descarta o resto. As regras são avaliadas em ordem, de cima para baixo, e a primeira que casa decide.

/ip firewall address-list add address=198.51.100.0/24 list=gerencia comment="NOC"
/ip firewall address-list add address=203.0.113.10 list=gerencia comment="bastion"
/ip firewall address-list add address=203.0.113.1 list=peers-bgp
/ip firewall address-list add address=203.0.113.5 list=peers-bgp
/ip firewall filter add chain=input action=accept connection-state=established,related,untracked comment="estabelecidas"
/ip firewall filter add chain=input action=drop connection-state=invalid comment="invalidas"
/ip firewall filter add chain=input action=accept protocol=icmp comment="icmp"
/ip firewall filter add chain=input action=accept protocol=tcp dst-port=22,8291 src-address-list=gerencia comment="ssh e winbox"
/ip firewall filter add chain=input action=accept protocol=tcp dst-port=179 src-address-list=peers-bgp comment="bgp"
/ip firewall filter add chain=input action=accept protocol=udp dst-port=161 src-address-list=gerencia comment="snmp"
/ip firewall filter add chain=input action=drop comment="descarta o resto"

Explicando a ordem:

1. As quatro linhas de address-list criam duas listas: gerencia, com a rede do NOC e o bastion, e peers-bgp, com os vizinhos BGP. Mudar quem acessa vira editar a lista, sem mexer nas regras.
2. established,related,untracked aceita o retorno de conexões que o próprio roteador abriu, como consultas DNS, NTP, RADIUS e sessões BGP iniciadas por ele. Fica em primeiro lugar porque é a regra que mais casa e poupa CPU.
3. connection-state=invalid descarta pacotes que não pertencem a nenhuma conexão válida.
4. ICMP liberado mantém ping, traceroute e descoberta de MTU funcionando. Se quiser limitar, a configuração avançada da MikroTik mostra uma chain só para ICMP com limit=.
5. SSH (22) e Winbox (8291) só para a lista gerencia.
6. BGP (179) só para os peers. Sem essa regra, qualquer host da internet consegue abrir conexão TCP na porta 179 do roteador.
7. SNMP (161/UDP) só para a gerência, para o Zabbix ou outra ferramenta de monitoramento.
8. A última regra descarta todo o resto que chega ao roteador.

Adapte a lista de liberações ao papel do equipamento. Um roteador de borda com OSPF interno precisa aceitar o protocolo OSPF vindo do backbone. Um concentrador que recebe CoA ou desconexão do RADIUS precisa liberar essa porta para o servidor RADIUS. Um concentrador com VPN de gerência precisa liberar o protocolo dela; o guia de como criar VPN no Mikrotik mostra os tipos de túnel mais usados.

Um detalhe de segurança no Mikrotik que costuma passar batido: num concentrador que é o DNS dos clientes, libere UDP e TCP 53 vindos da interface dos clientes antes do descarte final, por exemplo com in-interface-list=; sem isso, a última regra corta a resolução de nomes de todo mundo. Se o concentrador também faz CGNAT, veja o guia de CGNAT no Mikrotik com netmap determinístico.

Segurança no Mikrotik também no IPv6

Um erro comum é caprichar no firewall IPv4 e deixar o IPv6 aberto. Se o roteador tem endereço global IPv6, o Winbox e o SSH respondem nele também. O filtro IPv6 segue a mesma lógica:

/ipv6 firewall address-list add address=2001:db8:100::/48 list=gerencia comment="NOC"
/ipv6 firewall filter add chain=input action=accept connection-state=established,related,untracked
/ipv6 firewall filter add chain=input action=drop connection-state=invalid
/ipv6 firewall filter add chain=input action=accept protocol=icmpv6
/ipv6 firewall filter add chain=input action=accept protocol=tcp dst-port=22,8291 src-address-list=gerencia
/ipv6 firewall filter add chain=input action=drop

A diferença está no ICMPv6, que no IPv6 não é opcional: descoberta de vizinhos, anúncio de roteador e Packet Too Big dependem dele. Por isso a regra aceita icmpv6 antes do descarte. Se você está começando com o protocolo, o artigo sobre o que é IPv6 explica por que ele funciona diferente. Se o roteador recebe prefixo por DHCPv6-PD ou fecha BGP em IPv6, libere também o UDP 546 vindo de fe80::/10 e a porta 179 para os peers IPv6 antes do descarte.

SSH forte: criptografia, chave de host e chave pública

Com SSH restrito à gerência, o próximo passo é deixar a sessão mais difícil de quebrar e trocar a senha por chave:

/ip ssh set strong-crypto=yes
/ip ssh set host-key-type=ed25519
/ip ssh regenerate-host-key
/user ssh-keys import public-key-file=op-noc.pub user=op.noc
/ip ssh set password-authentication=yes-if-no-key

• strong-crypto=yes faz o servidor usar algoritmos e HMAC mais fortes, primos DH maiores e recusar os fracos. O padrão é no.
• host-key-type=ed25519 seleciona chave de host Ed25519 no lugar da RSA padrão, e o regenerate-host-key gera o par novo. Os clientes vão reclamar de chave de host diferente na próxima conexão: atualize o known_hosts sabendo o motivo.
• /user ssh-keys import associa a chave pública do arquivo op-noc.pub ao usuário op.noc. Envie o arquivo para o roteador antes, por SCP ou pelo Winbox. São aceitas chaves RSA e Ed25519.
• password-authentication=yes-if-no-key é o padrão e significa que o usuário com chave importada não entra mais por senha via SSH. Quem ainda não tem chave continua usando senha.

Num roteador que só o NOC acessa por SSH, chave para todo mundo e senha só para o Winbox já melhora muito a segurança no Mikrotik contra força bruta. A documentação avisa que regenerar a chave de host pode fazer chaves importadas antes pararem de funcionar, então gere a chave de host primeiro e importe as chaves dos usuários depois.

Canal de atualização e RouterBOOT

Muitas invasões em massa de Mikrotik exploraram falhas que já tinham correção publicada havia meses. Atualizar é parte da segurança no Mikrotik tanto quanto o firewall. A MikroTik publica o RouterOS em quatro canais:

/system package update set channel=long-term
/system package update check-for-updates once
/system package update install
/system routerboard upgrade
/system reboot

O set channel=long-term fixa o canal. O check-for-updates once consulta o servidor da MikroTik e mostra a versão disponível; o install baixa e reinicia. Depois que o RouterOS sobe na versão nova, o /system routerboard upgrade atualiza o bootloader, e ele só passa a valer no próximo reboot. A documentação recomenda fazer as duas atualizações juntas.

Em provedor, atualização tem janela de manutenção, backup antes e plano de volta. Teste a versão num equipamento igual ou num CHR antes de aplicar no concentrador. E leia o changelog.

Backup e export: o plano de volta

Segurança no Mikrotik mal aplicada tranca o operador do lado de fora. Atualização mal sucedida derruba o roteador. Nos dois casos, o que salva é ter a configuração guardada fora do equipamento.

/system backup save name=borda-01 password=SENHA-DO-BACKUP
/export file=borda-01
/export show-sensitive file=borda-01-completo

• /system backup save gera um arquivo binário .backup com a configuração completa, criptografado com AES-SHA256 por padrão quando há senha. Serve para restaurar no mesmo equipamento ou num igual.
• /export file= gera um .rsc em texto, legível e fácil de comparar entre versões. No v7 o export esconde dados sensíveis por padrão, como senhas e chaves.
• /export show-sensitive inclui esses dados. Use só quando o arquivo for para um lugar protegido, porque ele passa a conter segredos em texto.

Os arquivos ficam no próprio roteador até alguém copiá-los. Tire de lá por SFTP para um servidor de backup, de preferência com rotina automática. O mesmo raciocínio vale para qualquer ativo da rede; na borda Huawei, por exemplo, o roteiro de o guia de BGP communities na borda Huawei também começa por guardar a configuração antes de mexer.

Como conferir a segurança no Mikrotik depois do hardening

Depois de aplicar tudo, confira de dentro e de fora. De dentro do roteador:

/user active print
/ip service print
/ip firewall filter print stats

O /user active print mostra quem está logado, por qual serviço e de qual endereço. O /ip service print confirma os serviços ligados e as origens permitidas. O print stats do filtro mostra os contadores de cada regra: a de descarte no fim da chain input deve subir sem parar num roteador com IP público, o que confirma que ela está barrando varreduras.

De fora, a partir de um host que não está na lista de gerência, tente abrir as portas 22, 8291, 8728 e 80 do roteador. Nenhuma deve responder. Repita pelo endereço IPv6. Depois, de dentro do NOC, confirme que o acesso legítimo continua funcionando antes de encerrar a janela.

Erros comuns de segurança no Mikrotik

• Aplicar a regra de descarte antes das liberações. A sessão cai e só resta o acesso local. Use o modo seguro e confira a ordem.
• Restringir o address= do usuário e esquecer o bastion. O acesso de emergência some junto.
• Proteger o IPv4 e esquecer o IPv6. O roteador continua respondendo Winbox e SSH no endereço global.
• Deixar o MAC server ativo na interface dos clientes. Qualquer cliente no mesmo domínio de camada 2 vê o roteador e pode tentar login.
• DNS com allow-remote-requests=yes sem filtro na WAN. O roteador vira refletor em ataques de amplificação.
• Liberar BGP para qualquer origem. A porta 179 deve aceitar só os peers.
• Guardar o backup só no próprio roteador. Se o equipamento morre, o backup morre junto.
• Ficar anos sem atualizar. Firewall bem feito não corrige falha no serviço que ele precisa deixar aberto.

Perguntas frequentes

Por onde começar a segurança no Mikrotik?

Comece pelo usuário: crie um seu, limite a origem com address= e desative o admin. Em seguida restrinja SSH e Winbox no /ip service e monte o firewall input. Essas três camadas resolvem a maior parte dos acessos indevidos.

Desativar o usuário admin basta para a segurança no Mikrotik?

Não. Ele tira o alvo mais óbvio dos robôs de força bruta, mas um usuário novo com senha fraca e Winbox aberto para a internet continua exposto. O que protege é a soma de usuário, restrição de serviço e firewall input.

Preciso desligar o MAC server em todos os Mikrotik?

Em roteador de borda e concentrador, sim. Se precisar dele, restrinja a uma interface list de gerência. O MAC Winbox permite login sem IP por qualquer interface onde estiver ativo, inclusive a dos clientes.

Qual canal do RouterOS usar em produção?

O long-term, que recebe só correções críticas dentro do mesmo ramo. O stable serve quando você precisa de um recurso novo e testou antes. Testing e development ficam no laboratório.

O firewall input atrapalha o tráfego dos clientes?

Não. A chain input trata só o que é endereçado ao próprio roteador. O tráfego que atravessa o equipamento passa pela chain forward, que tem regras próprias.

Backup binário ou export, qual guardar?

Os dois. O backup binário restaura tudo de uma vez no mesmo modelo de equipamento. O export em texto é legível, permite comparar versões e serve para remontar a configuração num equipamento diferente.

Conclusão

Segurança no Mikrotik é um conjunto de camadas pequenas: usuário próprio com origem limitada, serviços desligados, camada 2 fechada, firewall input com address-list, SSH com chave, versão long-term e backup fora do equipamento. Nenhuma delas é complicada, e cada uma cobre a falha da outra. Aplique numa janela, com modo seguro e uma segunda sessão aberta, e confira de fora antes de encerrar. Revise a segurança no Mikrotik a cada atualização de versão.

Leitura recomendada: Boas práticas de segurança para roteadores Mikrotik, da wiki do Brasil Peering Forum (CC BY-NC 4.0), que discute o tema com foco em provedores.