Firewall Servidores Mikrotik

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

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