Regras base de firewall do MikroTik RouterOS 7 comentadas: input, forward, fasttrack, raw contra bogons e IPv6, aplicadas com Safe Mode.

Para que serve

O firewall do MikroTik não vem igual em todos os equipamentos: um RouterBOARD com a configuração padrão traz um conjunto mínimo de regras, enquanto um CHR ou um roteador resetado com no-defaults chega sem nenhuma regra, aceitando tudo. Este artigo apresenta um conjunto base para RouterOS 7, comentado linha a linha, separando o que vai na tabela raw (descarte barato, antes do connection tracking) e o que vai na filter (decisões com estado). Ele serve de fundação para os outros artigos desta categoria (força bruta, NAT, WireGuard).

Pré-requisitos

Risco de se trancar para fora. Ative o Safe Mode (Ctrl+X no terminal ou botão no Winbox) antes de colar as regras. Se a sessão cair, o RouterOS desfaz tudo. Se você está administrando pela WAN, confira que a regra de aceite da VPN ou do seu IP fixo vem antes do drop final. Para desfazer manualmente pelo console: /ip firewall filter disable [find].

Como o RouterOS processa o tráfego

  • input: pacotes destinados ao próprio roteador (Winbox, SSH, DNS, WireGuard).
  • forward: pacotes que atravessam o roteador (LAN ↔ internet, LAN ↔ VPN).
  • output: pacotes gerados pelo roteador. Raramente precisa de regra.
  • raw prerouting: roda antes do connection tracking. É o lugar para descartar lixo em grande volume (IPs impossíveis, listas negras) gastando pouca CPU.

As regras são lidas de cima para baixo e a primeira que casa decide. Por isso a ordem abaixo importa.

Passo 1: listas de endereços

/ip firewall address-list
add list=redes_internas address=192.168.88.0/24 comment="LAN"
add list=redes_internas address=10.8.0.0/24 comment="VPN admin"
add list=admin_permitidos address=10.8.0.0/24 comment="quem pode gerenciar"
# endereços que nunca deveriam chegar pela internet
add list=bogons address=0.0.0.0/8
add list=bogons address=127.0.0.0/8
add list=bogons address=169.254.0.0/16
add list=bogons address=192.0.0.0/24
add list=bogons address=198.18.0.0/15
add list=bogons address=224.0.0.0/3

Repare que 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 e 100.64.0.0/10 ficaram de fora da lista de bogons. No Brasil é muito comum o link chegar com IP de CGNAT (100.64.x.x) ou atrás do modem da operadora em 192.168.x.x; descartar essas faixas na WAN derrubaria a sua própria internet. Só inclua as faixas privadas se o seu IP da WAN for público e direto.

Passo 2: regras raw (descartar antes do connection tracking)

/ip firewall raw
add chain=prerouting action=drop in-interface-list=WAN src-address-list=bogons comment="origem impossivel vinda da internet"
add chain=prerouting action=drop in-interface-list=WAN src-address-list=lista_negra comment="IPs bloqueados (preenchida por outras regras)"
add chain=prerouting action=drop protocol=udp port=0 comment="UDP porta 0"
add chain=prerouting action=drop protocol=tcp port=0 comment="TCP porta 0"
add chain=prerouting action=drop protocol=tcp tcp-flags=syn,fin comment="combinacao de flags invalida"
add chain=prerouting action=drop protocol=tcp tcp-flags=syn,rst comment="combinacao de flags invalida"

A lista lista_negra ainda está vazia; ela é alimentada pelas regras do artigo de proteção contra força bruta. Bloquear nela via raw é bem mais leve do que na filter.

Passo 3: chain input (proteger o próprio roteador)

/ip firewall filter
add chain=input action=accept connection-state=established,related,untracked comment="IN: respostas de conexoes ja aceitas"
add chain=input action=drop connection-state=invalid comment="IN: pacotes invalidos"
add chain=input action=accept protocol=icmp comment="IN: ping e mensagens ICMP (necessario para PMTU)"
add chain=input action=accept protocol=udp dst-port=13231 in-interface-list=WAN comment="IN: WireGuard"
add chain=input action=accept in-interface-list=LAN comment="IN: tudo vindo da LAN"
add chain=input action=accept src-address-list=admin_permitidos comment="IN: administracao pela VPN"
add chain=input action=drop log=yes log-prefix="IN-DROP " comment="IN: descarta o resto"

A porta 13231/udp é a padrão do WireGuard no RouterOS; ajuste ou remova se não usar. Deixe o log=yes do último drop ligado só nos primeiros dias, para conferir se algo legítimo está sendo barrado, e depois desligue para não encher o log.

Passo 4: chain forward (proteger a LAN)

/ip firewall filter
add chain=forward action=fasttrack-connection connection-state=established,related hw-offload=yes connection-mark=no-mark comment="FWD: fasttrack (acelera conexoes estabelecidas)"
add chain=forward action=accept connection-state=established,related,untracked comment="FWD: respostas"
add chain=forward action=drop connection-state=invalid comment="FWD: invalidos"
add chain=forward action=drop in-interface-list=WAN connection-nat-state=!dstnat connection-state=new comment="FWD: internet so entra se houver redirecionamento de porta"
add chain=forward action=accept connection-nat-state=dstnat connection-state=new comment="FWD: aceita o que foi redirecionado por dst-nat"
add chain=forward action=accept in-interface-list=LAN out-interface-list=WAN comment="FWD: LAN pode navegar"
add chain=forward action=drop log=yes log-prefix="FWD-DROP " comment="FWD: descarta o resto"

Pontos importantes:

  • FastTrack faz os pacotes de conexões estabelecidas pularem boa parte do processamento. Ganha-se muito desempenho, mas esses pacotes não passam por filas (QoS) nem por mangle. O filtro connection-mark=no-mark deixa de fora conexões marcadas para balanceamento ou QoS (veja os artigos de PCC e QoS).
  • A regra com connection-nat-state=!dstnat é a que impede a internet de alcançar a LAN; a seguinte aceita apenas o que você publicar com dst-nat (artigo de NAT). Sem uma regra dst-nat, nada de fora entra.
  • Tráfego entre LAN e túneis VPN precisa de regras de aceite próprias antes do drop final, por exemplo add chain=forward action=accept src-address-list=redes_internas dst-address-list=redes_internas place-before=[find comment="FWD: descarta o resto"].

Passo 5: IPv6 também precisa de firewall

Se a operadora entrega IPv6, cada dispositivo da LAN tem endereço público. Sem regras, todos ficam expostos:

/ipv6 firewall filter
add chain=input action=accept connection-state=established,related,untracked
add chain=input action=drop connection-state=invalid
add chain=input action=accept protocol=icmpv6
add chain=input action=accept protocol=udp dst-port=546 src-address=fe80::/10 comment="DHCPv6 cliente (prefixo da operadora)"
add chain=input action=accept in-interface-list=LAN
add chain=input action=drop
add chain=forward action=accept connection-state=established,related,untracked
add chain=forward action=drop connection-state=invalid
add chain=forward action=accept protocol=icmpv6
add chain=forward action=accept in-interface-list=LAN out-interface-list=WAN
add chain=forward action=drop

Não bloqueie ICMPv6: sem ele a descoberta de vizinhos e o PMTU deixam de funcionar.

Como saber se funcionou

  1. Saia do Safe Mode só depois de abrir uma nova sessão Winbox/SSH e confirmar que entra.
  2. /ip firewall filter print stats mostra os contadores de cada regra. As de established e fasttrack devem subir rápido; o drop final deve contar tentativas vindas da internet.
  3. De um host externo: nmap -Pn -p 22,8291,53 IP_PUBLICO deve retornar filtered.
  4. Da LAN, a navegação continua normal e /log print where message~"DROP" não mostra tráfego legítimo seu.

Problemas comuns

  • Internet parou após o raw: o IP da sua WAN (ou o gateway da operadora) está numa faixa da lista bogons. Remova a faixa correspondente.
  • Regra nova não tem efeito: ela foi adicionada no fim, depois do drop. Use place-before ou arraste a regra no Winbox.
  • Redirecionamento de porta não funciona: confira se a regra de dst-nat existe; sem ela, o forward descarta a conexão de propósito.
  • QoS ou PCC sem efeito: o FastTrack está acelerando as conexões. Use o filtro connection-mark=no-mark ou desative o FastTrack.

Perguntas frequentes

Qual a diferença entre raw e filter no MikroTik?

A raw age antes do connection tracking e não conhece estado de conexão; é ideal para descartar volume. A filter conhece o estado (new, established, invalid) e é onde ficam as decisões de política.

Devo usar drop ou reject?

Para tráfego vindo da internet, drop: não responde e não ajuda quem está varrendo portas. reject pode ser útil na LAN, para que um programa falhe rápido em vez de esperar o timeout.

O firewall padrão da RouterBOARD é suficiente?

Ele é um bom ponto de partida e segue a mesma lógica deste artigo. Revise se o seu equipamento ainda tem essas regras: um reset com no-defaults ou um CHR começa sem nenhuma.

O AntiDDoS do datacenter dispensa o firewall do CHR?

Não. A proteção da rede mitiga ataques volumétricos; o controle de quem acessa o Winbox, o SSH e as portas publicadas continua sendo seu.

Leitura complementar

Precisa de ajuda?

Se o CHR do seu servidor ficou inacessível após mudanças de firewall e você não consegue abrir o console da VM, abra um ticket na Área do Cliente informando a VM e a última regra aplicada.

Esta resposta lhe foi útil? 0 Usuários acharam útil (0 Votos)

Leia também