Wiki BPF - Contribuições do(a) usuário(a) [pt-br]

Firewall Servidores Mikrotik

2026-01-19T19:25:33Z

Sandino: /* 📝 Observação Final (IPv6) */

== 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.

[[Arquivo:Topologia-fw-server-mk.png|borda|semmoldura|alt=|centro]]

== 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.

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 <code>REDES_CONFIAVEIS</code> 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:
* <code>192.168.0.0/16</code>
* <code>10.0.0.0/8</code>
* <code>172.16.0.0/12</code>
* 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'''
<pre>
/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"
</pre>

----

🔐 '''Uso com VPN'''

Caso exista VPN, é recomendado adicionar '''apenas a rede da VPN''', e não endereços individuais:
<pre>
/ip firewall address-list
add list=REDES_CONFIAVEIS address=10.99.0.0/24 comment="Rede VPN Administrativa"
</pre>
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 <code>REDES_CONFIAVEIS</code>:
* 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 <code>REDES_CONFIAVEIS</code> é 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.

<pre>
/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"
</pre>

'''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 <code>'''forward'''</code> e no <code>'''input'''</code>, 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.

<pre>
/ip 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
</pre>

'''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 <code>/ip service</code> 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 <code>REDES_CONFIAVEIS</code>, antes de aplicar valide que esteja a rede na sua address list.

<pre>
/ip firewall filter
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
</pre>

'''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.

<pre>
/ip firewall filter
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
</pre>

'''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 <code>RESOLVE-DNS</code> 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 (<code>100.64.0.0/10</code>) 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 <code>RESOLVE-DNS</code>'''

<pre>
/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"
</pre>

----

🔐 '''Regras de Firewall – DNS Anycast'''

Os IPs Anycast utilizados são:
* <code>200.200.200.1</code> – Primário
* <code>200.200.200.2</code> – Secundário

Todo tráfego destinado a esses IPs é tratado na chain <code>DNS</code>.

<pre>
/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"
</pre>

----

🛡️ '''Boas práticas'''
* Nunca permitir DNS sem <code>address-list</code>
* Separar lista de DNS de listas administrativas
* Manter comentários claros por cliente
* Revisar blocos removidos ou inativos
* Evitar liberar <code>0.0.0.0/0</code>

----

📝 '''Observação'''

A <code>RESOLVE-DNS</code> '''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 <code>/ipv6 firewall filter</code> 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.

<pre>
/ipv6 firewall filter
add chain=forward connection-state=established,related action=accept comment="CONEXOES ESTABELECIDAS/RELACIONADAS"
</pre>

'''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 <code>REDES_CONFIAVEIS</code> centraliza origens administrativas também no IPv6.

Todo tráfego originado dessas redes é aceito diretamente no <code>forward</code> e no <code>input</code>.

<pre>
/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
</pre>

'''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 <code>REDES_CONFIAVEIS</code> conseguem acessar serviços administrativos.

<pre>
/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
</pre>

'''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 (<code>DNS</code>).

Somente endereços presentes na address-list <code>RESOLVE-DNS</code> podem realizar consultas.

Os IPs utilizados são:
* <code>2804:XXXX:2::4</code> – Primário
* <code>2804:XXXX:4::5</code> – Secundário

<pre>
/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
</pre>

'''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

Firewall Servidores Mikrotik

2026-01-19T19:24:14Z

Sandino:

== 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.

[[Arquivo:Topologia-fw-server-mk.png|borda|semmoldura|alt=|centro]]

== 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.

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 <code>REDES_CONFIAVEIS</code> 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:
* <code>192.168.0.0/16</code>
* <code>10.0.0.0/8</code>
* <code>172.16.0.0/12</code>
* 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'''
<pre>
/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"
</pre>

----

🔐 '''Uso com VPN'''

Caso exista VPN, é recomendado adicionar '''apenas a rede da VPN''', e não endereços individuais:
<pre>
/ip firewall address-list
add list=REDES_CONFIAVEIS address=10.99.0.0/24 comment="Rede VPN Administrativa"
</pre>
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 <code>REDES_CONFIAVEIS</code>:
* 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 <code>REDES_CONFIAVEIS</code> é 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.

<pre>
/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"
</pre>

'''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 <code>'''forward'''</code> e no <code>'''input'''</code>, 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.

<pre>
/ip 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
</pre>

'''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 <code>/ip service</code> 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 <code>REDES_CONFIAVEIS</code>, antes de aplicar valide que esteja a rede na sua address list.

<pre>
/ip firewall filter
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
</pre>

'''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.

<pre>
/ip firewall filter
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
</pre>

'''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 <code>RESOLVE-DNS</code> 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 (<code>100.64.0.0/10</code>) 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 <code>RESOLVE-DNS</code>'''

<pre>
/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"
</pre>

----

🔐 '''Regras de Firewall – DNS Anycast'''

Os IPs Anycast utilizados são:
* <code>200.200.200.1</code> – Primário
* <code>200.200.200.2</code> – Secundário

Todo tráfego destinado a esses IPs é tratado na chain <code>DNS</code>.

<pre>
/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"
</pre>

----

🛡️ '''Boas práticas'''
* Nunca permitir DNS sem <code>address-list</code>
* Separar lista de DNS de listas administrativas
* Manter comentários claros por cliente
* Revisar blocos removidos ou inativos
* Evitar liberar <code>0.0.0.0/0</code>

----

📝 '''Observação'''

A <code>RESOLVE-DNS</code> '''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 <code>/ipv6 firewall filter</code> 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.

<pre>
/ipv6 firewall filter
add chain=forward connection-state=established,related action=accept comment="CONEXOES ESTABELECIDAS/RELACIONADAS"
</pre>

'''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 <code>REDES_CONFIAVEIS</code> centraliza origens administrativas também no IPv6.

Todo tráfego originado dessas redes é aceito diretamente no <code>forward</code> e no <code>input</code>.

<pre>
/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
</pre>

'''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 <code>REDES_CONFIAVEIS</code> conseguem acessar serviços administrativos.

<pre>
/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
</pre>

'''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 (<code>DNS</code>).

Somente endereços presentes na address-list <code>RESOLVE-DNS</code> podem realizar consultas.

Os IPs utilizados são:
* <code>2804:XXXX:2::4</code> – Primário
* <code>2804:XXXX:4::5</code> – Secundário

<pre>
/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
</pre>

'''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

Firewall Servidores Mikrotik

2026-01-19T19:12:05Z

Sandino: /* 5. Conclusão */

== 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.
[[Arquivo:Topologia-fw-server-mk.png|borda|semmoldura|alt=|centro]]

== 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.

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 <code>REDES_CONFIAVEIS</code> 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:
* <code>192.168.0.0/16</code>
* <code>10.0.0.0/8</code>
* <code>172.16.0.0/12</code>
* 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'''
<code>/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"</code>
----🔐 Uso com VPN

Caso exista VPN, é recomendado adicionar '''apenas a rede da VPN''', e não endereços individuais:
<code>/ip firewall address-list
add list=REDES_CONFIAVEIS address=10.99.0.0/24 comment="Rede VPN Administrativa"</code>
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 <code>REDES_CONFIAVEIS</code>:
* 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 <code>REDES_CONFIAVEIS</code> é 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.

<code>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"</code>
'''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 <code>'''forward''' e no '''input'''</code>, 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.
<code>add action=jump chain=forward src-address-list=REDES_CONFIAVEIS \
jump-target=REDES_CONFIAVEIS comment="REDES CONFIAVEIS"</code>

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

add action=accept chain=REDES_CONFIAVEIS</code>
'''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.
<code>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</code>
'''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.
<code>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</code>
'''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 <code>RESOLVE-DNS</code> 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 (<code>100.64.0.0/10</code>) 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 <code>RESOLVE-DNS</code>

<code>/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"</code>
----🔐 Regras de Firewall – DNS Anycast

Os IPs Anycast utilizados são:
* <code>200.200.200.1</code> – Primário
* <code>200.200.200.2</code> – Secundário
Todo tráfego destinado a esses IPs é tratado na chain <code>DNS</code>.

<code>/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"</code>

----🛡️ Boas práticas
* Nunca permitir DNS sem <code>address-list</code>
* Separar lista de DNS de listas administrativas
* Manter comentários claros por cliente
* Revisar blocos removidos ou inativos
* Evitar liberar <code>0.0.0.0/0</code>
----📝 Observação

A <code>RESOLVE-DNS</code> '''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.

<code>/ipv6 firewall filter

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

'''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 <code>REDES_CONFIAVEIS</code> centraliza origens administrativas também no IPv6.

Todo tráfego originado dessas redes é aceito diretamente no <code>forward</code> e no <code>input</code>.

<code>/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</code>

'''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 <code>REDES_CONFIAVEIS</code> conseguem acessar serviços administrativos.

<code>/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</code>

'''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 (<code>DNS</code>).

Somente endereços presentes na address-list <code>RESOLVE-DNS</code> podem realizar consultas.

Os IPs utilizados são:

<code>2804:XXXX:2::4</code> – Primário

<code>2804:XXXX:4::5</code> – Secundário

<code>/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

</code>

'''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

Firewall Servidores Mikrotik

2026-01-19T19:09:16Z

Sandino: /* 4.4 Aplicação de exemplo – DNS IPv6 */

== 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.
[[Arquivo:Topologia-fw-server-mk.png|borda|semmoldura|alt=|centro]]

== 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.

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 <code>REDES_CONFIAVEIS</code> 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:
* <code>192.168.0.0/16</code>
* <code>10.0.0.0/8</code>
* <code>172.16.0.0/12</code>
* 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'''
<code>/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"</code>
----🔐 Uso com VPN

Caso exista VPN, é recomendado adicionar '''apenas a rede da VPN''', e não endereços individuais:
<code>/ip firewall address-list
add list=REDES_CONFIAVEIS address=10.99.0.0/24 comment="Rede VPN Administrativa"</code>
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 <code>REDES_CONFIAVEIS</code>:
* 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 <code>REDES_CONFIAVEIS</code> é 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.

<code>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"</code>
'''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 <code>'''forward''' e no '''input'''</code>, 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.
<code>add action=jump chain=forward src-address-list=REDES_CONFIAVEIS \
jump-target=REDES_CONFIAVEIS comment="REDES CONFIAVEIS"</code>

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

add action=accept chain=REDES_CONFIAVEIS</code>
'''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.
<code>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</code>
'''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.
<code>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</code>
'''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 <code>RESOLVE-DNS</code> 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 (<code>100.64.0.0/10</code>) 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 <code>RESOLVE-DNS</code>

<code>/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"</code>
----🔐 Regras de Firewall – DNS Anycast

Os IPs Anycast utilizados são:
* <code>200.200.200.1</code> – Primário
* <code>200.200.200.2</code> – Secundário
Todo tráfego destinado a esses IPs é tratado na chain <code>DNS</code>.

<code>/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"</code>

----🛡️ Boas práticas
* Nunca permitir DNS sem <code>address-list</code>
* Separar lista de DNS de listas administrativas
* Manter comentários claros por cliente
* Revisar blocos removidos ou inativos
* Evitar liberar <code>0.0.0.0/0</code>
----📝 Observação

A <code>RESOLVE-DNS</code> '''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.

<code>/ipv6 firewall filter

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

'''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 <code>REDES_CONFIAVEIS</code> centraliza origens administrativas também no IPv6.

Todo tráfego originado dessas redes é aceito diretamente no <code>forward</code> e no <code>input</code>.

<code>/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</code>

'''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 <code>REDES_CONFIAVEIS</code> conseguem acessar serviços administrativos.

<code>/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</code>

'''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 (<code>DNS</code>).

Somente endereços presentes na address-list <code>RESOLVE-DNS</code> podem realizar consultas.

Os IPs utilizados são:

<code>2804:XXXX:2::4</code> – Primário

<code>2804:XXXX:4::5</code> – Secundário

<code>/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

</code>

'''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 ==

Firewall Servidores Mikrotik

2026-01-19T19:08:37Z

Sandino: /* 4.3 Regra de INPUT – DMZ IPv6 */

== 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.
[[Arquivo:Topologia-fw-server-mk.png|borda|semmoldura|alt=|centro]]

== 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.

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 <code>REDES_CONFIAVEIS</code> 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:
* <code>192.168.0.0/16</code>
* <code>10.0.0.0/8</code>
* <code>172.16.0.0/12</code>
* 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'''
<code>/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"</code>
----🔐 Uso com VPN

Caso exista VPN, é recomendado adicionar '''apenas a rede da VPN''', e não endereços individuais:
<code>/ip firewall address-list
add list=REDES_CONFIAVEIS address=10.99.0.0/24 comment="Rede VPN Administrativa"</code>
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 <code>REDES_CONFIAVEIS</code>:
* 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 <code>REDES_CONFIAVEIS</code> é 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.

<code>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"</code>
'''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 <code>'''forward''' e no '''input'''</code>, 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.
<code>add action=jump chain=forward src-address-list=REDES_CONFIAVEIS \
jump-target=REDES_CONFIAVEIS comment="REDES CONFIAVEIS"</code>

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

add action=accept chain=REDES_CONFIAVEIS</code>
'''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.
<code>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</code>
'''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.
<code>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</code>
'''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 <code>RESOLVE-DNS</code> 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 (<code>100.64.0.0/10</code>) 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 <code>RESOLVE-DNS</code>

<code>/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"</code>
----🔐 Regras de Firewall – DNS Anycast

Os IPs Anycast utilizados são:
* <code>200.200.200.1</code> – Primário
* <code>200.200.200.2</code> – Secundário
Todo tráfego destinado a esses IPs é tratado na chain <code>DNS</code>.

<code>/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"</code>

----🛡️ Boas práticas
* Nunca permitir DNS sem <code>address-list</code>
* Separar lista de DNS de listas administrativas
* Manter comentários claros por cliente
* Revisar blocos removidos ou inativos
* Evitar liberar <code>0.0.0.0/0</code>
----📝 Observação

A <code>RESOLVE-DNS</code> '''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.

<code>/ipv6 firewall filter

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

'''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 <code>REDES_CONFIAVEIS</code> centraliza origens administrativas também no IPv6.

Todo tráfego originado dessas redes é aceito diretamente no <code>forward</code> e no <code>input</code>.

<code>/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</code>

'''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 <code>REDES_CONFIAVEIS</code> conseguem acessar serviços administrativos.

<code>/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</code>

'''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 (<code>DNS</code>).

Somente endereços presentes na address-list <code>RESOLVE-DNS</code> podem realizar consultas.

Os IPs utilizados são:

<code>2804:XXXX:2::4</code> – Primário

<code>2804:XXXX:4::5</code> – Secundário

<code>/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=tcp src-address-list=RESOLVE-DNS
add action=accept chain=DNS dst-port=53 protocol=udp src-address-list=RESOLVE-DNS
add action=drop chain=DNS

</code>

'''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 ==

Firewall Servidores Mikrotik

2026-01-19T19:08:18Z

Sandino:

== 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.
[[Arquivo:Topologia-fw-server-mk.png|borda|semmoldura|alt=|centro]]

== 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.

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 <code>REDES_CONFIAVEIS</code> 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:
* <code>192.168.0.0/16</code>
* <code>10.0.0.0/8</code>
* <code>172.16.0.0/12</code>
* 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'''
<code>/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"</code>
----🔐 Uso com VPN

Caso exista VPN, é recomendado adicionar '''apenas a rede da VPN''', e não endereços individuais:
<code>/ip firewall address-list
add list=REDES_CONFIAVEIS address=10.99.0.0/24 comment="Rede VPN Administrativa"</code>
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 <code>REDES_CONFIAVEIS</code>:
* 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 <code>REDES_CONFIAVEIS</code> é 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.

<code>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"</code>
'''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 <code>'''forward''' e no '''input'''</code>, 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.
<code>add action=jump chain=forward src-address-list=REDES_CONFIAVEIS \
jump-target=REDES_CONFIAVEIS comment="REDES CONFIAVEIS"</code>

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

add action=accept chain=REDES_CONFIAVEIS</code>
'''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.
<code>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</code>
'''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.
<code>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</code>
'''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 <code>RESOLVE-DNS</code> 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 (<code>100.64.0.0/10</code>) 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 <code>RESOLVE-DNS</code>

<code>/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"</code>
----🔐 Regras de Firewall – DNS Anycast

Os IPs Anycast utilizados são:
* <code>200.200.200.1</code> – Primário
* <code>200.200.200.2</code> – Secundário
Todo tráfego destinado a esses IPs é tratado na chain <code>DNS</code>.

<code>/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"</code>

----🛡️ Boas práticas
* Nunca permitir DNS sem <code>address-list</code>
* Separar lista de DNS de listas administrativas
* Manter comentários claros por cliente
* Revisar blocos removidos ou inativos
* Evitar liberar <code>0.0.0.0/0</code>
----📝 Observação

A <code>RESOLVE-DNS</code> '''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.

<code>/ipv6 firewall filter

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

'''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 <code>REDES_CONFIAVEIS</code> centraliza origens administrativas também no IPv6.

Todo tráfego originado dessas redes é aceito diretamente no <code>forward</code> e no <code>input</code>.

<code>/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</code>

'''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 <code>REDES_CONFIAVEIS</code> conseguem acessar serviços administrativos.

<code>/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</code>

'''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 (<code>DNS</code>).

Somente endereços presentes na address-list <code>RESOLVE-DNS</code> podem realizar consultas.

Os IPs utilizados são:

<code>2804:XXXX:2::4</code> – Primário

<code>2804:XXXX:4::5</code> – Secundário

<code>/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=tcp src-address-list=RESOLVE-DNS
add action=accept chain=DNS dst-port=53 protocol=udp src-address-list=RESOLVE-DNS
add action=drop chain=DNS

</code>

'''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 ==

Firewall Servidores Mikrotik

2026-01-19T19:04:36Z

Sandino:

== 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.
[[Arquivo:Topologia-fw-server-mk.png|borda|semmoldura|alt=|centro]]

== 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.

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 <code>REDES_CONFIAVEIS</code> 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:
* <code>192.168.0.0/16</code>
* <code>10.0.0.0/8</code>
* <code>172.16.0.0/12</code>
* 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'''
<code>/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"</code>
----🔐 Uso com VPN

Caso exista VPN, é recomendado adicionar '''apenas a rede da VPN''', e não endereços individuais:
<code>/ip firewall address-list
add list=REDES_CONFIAVEIS address=10.99.0.0/24 comment="Rede VPN Administrativa"</code>
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 <code>REDES_CONFIAVEIS</code>:
* 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 <code>REDES_CONFIAVEIS</code> é 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.

<code>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"</code>
'''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 <code>'''forward''' e no '''input'''</code>, 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.
<code>add action=jump chain=forward src-address-list=REDES_CONFIAVEIS \
jump-target=REDES_CONFIAVEIS comment="REDES CONFIAVEIS"</code>

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

add action=accept chain=REDES_CONFIAVEIS</code>
'''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.
<code>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</code>
'''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.
<code>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</code>
'''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 <code>RESOLVE-DNS</code> 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 (<code>100.64.0.0/10</code>) 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 <code>RESOLVE-DNS</code>

<code>/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"</code>
----🔐 Regras de Firewall – DNS Anycast

Os IPs Anycast utilizados são:
* <code>200.200.200.1</code> – Primário
* <code>200.200.200.2</code> – Secundário
Todo tráfego destinado a esses IPs é tratado na chain <code>DNS</code>.

<code>/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"</code>

----🛡️ Boas práticas
* Nunca permitir DNS sem <code>address-list</code>
* Separar lista de DNS de listas administrativas
* Manter comentários claros por cliente
* Revisar blocos removidos ou inativos
* Evitar liberar <code>0.0.0.0/0</code>
----📝 Observação

A <code>RESOLVE-DNS</code> '''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.

<code>/ipv6 firewall filter

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

'''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 <code>REDES_CONFIAVEIS</code> centraliza origens administrativas também no IPv6.

Todo tráfego originado dessas redes é aceito diretamente no <code>forward</code> e no <code>input</code>.

<code>/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</code>

'''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 <code>REDES_CONFIAVEIS</code> conseguem acessar serviços administrativos.

<code>/ipv6 firewall filter

add chain=input dst-address=2804:8dcc::7/128
action=jump jump-target=CE-DMZ comment="CE-DMZ INPUT"

add chain=input dst-address=2804:8dcc:1::1/128
action=jump jump-target=CE-DMZ comment="CE-DMZ INPUT"

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

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

add chain=CE-DMZ action=drop</code>

'''Objetivo'''
* Proteger o acesso administrativo IPv6

* Restringir por origem confiável

* Bloquear tentativas não autorizadas

=== 4.4 Aplicação de exemplo – DNS Anycast IPv6 ===

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

Somente endereços presentes na address-list <code>RESOLVE-DNS</code> podem realizar consultas.

Os IPs Anycast utilizados são:

<code>2804:XXXX:2::4</code> – Primário

<code>2804:XXXX::5</code> – Secundário

<code>/ipv6 firewall filter

add chain=forward dst-address=2804:8dcc:1::4/128
action=jump jump-target=DNS comment="GODNS PRIMARIO GERENCIA"

add chain=forward dst-address=2804:8dcc:1::5/128
action=jump jump-target=DNS comment="GODNS SECUNDARIO GERENCIA"

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

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

add chain=DNS protocol=icmp action=accept

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

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

add chain=DNS action=drop</code>

'''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 ==

Firewall Servidores Mikrotik

2026-01-19T18:53:08Z

Sandino:

== 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.
[[Arquivo:Topologia-fw-server-mk.png|borda|semmoldura|alt=|centro]]

== 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.

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 <code>REDES_CONFIAVEIS</code> 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:
* <code>192.168.0.0/16</code>
* <code>10.0.0.0/8</code>
* <code>172.16.0.0/12</code>
* 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'''
<code>/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"</code>
----🔐 Uso com VPN

Caso exista VPN, é recomendado adicionar '''apenas a rede da VPN''', e não endereços individuais:
<code>/ip firewall address-list
add list=REDES_CONFIAVEIS address=10.99.0.0/24 comment="Rede VPN Administrativa"</code>
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 <code>REDES_CONFIAVEIS</code>:
* 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 <code>REDES_CONFIAVEIS</code> é 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.

<code>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"</code>
'''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 <code>'''forward''' e no '''input'''</code>, 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.
<code>add action=jump chain=forward src-address-list=REDES_CONFIAVEIS \
jump-target=REDES_CONFIAVEIS comment="REDES CONFIAVEIS"</code>

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

add action=accept chain=REDES_CONFIAVEIS</code>
'''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.
<code>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</code>
'''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.
<code>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</code>
'''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 <code>RESOLVE-DNS</code> 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 (<code>100.64.0.0/10</code>) 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 <code>RESOLVE-DNS</code>

<code>/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"</code>
----🔐 Regras de Firewall – DNS Anycast

Os IPs Anycast utilizados são:
* <code>200.200.200.1</code> – Primário
* <code>200.200.200.2</code> – Secundário
Todo tráfego destinado a esses IPs é tratado na chain <code>DNS</code>.

<code>/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"</code>

----🛡️ Boas práticas
* Nunca permitir DNS sem <code>address-list</code>
* Separar lista de DNS de listas administrativas
* Manter comentários claros por cliente
* Revisar blocos removidos ou inativos
* Evitar liberar <code>0.0.0.0/0</code>
----📝 Observação

A <code>RESOLVE-DNS</code> '''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

Firewall Servidores Mikrotik

2026-01-19T18:52:19Z

Sandino:

== 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.
[[Arquivo:Topologia-fw-server-mk.png|borda|semmoldura|alt=|centro]]

== 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.

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 <code>REDES_CONFIAVEIS</code> 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:
* <code>192.168.0.0/16</code>
* <code>10.0.0.0/8</code>
* <code>172.16.0.0/12</code>
* 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'''
<code>/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"</code>
----🔐 Uso com VPN

Caso exista VPN, é recomendado adicionar '''apenas a rede da VPN''', e não endereços individuais:
<code>/ip firewall address-list
add list=REDES_CONFIAVEIS address=10.99.0.0/24 comment="Rede VPN Administrativa"</code>
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 <code>REDES_CONFIAVEIS</code>:
* 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 <code>REDES_CONFIAVEIS</code> é 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.

<code>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"</code>
'''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 <code>'''forward''' e no '''input'''</code>, 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.
<code>add action=jump chain=forward src-address-list=REDES_CONFIAVEIS \
jump-target=REDES_CONFIAVEIS comment="REDES CONFIAVEIS"</code>

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

add action=accept chain=REDES_CONFIAVEIS</code>
'''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.
<code>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</code>
'''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.
<code>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</code>
'''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 <code>RESOLVE-DNS</code> 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 (<code>100.64.0.0/10</code>) 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 <code>RESOLVE-DNS</code>

<code>/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"</code>
----🔐 Regras de Firewall – DNS Anycast

Os IPs Anycast utilizados são:
* <code>200.200.200.1</code> – Primário
* <code>200.200.200.2</code> – Secundário
Todo tráfego destinado a esses IPs é tratado na chain <code>DNS</code>.

<code>/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"</code>

----🛡️ Boas práticas
* Nunca permitir DNS sem <code>address-list</code>
* Separar lista de DNS de listas administrativas
* Manter comentários claros por cliente
* Revisar blocos removidos ou inativos
* Evitar liberar <code>0.0.0.0/0</code>
----📝 Observação

A <code>RESOLVE-DNS</code> '''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

Firewall Servidores Mikrotik

2026-01-19T18:51:43Z

Sandino:

== 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.
[[Arquivo:Topologia-fw-server-mk.png|borda|semmoldura|alt=|centro]]

== 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.

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 <code>REDES_CONFIAVEIS</code> 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:
* <code>192.168.0.0/16</code>
* <code>10.0.0.0/8</code>
* <code>172.16.0.0/12</code>
* 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'''
<code>/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"</code>
----🔐 Uso com VPN

Caso exista VPN, é recomendado adicionar '''apenas a rede da VPN''', e não endereços individuais:
<code>/ip firewall address-list
add list=REDES_CONFIAVEIS address=10.99.0.0/24 comment="Rede VPN Administrativa"</code>
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 <code>REDES_CONFIAVEIS</code>:
* 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 <code>REDES_CONFIAVEIS</code> é 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.

<code>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"</code>
'''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 <code>'''forward''' e no '''input'''</code>, 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.
<code>add action=jump chain=forward src-address-list=REDES_CONFIAVEIS \
jump-target=REDES_CONFIAVEIS comment="REDES CONFIAVEIS"</code>

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

add action=accept chain=REDES_CONFIAVEIS</code>
'''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.
<code>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</code>
'''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.
<code>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</code>
'''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 <code>RESOLVE-DNS</code> 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 (<code>100.64.0.0/10</code>) 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 <code>RESOLVE-DNS</code>

<code>/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"</code>
----🔐 Regras de Firewall – DNS Anycast

Os IPs Anycast utilizados são:
* <code>200.200.200.1</code> – Primário
* <code>200.200.200.2</code> – Secundário
Todo tráfego destinado a esses IPs é tratado na chain <code>DNS</code>.

<code>/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"</code>

----🛡️ Boas práticas
* Nunca permitir DNS sem <code>address-list</code>
* Separar lista de DNS de listas administrativas
* Manter comentários claros por cliente
* Revisar blocos removidos ou inativos
* Evitar liberar <code>0.0.0.0/0</code>
----📝 Observação

A <code>RESOLVE-DNS</code> '''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

Firewall Servidores Mikrotik

2026-01-19T18:51:03Z

Sandino:

== 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.
[[Arquivo:Topologia-fw-server-mk.png|borda|semmoldura|alt=|centro]]

== 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.

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 <code>REDES_CONFIAVEIS</code> 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:
* <code>192.168.0.0/16</code>
* <code>10.0.0.0/8</code>
* <code>172.16.0.0/12</code>
* 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'''
<code>/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"</code>
----🔐 Uso com VPN

Caso exista VPN, é recomendado adicionar '''apenas a rede da VPN''', e não endereços individuais:
<code>/ip firewall address-list
add list=REDES_CONFIAVEIS address=10.99.0.0/24 comment="Rede VPN Administrativa"</code>
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 <code>REDES_CONFIAVEIS</code>:
* 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 <code>REDES_CONFIAVEIS</code> é 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.

<code>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"</code>
'''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 <code>'''forward''' e no '''input'''</code>, 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.
<code>add action=jump chain=forward src-address-list=REDES_CONFIAVEIS \
jump-target=REDES_CONFIAVEIS comment="REDES CONFIAVEIS"</code>

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

add action=accept chain=REDES_CONFIAVEIS</code>
'''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.
<code>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</code>
'''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.
<code>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</code>
'''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 <code>RESOLVE-DNS</code> 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 (<code>100.64.0.0/10</code>) 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 <code>RESOLVE-DNS</code>

/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:
* <code>200.200.200.1</code> – Primário
* <code>200.200.200.2</code> – Secundário
Todo tráfego destinado a esses IPs é tratado na chain <code>DNS</code>.

<code>
/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"
</code>
----🛡️ Boas práticas
* Nunca permitir DNS sem <code>address-list</code>
* Separar lista de DNS de listas administrativas
* Manter comentários claros por cliente
* Revisar blocos removidos ou inativos
* Evitar liberar <code>0.0.0.0/0</code>
----📝 Observação

A <code>RESOLVE-DNS</code> '''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

Firewall Servidores Mikrotik

2026-01-19T18:50:31Z

Sandino:

== 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.
[[Arquivo:Topologia-fw-server-mk.png|borda|semmoldura|alt=|centro]]

== 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.

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 <code>REDES_CONFIAVEIS</code> 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:
* <code>192.168.0.0/16</code>
* <code>10.0.0.0/8</code>
* <code>172.16.0.0/12</code>
* 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'''
<code>/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"</code>
----🔐 Uso com VPN

Caso exista VPN, é recomendado adicionar '''apenas a rede da VPN''', e não endereços individuais:
<code>/ip firewall address-list
add list=REDES_CONFIAVEIS address=10.99.0.0/24 comment="Rede VPN Administrativa"</code>
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 <code>REDES_CONFIAVEIS</code>:
* 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 <code>REDES_CONFIAVEIS</code> é 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.

<code>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"</code>
'''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 <code>'''forward''' e no '''input'''</code>, 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.
<code>add action=jump chain=forward src-address-list=REDES_CONFIAVEIS \
jump-target=REDES_CONFIAVEIS comment="REDES CONFIAVEIS"</code>

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

add action=accept chain=REDES_CONFIAVEIS</code>
'''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.
<code>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</code>
'''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.
<code>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</code>
'''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 <code>RESOLVE-DNS</code> 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 (<code>100.64.0.0/10</code>) 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 <code>RESOLVE-DNS</code>

/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:
* <code>200.200.200.1</code> – Primário
* <code>200.200.200.2</code> – Secundário
Todo tráfego destinado a esses IPs é tratado na chain <code>DNS</code>.

/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 <code>address-list</code>
* Separar lista de DNS de listas administrativas
* Manter comentários claros por cliente
* Revisar blocos removidos ou inativos
* Evitar liberar <code>0.0.0.0/0</code>
----📝 Observação

A <code>RESOLVE-DNS</code> '''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

Firewall Servidores Mikrotik

2026-01-19T18:49:56Z

Sandino:

== 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.
[[Arquivo:Topologia-fw-server-mk.png|borda|esquerda|semmoldura]]

== 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.

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 <code>REDES_CONFIAVEIS</code> 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:
* <code>192.168.0.0/16</code>
* <code>10.0.0.0/8</code>
* <code>172.16.0.0/12</code>
* 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'''
<code>/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"</code>
----🔐 Uso com VPN

Caso exista VPN, é recomendado adicionar '''apenas a rede da VPN''', e não endereços individuais:
<code>/ip firewall address-list
add list=REDES_CONFIAVEIS address=10.99.0.0/24 comment="Rede VPN Administrativa"</code>
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 <code>REDES_CONFIAVEIS</code>:
* 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 <code>REDES_CONFIAVEIS</code> é 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.

<code>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"</code>
'''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 <code>'''forward''' e no '''input'''</code>, 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.
<code>add action=jump chain=forward src-address-list=REDES_CONFIAVEIS \
jump-target=REDES_CONFIAVEIS comment="REDES CONFIAVEIS"</code>

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

add action=accept chain=REDES_CONFIAVEIS</code>
'''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.
<code>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</code>
'''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.
<code>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</code>
'''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 <code>RESOLVE-DNS</code> 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 (<code>100.64.0.0/10</code>) 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 <code>RESOLVE-DNS</code>

/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:
* <code>200.200.200.1</code> – Primário
* <code>200.200.200.2</code> – Secundário
Todo tráfego destinado a esses IPs é tratado na chain <code>DNS</code>.

/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 <code>address-list</code>
* Separar lista de DNS de listas administrativas
* Manter comentários claros por cliente
* Revisar blocos removidos ou inativos
* Evitar liberar <code>0.0.0.0/0</code>
----📝 Observação

A <code>RESOLVE-DNS</code> '''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

Firewall Servidores Mikrotik

2026-01-19T18:49:09Z

Sandino:

Firewall Servidores Mikrotik

2026-01-19T18:48:25Z

Sandino:

Firewall Servidores Mikrotik

2026-01-19T18:48:07Z

Sandino:

Firewall Servidores Mikrotik

2026-01-19T18:46:30Z

Sandino:

=== 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.
[[Arquivo:Topologia-fw-server-mk.png|borda|esquerda|semmoldura]]

=== 3. Regras de Firewall IPv4 ===
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.

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 <code>REDES_CONFIAVEIS</code> 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:
* <code>192.168.0.0/16</code>
* <code>10.0.0.0/8</code>
* <code>172.16.0.0/12</code>
* 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 ===
<code>/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"</code>
----🔐 Uso com VPN

Caso exista VPN, é recomendado adicionar '''apenas a rede da VPN''', e não endereços individuais:
<code>/ip firewall address-list
add list=REDES_CONFIAVEIS address=10.99.0.0/24 comment="Rede VPN Administrativa"</code>
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 <code>REDES_CONFIAVEIS</code>:
* 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 <code>REDES_CONFIAVEIS</code> é 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.

<code>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"</code>

=== 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 <code>'''forward''' e no '''input'''</code>, 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.
<code>add action=jump chain=forward src-address-list=REDES_CONFIAVEIS \
jump-target=REDES_CONFIAVEIS comment="REDES CONFIAVEIS"</code>

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

add action=accept chain=REDES_CONFIAVEIS</code>

=== 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.
<code>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</code>

=== 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.
<code>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</code>

=== 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 <code>RESOLVE-DNS</code> 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 (<code>100.64.0.0/10</code>) 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 <code>RESOLVE-DNS</code>

/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:
* <code>200.200.200.1</code> – Primário
* <code>200.200.200.2</code> – Secundário
Todo tráfego destinado a esses IPs é tratado na chain <code>DNS</code>.

/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 <code>address-list</code>
* Separar lista de DNS de listas administrativas
* Manter comentários claros por cliente
* Revisar blocos removidos ou inativos
* Evitar liberar <code>0.0.0.0/0</code>
----📝 Observação

A <code>RESOLVE-DNS</code> '''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

Firewall Servidores Mikrotik

2026-01-19T18:45:08Z

Sandino: Criou página com '=== 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 f...'

=== 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.
[[Arquivo:Topologia-fw-server-mk.png|borda|esquerda|semmoldura]]

=== 3. Regras de Firewall IPv4 ===
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.

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 <code>REDES_CONFIAVEIS</code> 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:
* <code>192.168.0.0/16</code>
* <code>10.0.0.0/8</code>
* <code>172.16.0.0/12</code>
* 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 ===
<code>/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"</code>
----

== 🔐 Uso com VPN ==
Caso exista VPN, é recomendado adicionar '''apenas a rede da VPN''', e não endereços individuais:
<code>/ip firewall address-list
add list=REDES_CONFIAVEIS address=10.99.0.0/24 comment="Rede VPN Administrativa"</code>
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 <code>REDES_CONFIAVEIS</code>:
* 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 <code>REDES_CONFIAVEIS</code> é 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.

<code>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"</code>

=== 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 <code>'''forward''' e no '''input'''</code>, 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.
<code>add action=jump chain=forward src-address-list=REDES_CONFIAVEIS \
jump-target=REDES_CONFIAVEIS comment="REDES CONFIAVEIS"</code>

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

add action=accept chain=REDES_CONFIAVEIS</code>

=== 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.
<code>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</code>

=== 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.
<code>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</code>

=== 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 <code>RESOLVE-DNS</code> 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 (<code>100.64.0.0/10</code>) 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 <code>RESOLVE-DNS</code> ==
/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:
* <code>200.200.200.1</code> – Primário
* <code>200.200.200.2</code> – Secundário
Todo tráfego destinado a esses IPs é tratado na chain <code>DNS</code>.

/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 <code>address-list</code>
* Separar lista de DNS de listas administrativas
* Manter comentários claros por cliente
* Revisar blocos removidos ou inativos
* Evitar liberar <code>0.0.0.0/0</code>
----

== 📝 Observação ==
A <code>RESOLVE-DNS</code> '''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

Arquivo:Topologia-fw-server-mk.png

2026-01-19T17:48:47Z

Sandino:

Exemplo