Mudanças entre as edições de "Firewall Servidores Mikrotik"
Ir para navegação
Ir para pesquisar
| (14 revisões intermediárias pelo mesmo usuário não estão sendo mostradas) | |||
| Linha 1: | Linha 1: | ||
== 1. Introduçã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. | 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 == | == 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. | + | |
| + | 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. | O fluxo do trafego é pensado em aplicações que necessitam estar publicadas para internet ou somente para endereços específicos, então o trafego no geral vem da WAN do mikrotik e assim utilizando /'''ip firewall filter''' irá realizar filtros individuais para cada servidor sendo FORWARD pois o tráfego passa por ele e de INPUT para endereços públicos no próprio roteador, por exemplo endereço de acesso do equipamento. | ||
| − | |||
| − | === 3. Regras de Firewall IPv4 === | + | [[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. | 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. | 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 | + | |
| + | ---- | ||
| + | |||
| + | 📌 '''Conceito''' | ||
A <code>REDES_CONFIAVEIS</code> deve conter '''apenas origens confiáveis''', pois qualquer endereço incluído nela poderá: | A <code>REDES_CONFIAVEIS</code> deve conter '''apenas origens confiáveis''', pois qualquer endereço incluído nela poderá: | ||
| Linha 18: | Linha 27: | ||
* Ignorar regras específicas de servidores | * Ignorar regras específicas de servidores | ||
* Ter prioridade no fluxo do firewall | * Ter prioridade no fluxo do firewall | ||
| + | |||
⚠️ '''Nunca adicione IPs públicos ou redes desconhecidas''' a esta lista. | ⚠️ '''Nunca adicione IPs públicos ou redes desconhecidas''' a esta lista. | ||
| − | ----🧩 Tipos de endereços recomendados | + | |
| + | ---- | ||
| + | |||
| + | 🧩 '''Tipos de endereços recomendados''' | ||
Normalmente, a lista pode conter: | Normalmente, a lista pode conter: | ||
| Linha 27: | Linha 40: | ||
* Jump servers | * Jump servers | ||
* Hosts de administração | * Hosts de administração | ||
| + | |||
Exemplos comuns: | Exemplos comuns: | ||
* <code>192.168.0.0/16</code> | * <code>192.168.0.0/16</code> | ||
| Linha 33: | Linha 47: | ||
* IP público fixo do escritório | * IP público fixo do escritório | ||
* IP de saída da VPN | * 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 | + | *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''' | '''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" | |
| − | ----🔐 Uso com VPN | + | 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: | 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. | Isso facilita manutenção e crescimento futuro. | ||
| − | ----🛡️ Boas práticas | + | |
| + | ---- | ||
| + | |||
| + | 🛡️ '''Boas práticas''' | ||
* Utilize '''comentários claros''' em cada entrada | * Utilize '''comentários claros''' em cada entrada | ||
* Revise periodicamente a lista | * Revise periodicamente a lista | ||
* Remova IPs temporários após uso | * Remova IPs temporários após uso | ||
* Evite listas muito amplas sem necessidade | * Evite listas muito amplas sem necessidade | ||
| − | ----⚠️ Impacto no Firewall | + | |
| + | ---- | ||
| + | |||
| + | ⚠️ '''Impacto no Firewall''' | ||
Qualquer tráfego originado de endereços presentes na <code>REDES_CONFIAVEIS</code>: | Qualquer tráfego originado de endereços presentes na <code>REDES_CONFIAVEIS</code>: | ||
| Linha 58: | Linha 89: | ||
* Terá acesso aos serviços administrativos | * Terá acesso aos serviços administrativos | ||
* Não passará pelas regras específicas de servidores | * Não passará pelas regras específicas de servidores | ||
| + | |||
Por isso, esta lista deve ser tratada como '''zona de alta confiança'''. | Por isso, esta lista deve ser tratada como '''zona de alta confiança'''. | ||
| − | ----📝 Observação Final | + | |
| + | ---- | ||
| + | |||
| + | 📝 '''Observação Final''' | ||
A correta definição da <code>REDES_CONFIAVEIS</code> é fundamental para a segurança do ambiente. | A correta definição da <code>REDES_CONFIAVEIS</code> é fundamental para a segurança do ambiente. | ||
| Linha 68: | Linha 103: | ||
=== 3.2 Conexões estabelecidas === | === 3.2 Conexões estabelecidas === | ||
| + | |||
Estas regras devem estar sempre no início do firewall, garantindo o funcionamento correto das sessões já criadas. | 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''' | '''Objetivo''' | ||
* Manter conexões ativas | * Manter conexões ativas | ||
| Linha 83: | Linha 118: | ||
=== 3.3 Conexões de redes confiáveis === | === 3.3 Conexões de redes confiáveis === | ||
| + | |||
Este bloco centraliza o tratamento de redes internas, VPNs ou endereços administrativos. | 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. | + | 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 | * Facilitar administração | ||
* Evitar repetição de regras | * Evitar repetição de regras | ||
| Linha 100: | Linha 136: | ||
=== 3.4 Regra para INPUT === | === 3.4 Regra para INPUT === | ||
| + | |||
Estas regras controlam o acesso ao próprio roteador ou a endereços de gestão publicados. | 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 | + | 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 | * Proteger serviços administrativos | ||
* Restringir acesso por origem | * Restringir acesso por origem | ||
| Linha 124: | Linha 158: | ||
=== 3.5 Aplicação de exemplo (ZABBIX/GRAFANA) === | === 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. | 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. | 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 | * Limitar exposição do servidor | ||
* Bloquear portas não utilizadas | * Bloquear portas não utilizadas | ||
* Manter o controle isolado por aplicação | * 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. | Somente endereços presentes na <code>RESOLVE-DNS</code> conseguem consultar o DNS. | ||
| Linha 150: | Linha 187: | ||
* Blocos IPv4 públicos dos clientes | * 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. | * 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 | /ip firewall address-list | ||
| − | |||
add list=RESOLVE-DNS address=100.64.0.0/10 comment="CGNAT clientes" | 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: | Os IPs Anycast utilizados são: | ||
* <code>200.200.200.1</code> – Primário | * <code>200.200.200.1</code> – Primário | ||
* <code>200.200.200.2</code> – Secundário | * <code>200.200.200.2</code> – Secundário | ||
| + | |||
Todo tráfego destinado a esses IPs é tratado na chain <code>DNS</code>. | Todo tráfego destinado a esses IPs é tratado na chain <code>DNS</code>. | ||
| + | <pre> | ||
/ip firewall filter | /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.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=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=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 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> | * Nunca permitir DNS sem <code>address-list</code> | ||
* Separar lista de DNS de listas administrativas | * Separar lista de DNS de listas administrativas | ||
| Linha 184: | Linha 226: | ||
* Revisar blocos removidos ou inativos | * Revisar blocos removidos ou inativos | ||
* Evitar liberar <code>0.0.0.0/0</code> | * Evitar liberar <code>0.0.0.0/0</code> | ||
| − | ----📝 Observação | + | |
| + | ---- | ||
| + | |||
| + | 📝 '''Observação''' | ||
A <code>RESOLVE-DNS</code> '''autoriza apenas resolução de nomes''', não acesso administrativo. | A <code>RESOLVE-DNS</code> '''autoriza apenas resolução de nomes''', não acesso administrativo. | ||
| Linha 192: | Linha 237: | ||
* Controle por cliente | * Controle por cliente | ||
* Segurança contra abuso e amplificação | * 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 | ||
Edição atual tal como às 16h25min de 19 de janeiro de 2026
1. Introdução
O objetivo desse documento é descrever um padrão de firewall para proteção de servidores (aplicações) em roteadores mikrotik, baseado em /ip firewall filter, adotando um modelo mais simples de gerenciar suas regras. O conceito principal é negar por aplicação, ou seja, cada servidor (aplicação) possui sua própria chain e apenas os serviços necessários são abertos, utilizando um drop para cada aplicação individual.
2. Conceito do Firewall por CHAIN
Por padrão do mikrotik o firewall dele é ACCEPT, ou seja, ele não irá negar o trafego por padrão como normalmente os firewalls no mercado realizam, sendo assim precisamos realizar uma regra de DROP, o mais comum é fazer um DROP GERAL no final, com este tipo de configuração o DROP afeta o ambiente completo, sendo muito comum acabar o DROP ser desabilitado em momento de problema e nunca mais ser habilitado novamente (é raro mas acontece sempre kkkk), assim foi pensado em realizar o firewall por CHAIN, ou seja, cada servidor (aplicação) possui seu firewall independente, ou seja, o que é feito na chain de um servidor não impacta no outro, cada servidor possui seu drop, isolando as regras e deixando mais facil a gerencia com ambiente com bastante aplicações, para isto é utilizado JUMP e CHAIN, basicamente é criado uma CHAIN com nome da aplicação onde tudo que for em destino ao IP da aplicação desejada irá redirecionar para aquela CHAIN onde ela irá liberar as portas necessárias e o restante irá bloquear.
O fluxo do trafego é pensado em aplicações que necessitam estar publicadas para internet ou somente para endereços específicos, então o trafego no geral vem da WAN do mikrotik e assim utilizando /ip firewall filter irá realizar filtros individuais para cada servidor sendo FORWARD pois o tráfego passa por ele e de INPUT para endereços públicos no próprio roteador, por exemplo endereço de acesso do equipamento.
3. Regras de Firewall IPv4
3.1 Address list Redes Confiaveis
A address-list REDES_CONFIAVEIS é utilizada para identificar redes e endereços IP que possuem permissão administrativa, como acessos de NOC, VPN, jump server ou redes internas confiáveis.
Todas as regras de gestão e administração do firewall fazem referência a esta lista, evitando a necessidade de repetir IPs diretamente nas regras.
📌 Conceito
A REDES_CONFIAVEIS deve conter apenas origens confiáveis, pois qualquer endereço incluído nela poderá:
- Acessar serviços administrativos
- Ignorar regras específicas de servidores
- Ter prioridade no fluxo do firewall
⚠️ Nunca adicione IPs públicos ou redes desconhecidas a esta lista.
🧩 Tipos de endereços recomendados
Normalmente, a lista pode conter:
- Redes internas (LAN / DC)
- Endereços de VPN
- IPs fixos do NOC
- Jump servers
- Hosts de administração
Exemplos comuns:
192.168.0.0/1610.0.0.0/8172.16.0.0/12- IP público fixo do escritório
- IP de saída da VPN
- Evite utilizar redes muito amplas, tente deixar o mais restrito possível, evite usar a RFC1918 inteira.*
🔧 Criação da Address-List
Exemplo básico
/ip firewall address-list add list=REDES_CONFIAVEIS address=192.168.0.0/16 comment="Rede interna" add list=REDES_CONFIAVEIS address=10.0.0.0/8 comment="Rede privada" add list=REDES_CONFIAVEIS address=200.200.200.10 comment="IP fixo NOC"
🔐 Uso com VPN
Caso exista VPN, é recomendado adicionar apenas a rede da VPN, e não endereços individuais:
/ip firewall address-list add list=REDES_CONFIAVEIS address=10.99.0.0/24 comment="Rede VPN Administrativa"
Isso facilita manutenção e crescimento futuro.
🛡️ Boas práticas
- Utilize comentários claros em cada entrada
- Revise periodicamente a lista
- Remova IPs temporários após uso
- Evite listas muito amplas sem necessidade
⚠️ Impacto no Firewall
Qualquer tráfego originado de endereços presentes na REDES_CONFIAVEIS:
- Será aceito diretamente nas regras de forward e no input
- Terá acesso aos serviços administrativos
- Não passará pelas regras específicas de servidores
Por isso, esta lista deve ser tratada como zona de alta confiança.
📝 Observação Final
A correta definição da REDES_CONFIAVEIS é fundamental para a segurança do ambiente.
Um erro nesta lista pode resultar em exposição administrativa indevida.
Sempre valide os endereços antes de adicioná-los.
3.2 Conexões estabelecidas
Estas regras devem estar sempre no início do firewall, garantindo o funcionamento correto das sessões já criadas.
/ip firewall filter add chain=input connection-state=established,related action=accept comment="ACEITA CONEXÕES ESTABELECIDAS" add chain=forward connection-state=established,related action=accept comment="ACEITA CONEXÕES ESTABELECIDAS"
Objetivo
- Manter conexões ativas
- Evitar reprocessamento de pacotes
- Garantir estabilidade dos serviços
3.3 Conexões de redes confiáveis
Este bloco centraliza o tratamento de redes internas, VPNs ou endereços administrativos.
Todo tráfego originado dessas redes é aceito diretamente no forward e no input, sem passar pelas regras específicas de servidores, somente tenha cuidado com o que libera, evite liberar por exemplo seu prefixo completo de IPv4, libere IPs específicos, como /32, a partir do momento que você libera o seu bloco completo seu usuário final, uma maquina comprometida dentro da infraestrutura pode acessar aquela aplicação que muita das vezes pode não ser o necessário.
/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
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.
/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
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.
/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
Objetivo
- Limitar exposição do servidor
- Bloquear portas não utilizadas
- Manter o controle isolado por aplicação
- Desta forma somente liberamos a porta 80,443 e 3000 para internet (so libere para internet se realmente precisar acessar externo e não possa acessar via VPN por exemplo), evite o máximo aplicações publicas caso não existe 100% da necessidade, desta forma somente as portas necessárias ficariam abertas, por exemplo o SSH estaria fechado para todos neste caso, exceto para REDES_CONFIAVEIS*
3.6. Aplicação de exemplo (DNS)
Somente endereços presentes na RESOLVE-DNS conseguem consultar o DNS.
Qualquer outra origem é descartada, evitando DNS aberto e abusos.
A lista normalmente contém:
- Blocos IPv4 públicos dos clientes
- Rede de CGNAT (
100.64.0.0/10) por padrão tente fazer as requisições para seu servidor de DNS não passar por CGNAT, com exemplo com exceção no PBR.
🔧 Address-List RESOLVE-DNS
/ip firewall address-list add list=RESOLVE-DNS address=100.64.0.0/10 comment="CGNAT clientes" add list=RESOLVE-DNS address=187.45.120.0/24 comment="Cliente ISP A" add list=RESOLVE-DNS address=200.200.200.0/22 comment="Meu bloco"
🔐 Regras de Firewall – DNS Anycast
Os IPs Anycast utilizados são:
200.200.200.1– Primário200.200.200.2– Secundário
Todo tráfego destinado a esses IPs é tratado na chain DNS.
/ip firewall filter add chain=forward dst-address=200.200.200.1 action=jump jump-target=DNS comment="DNS PRIMARIO" add chain=forward dst-address=200.200.200.2 action=jump jump-target=DNS comment="DNS SECUNDARIO" add chain=DNS protocol=icmp action=accept comment="ICMP DNS" add chain=DNS protocol=udp dst-port=53 src-address-list=RESOLVE-DNS action=accept comment="DNS UDP autorizado" add chain=DNS action=drop comment="DROP DNS NAO AUTORIZADO"
🛡️ Boas práticas
- Nunca permitir DNS sem
address-list - Separar lista de DNS de listas administrativas
- Manter comentários claros por cliente
- Revisar blocos removidos ou inativos
- Evitar liberar
0.0.0.0/0
📝 Observação
A RESOLVE-DNS autoriza apenas resolução de nomes, não acesso administrativo.
Este modelo garante:
- DNS fechado
- Controle por cliente
- Segurança contra abuso e amplificação
4. Regras de Firewall IPv6
O firewall IPv6 segue exatamente o mesmo conceito do IPv4, utilizando isolamento por aplicação através de chains dedicadas, evitando drops globais e mantendo o controle individual por serviço.
A principal diferença é apenas o uso de /ipv6 firewall filter e endereços IPv6 /128 para hosts, sempre tenha firewall IPv6 para as suas aplicações também.
4.1 Conexões estabelecidas
Estas regras devem ficar no início do firewall IPv6, garantindo o funcionamento correto das conexões já existentes.
/ipv6 firewall filter add chain=forward connection-state=established,related action=accept comment="CONEXOES ESTABELECIDAS/RELACIONADAS"
Objetivo
- Manter sessões ativas
- Evitar reprocessamento desnecessário
- Garantir estabilidade dos serviços IPv6
4.2 Redes Confiáveis (IPv6)
Assim como no IPv4, a address-list REDES_CONFIAVEIS centraliza origens administrativas também no IPv6.
Todo tráfego originado dessas redes é aceito diretamente no forward e no input.
/ipv6 firewall filter add action=jump chain=forward src-address-list=REDES_CONFIAVEIS jump-target=REDES_CONFIAVEIS comment="REDES CONFIAVEIS" add action=jump chain=input src-address-list=REDES_CONFIAVEIS jump-target=REDES_CONFIAVEIS comment="REDES CONFIAVEIS" add action=accept chain=REDES_CONFIAVEIS
Objetivo
- Centralizar acessos administrativos
- Evitar repetição de regras
- Facilitar manutenção do firewall IPv6
⚠️ *Evite adicionar prefixos IPv6 muito amplos (/32, /29). Sempre que possível, utilize o menor tamanho de prefixo possível ou prefixos bem definidos.*
4.3 Regra de INPUT – DMZ IPv6
Estas regras controlam o acesso a endereços IPv6 de gestão publicados no próprio roteador.
Somente origens presentes na REDES_CONFIAVEIS conseguem acessar serviços administrativos.
/ipv6 firewall filter add action=jump chain=input comment=CE-DMZ dst-address=2804:XXXX:1::1/128 jump-target=CE-DMZ add action=accept chain=CE-DMZ dst-port=22,8291 protocol=tcp src-address-list=REDES_CONFIAVEIS add action=drop chain=CE-DMZ
Objetivo
- Proteger o acesso administrativo IPv6
- Restringir por origem confiável
- Bloquear tentativas não autorizadas
4.4 Aplicação de exemplo – DNS IPv6
Neste cenário, os servidores DNS IPv6 são protegidos por uma chain dedicada (DNS).
Somente endereços presentes na address-list RESOLVE-DNS podem realizar consultas.
Os IPs utilizados são:
2804:XXXX:2::4– Primário2804:XXXX:4::5– Secundário
/ipv6 firewall filter add action=jump chain=forward comment="DNS PRIMARIO" dst-address=2804:XXXX:2::4/128 jump-target=DNS add action=jump chain=forward comment="DNS SECUNDARIO" dst-address=2804:XXXX:2::5/128 jump-target=DNS add action=accept chain=DNS protocol=icmp add action=accept chain=DNS dst-port=53 protocol=udp src-address-list=RESOLVE-DNS add action=drop chain=DNS
Objetivo
- Evitar DNS aberto em IPv6
- Controlar resolução por origem
- Prevenir abuso e amplificação
📝 Observação Final (IPv6)
O firewall IPv6 não deve ser tratado como opcional. Todo serviço publicado em IPv4 caso tenha IPv6 também necessita de firewall, visto que o IPv6 é possível disponibilizar acesso via ssh, amplificações e etc, IPv6 é o protocolo padrão da internet!
5. Conclusão
Este padrão de firewall por chain permite facilitar a gerencia das regras e garantir uma gerencia facilitada, evitando o problema de desabilitar o DROP geral de firewall que sempre ocorre em momentos de problema e acaba ficando dias sem estar habilitado ou até mesmo nunca mais habilitado novamente. A ideia é realizar um padrão de firewall onde garantimos segurança e gerencia facilitada.
6. Sobre mim
Este é meu primeiro publicado, em caso de qualquer erro ou sugestão de melhoria aceito com gratidão, caso tenha duvida e queira tirar duvidas sobre o firewall pode entrar em contato comigo:
Telefone (whatsapp): 19 987601686
e-mail: vitor.sandino@version2.com.br