Mudanças entre as edições de "Firewall Servidores Mikrotik"

De Wiki BPF
Ir para navegação Ir para pesquisar
Linha 9: Linha 9:
  
 
== 3. Regras de Firewall IPv4 ==
 
== 3. Regras de Firewall IPv4 ==
 +
=== 3.1 Address list Redes Confiaveis ===
 
A <code>address-list REDES_CONFIAVEIS</code> é 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.
 
A <code>address-list REDES_CONFIAVEIS</code> é 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.
  

Edição das 15h49min de 19 de janeiro de 2026

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.

Topologia-fw-server-mk.png

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
Disponível em “https://wiki.brasilpeeringforum.org/index.php?title=Firewall_Servidores_Mikrotik&oldid=4013”