Firewall Servidores Mikrotik

De Wiki BPF
Revisão de 16h12min de 19 de janeiro de 2026 por Sandino (discussão | contribs) (→‎5. Conclusão)
Ir para navegação Ir para pesquisar

1. Introdução

O objetivo desse documento é descrever um padrão de firewall para proteção de servidores (aplicações) em roteadores mikrotik, baseado em /ip firewall filter, adotando um modelo mais simples de gerenciar suas regras. O conceito principal é negar por aplicação, ou seja, cada servidor (aplicação) possui sua própria chain e apenas os serviços necessários são abertos, utilizando um drop para cada aplicação individual.

2. Conceito do Firewall por CHAIN

Por padrão do mikrotik o firewall dele é ACCEPT, ou seja, ele não irá negar o trafego por padrão como normalmente os firewalls no mercado realizam, sendo assim precisamos realizar uma regra de DROP, o mais comum é fazer um DROP GERAL no final, com este tipo de configuração o DROP afeta o ambiente completo, sendo muito comum acabar o DROP ser desabilitado em momento de problema e nunca mais ser habilitado novamente (é raro mas acontece sempre kkkk), assim foi pensado em realizar o firewall por CHAIN, ou seja, cada servidor (aplicação) possui seu firewall independente, ou seja, o que é feito na chain de um servidor não impacta no outro, cada servidor possui seu drop, isolando as regras e deixando mais facil a gerencia com ambiente com bastante aplicações, para isto é utilizado JUMP e CHAIN, basicamente é criado uma CHAIN com nome da aplicação onde tudo que for em destino ao IP da aplicação desejada irá redirecionar para aquela CHAIN onde ela irá liberar as portas necessárias e o restante irá bloquear.

O fluxo do trafego é pensado em aplicações que necessitam estar publicadas para internet ou somente para endereços específicos, então o trafego no geral vem da WAN do mikrotik e assim utilizando /ip firewall filter irá realizar filtros individuais para cada servidor sendo FORWARD pois o tráfego passa por ele e de INPUT para endereços públicos no próprio roteador, por exemplo endereço de acesso do equipamento.

3. Regras de Firewall IPv4

3.1 Address list Redes Confiaveis

A address-list REDES_CONFIAVEIS é utilizada para identificar redes e endereços IP que possuem permissão administrativa, como acessos de NOC, VPN, jump server ou redes internas confiáveis.

Todas as regras de gestão e administração do firewall fazem referência a esta lista, evitando a necessidade de repetir IPs diretamente nas regras.

📌 Conceito

A REDES_CONFIAVEIS deve conter apenas origens confiáveis, pois qualquer endereço incluído nela poderá:

  • Acessar serviços administrativos
  • Ignorar regras específicas de servidores
  • Ter prioridade no fluxo do firewall

⚠️ Nunca adicione IPs públicos ou redes desconhecidas a esta lista.

🧩 Tipos de endereços recomendados

Normalmente, a lista pode conter:

  • Redes internas (LAN / DC)
  • Endereços de VPN
  • IPs fixos do NOC
  • Jump servers
  • Hosts de administração

Exemplos comuns:

  • 192.168.0.0/16
  • 10.0.0.0/8
  • 172.16.0.0/12
  • IP público fixo do escritório
  • IP de saída da VPN
  • Evite utilizar redes muito amplas, tente deixar o mais restrito possível, evite usar a RFC1918 inteira.

🔧 Criação da Address-List

Exemplo básico 

/ip firewall address-list
add list=REDES_CONFIAVEIS address=192.168.0.0/16 comment="Rede interna"
add list=REDES_CONFIAVEIS address=10.0.0.0/8 comment="Rede privada"
add list=REDES_CONFIAVEIS address=200.200.200.10 comment="IP fixo NOC"

🔐 Uso com VPN

Caso exista VPN, é recomendado adicionar apenas a rede da VPN, e não endereços individuais: 

/ip firewall address-list
add list=REDES_CONFIAVEIS address=10.99.0.0/24 comment="Rede VPN Administrativa"

Isso facilita manutenção e crescimento futuro.

🛡️ Boas práticas

  • Utilize comentários claros em cada entrada
  • Revise periodicamente a lista
  • Remova IPs temporários após uso
  • Evite listas muito amplas sem necessidade

⚠️ Impacto no Firewall

Qualquer tráfego originado de endereços presentes na REDES_CONFIAVEIS:

  • Será aceito diretamente nas regras de forward e no input
  • Terá acesso aos serviços administrativos
  • Não passará pelas regras específicas de servidores

Por isso, esta lista deve ser tratada como zona de alta confiança.

📝 Observação Final

A correta definição da REDES_CONFIAVEIS é fundamental para a segurança do ambiente.

Um erro nesta lista pode resultar em exposição administrativa indevida.

Sempre valide os endereços antes de adicioná-los.

3.2 Conexões estabelecidas

Estas regras devem estar sempre no início do firewall, garantindo o funcionamento correto das sessões já criadas.

ip firewall filter 

add chain=input connection-state=established,related action=accept \
    comment="ACEITA CONEXÕES ESTABELECIDAS"

add chain=forward connection-state=established,related action=accept \
    comment="ACEITA CONEXÕES ESTABELECIDAS"

Objetivo

  • Manter conexões ativas
  • Evitar reprocessamento de pacotes
  • Garantir estabilidade dos serviços

3.3 Conexões de redes confiáveis

Este bloco centraliza o tratamento de redes internas, VPNs ou endereços administrativos.

Todo tráfego originado dessas redes é aceito diretamente no forward e no input, sem passar pelas regras específicas de servidores, somente tenha cuidado com o que libera, evite liberar por exemplo seu prefixo completo de IPv4, libere IPs específicos, como /32, a partir do momento que você libera o seu bloco completo seu usuário final, uma maquina comprometida dentro da infraestrutura pode acessar aquela aplicação que muita das vezes pode não ser o necessário. 

add action=jump chain=forward src-address-list=REDES_CONFIAVEIS \
    jump-target=REDES_CONFIAVEIS comment="REDES CONFIAVEIS"

add action=jump chain=input src-address-list=REDES_CONFIAVEIS \
    jump-target=REDES_CONFIAVEIS comment="REDES CONFIAVEIS"

add action=accept chain=REDES_CONFIAVEIS

Objetivo

  • Facilitar administração
  • Evitar repetição de regras
  • Padronizar acessos de gestão

3.4 Regra para INPUT

Estas regras controlam o acesso ao próprio roteador ou a endereços de gestão publicados.

Somente redes previamente autorizadas podem acessar serviços administrativos, como winbox e ssh. Além de você ter o /ip service o bloqueio de ips de acesso ao bloquear no service o mikrotik ainda continua respondendo a porta, ele não bloqueia a porta e sim quem pode acessa-la, diferentemente do firewall que o roteador parará de escutar a porta para IPs fora da range liberada.

As redes liberadas para acesso do seu roteador devem estar na address list REDES_CONFIAVEIS, antes de aplicar valide que esteja a rede na sua address list. 

add action=jump chain=input dst-address=X.X.X.X jump-target=CE-DMZ \
    comment="CE-DMZ INPUT"

add action=accept chain=CE-DMZ protocol=tcp dst-port=22,8291 \
    src-address-list=REDES_CONFIAVEIS

add action=accept chain=CE-DMZ protocol=udp dst-port=22,8291 \
    src-address-list=REDES_CONFIAVEIS

add action=accept chain=CE-DMZ protocol=icmp

add action=drop chain=CE-DMZ

Objetivo

  • Proteger serviços administrativos
  • Restringir acesso por origem
  • Impedir tentativas não autorizadas

3.5 Aplicação de exemplo (ZABBIX/GRAFANA)

Regras dedicadas ao servidor Zabbix, permitindo apenas os serviços necessários para acesso e operação.

Qualquer outro tráfego destinado a este servidor é descartado. 

add action=jump chain=forward dst-address=X.X.X.X jump-target=Zabbix \
    comment="ZABBIX SERVER"

add action=accept chain=Zabbix protocol=tcp dst-port=80,443,3000

add action=accept chain=Zabbix protocol=icmp

add action=drop chain=Zabbix

Objetivo

  • Limitar exposição do servidor
  • Bloquear portas não utilizadas
  • Manter o controle isolado por aplicação
  • Desta forma somente liberamos a porta 80,443 e 3000 para internet (so libere para internet se realmente precisar acessar externo e não possa acessar via VPN por exemplo), evite o máximo aplicações publicas caso não existe 100% da necessidade, desta forma somente as portas necessárias ficariam abertas, por exemplo o SSH estaria fechado para todos neste caso, exceto para REDES_CONFIAVEIS

3.6. Aplicação de exemplo (DNS)

Somente endereços presentes na RESOLVE-DNS conseguem consultar o DNS.

Qualquer outra origem é descartada, evitando DNS aberto e abusos.

A lista normalmente contém:

  • Blocos IPv4 públicos dos clientes
  • Rede de CGNAT (100.64.0.0/10) por padrão tente fazer as requisições para seu servidor de DNS não passar por CGNAT, com exemplo com exceção no PBR.

🔧 Address-List RESOLVE-DNS

/ip firewall address-list

add list=RESOLVE-DNS address=100.64.0.0/10 comment="CGNAT clientes"

add list=RESOLVE-DNS address=187.45.120.0/24 comment="Cliente ISP A"

add list=RESOLVE-DNS address=200.200.200.0/22 comment="Meu bloco"

🔐 Regras de Firewall – DNS Anycast

Os IPs Anycast utilizados são:

  • 200.200.200.1 – Primário
  • 200.200.200.2 – Secundário

Todo tráfego destinado a esses IPs é tratado na chain DNS.


/ip firewall filter

add chain=forward dst-address=200.200.200.1 action=jump jump-target=DNS comment="DNS PRIMARIO"

add chain=forward dst-address=200.200.200.2 action=jump jump-target=DNS comment="DNS SECUNDARIO"

add chain=DNS protocol=icmp action=accept comment="ICMP DNS"

add chain=DNS protocol=udp dst-port=53 src-address-list=RESOLVE-DNS action=accept comment="DNS UDP autorizado"

add chain=DNS action=drop comment="DROP DNS NAO AUTORIZADO"

🛡️ Boas práticas

  • Nunca permitir DNS sem address-list
  • Separar lista de DNS de listas administrativas
  • Manter comentários claros por cliente
  • Revisar blocos removidos ou inativos
  • Evitar liberar 0.0.0.0/0

📝 Observação

A RESOLVE-DNS autoriza apenas resolução de nomes, não acesso administrativo.

Este modelo garante:

  • DNS fechado
  • Controle por cliente
  • Segurança contra abuso e amplificação

4. Regras de Firewall IPv6

O firewall IPv6 segue exatamente o mesmo conceito do IPv4, utilizando isolamento por aplicação através de chains dedicadas, evitando drops globais e mantendo o controle individual por serviço.

A principal diferença é apenas o uso de /ipv6 firewall filter e endereços IPv6 /128 para hosts, sempre tenha firewall IPv6 para as suas aplicações também.

4.1 Conexões estabelecidas

Estas regras devem ficar no início do firewall IPv6, garantindo o funcionamento correto das conexões já existentes.

/ipv6 firewall filter

add chain=forward connection-state=established,related action=accept comment="CONEXOES ESTABELECIDAS/RELACIONADAS"

Objetivo

Manter sessões ativas

Evitar reprocessamento desnecessário

Garantir estabilidade dos serviços IPv6

4.2 Redes Confiáveis (IPv6)

Assim como no IPv4, a address-list REDES_CONFIAVEIS centraliza origens administrativas também no IPv6.

Todo tráfego originado dessas redes é aceito diretamente no forward e no input.

/ipv6 firewall filter

add action=jump chain=forward src-address-list=REDES_CONFIAVEIS jump-target=REDES_CONFIAVEIS comment="REDES CONFIAVEIS"

add action=jump chain=input src-address-list=REDES_CONFIAVEIS jump-target=REDES_CONFIAVEIS comment="REDES CONFIAVEIS"

add action=accept chain=REDES_CONFIAVEIS

Objetivo

Centralizar acessos administrativos

Evitar repetição de regras

Facilitar manutenção do firewall IPv6

⚠️ Evite adicionar prefixos IPv6 muito amplos (/32, /29). Sempre que possível, utilize o menor tamanho de prefixo possível ou prefixos bem definidos.

4.3 Regra de INPUT – DMZ IPv6

Estas regras controlam o acesso a endereços IPv6 de gestão publicados no próprio roteador.

Somente origens presentes na REDES_CONFIAVEIS conseguem acessar serviços administrativos.

/ipv6 firewall filter

add action=jump chain=input comment=CE-DMZ dst-address=2804:XXXX:1::1/128 jump-target=CE-DMZ

add action=accept chain=CE-DMZ dst-port=22,8291 protocol=tcp src-address-list=REDES_CONFIAVEIS

add action=drop chain=CE-DMZ

Objetivo

  • Proteger o acesso administrativo IPv6
  • Restringir por origem confiável
  • Bloquear tentativas não autorizadas

4.4 Aplicação de exemplo – DNS IPv6

Neste cenário, os servidores DNS IPv6 são protegidos por uma chain dedicada (DNS).

Somente endereços presentes na address-list RESOLVE-DNS podem realizar consultas.

Os IPs utilizados são:

2804:XXXX:2::4 – Primário

2804:XXXX:4::5 – Secundário

/ipv6 firewall filter

add action=jump chain=forward comment="DNS PRIMARIO" dst-address=2804:XXXX:2::4/128 jump-target=DNS

add action=jump chain=forward comment="DNS SECUNDARIO" dst-address=2804:XXXX:2::5/128 jump-target=DNS

add action=accept chain=DNS protocol=icmp

add action=accept chain=DNS dst-port=53 protocol=udp src-address-list=RESOLVE-DNS

add action=drop chain=DNS

Objetivo

  • Evitar DNS aberto em IPv6
  • Controlar resolução por origem
  • Prevenir abuso e amplificação

📝 Observação Final (IPv6)

O firewall IPv6 não deve ser tratado como opcional. Todo serviço publicado em IPv4 caso tenha IPv6 também necessita de firewall, visto que o IPv6 é possível disponibilizar acesso via ssh, amplificações e etc, IPv6 é o protocolo padrão da internet!

5. Conclusão

Este padrão de firewall por chain permite facilitar a gerencia das regras e garantir uma gerencia facilitada, evitando o problema de desabilitar o DROP geral de firewall que sempre ocorre em momentos de problema e acaba ficando dias sem estar habilitado ou até mesmo nunca mais habilitado novamente. A ideia é realizar um padrão de firewall onde garantimos segurança e gerencia facilitada.

6. Sobre mim

Este é meu primeiro publicado, em caso de qualquer erro ou sugestão de melhoria aceito com gratidão, caso tenha duvida e queira tirar duvidas sobre o firewall pode entrar em contato comigo:

Telefone (whatsapp): 19 987601686

e-mail: vitor.sandino@version2.com.br

Disponível em “https://wiki.brasilpeeringforum.org/index.php?title=Firewall_Servidores_Mikrotik&oldid=4023”