Qual é a diferença entre Firewall Allow e Denied no MikroTik RouterOS?

Introdução

Este artigo explica, de forma prática e técnica, a diferença entre regras que aceitam tráfego (Allow) e as que o negam (Denied) no firewall do MikroTik RouterOS. Abordamos também o impacto no connection tracking, a importância da ordem das regras e apresentamos exemplos de configuração usando os comandos nativos.

Conceitos básicos

Ações principais no firewall

• accept (Allow): permite que o pacote prossiga; quando uma regra com action=accept corresponde, o pacote é autorizado e não continua avaliando outras regras daquela cadeia.
• drop: descarta o pacote silenciosamente (sem responder ao remetente).
• reject: descarta o pacote e envia uma resposta ao remetente (por exemplo, TCP RST ou ICMP "administratively prohibited"). Em RouterOS é possível especificar o tipo de resposta com o parâmetro reject-with.

Observação: nos comandos do RouterOS, as ações são exatamente action=accept, action=drop e action=reject.

Implicações práticas

• accept permite o tráfego correspondente e, para conexões novas, normalmente resulta na criação de uma entrada no connection tracking (se a regra for avaliada após o ponto onde o rastreamento é aplicado).
• drop bloqueia sem indicar ao originador, causando retransmissões e timeouts no lado cliente.
• reject informa imediatamente que a sessão foi recusada — útil para protocolos que se beneficiam de um retorno (por exemplo, fechar uma sessão TCP com RST).

Connection tracking em MikroTik (explicação prática)

• O connection tracking (ct) é o mecanismo que identifica estados de conexão (new, established, related, invalid) e é utilizado normalmente nas regras do tipo connection-state=... em /ip firewall filter.
• Regras na tabela raw (ex.: /ip firewall raw) são avaliadas antes do connection tracking: se você descartar pacotes na raw table, esses pacotes podem ser descartados antes de gerar uma entrada de connection tracking. Isso é usado quando se deseja evitar consumo de recursos com tracking para tráfegos indesejados.
• A maioria das regras no filter (chain=input/forward/output) é aplicada após o connection tracking, o que permite usar connection-state=established,related para aceitar respostas de conexões já estabelecidas.

Ordem das regras e efeito da primeira correspondência

• O RouterOS processa regras dentro de cada cadeia em ordem sequencial. Ao encontrar uma regra que corresponde, a ação é executada e o processamento daquela cadeia é interrompido para o pacote (portanto, a posição da regra é crítica).
• Boas práticas comuns:
  • Aceitar established,related logo no início para permitir respostas de conexões já validadas.
  • Inserir regras específicas de Allow antes de regras genéricas de Deny/Drop.
  • Utilizar a tabela raw com cuidado para prevenir que tráfegos indesejados atinjam o connection tracking.

Drop vs Reject — diferença e impacto

• Drop:
  • Silencioso. O emissor não recebe aviso imediato e continuará retransmitindo conforme seu protocolo.
  • Útil para esconder serviços e forçar exploração de timeouts no atacante.
  • Menos tráfego de controle de retorno, mas causa mais retransmissões do lado cliente.
• Reject:
  • Gera uma resposta imediata (ex.: TCP RST, ICMP port unreachable), liberando recursos no lado cliente e informando a rejeição.
  • Útil em redes internas para feedback rápido de erro ou quando você quer que um cliente pare de tentar.
  • Pode oferecer mais informações ao cliente/possível atacante (pode ser menos "silencioso" do ponto de vista de segurança por revelar que um host existe).

Exemplos de regras Allow/Deny no RouterOS

Exemplo 1 — Política mínima de filtro (base)

/ip firewall filter
add chain=input connection-state=established,related action=accept comment="Allow established/related"
add chain=input connection-state=invalid action=drop comment="Drop invalid packets"
add chain=input protocol=tcp dst-port=22 action=reject reject-with=tcp-reset comment="Reject SSH with RST"
add chain=input action=drop comment="Drop everything else to input"

Explicação:

• A primeira regra libera pacotes de conexões já estabelecidas ou relacionadas (usa connection tracking).
• Em seguida, descartamos pacotes inválidos.
• Rejeitamos tentativas de SSH explicitamente com reset.
• Finalmente, tudo que não corresponde acima é descartado.

Exemplo 2 — Bloquear uma rede na tabela raw (antes do connection tracking)

/ip firewall raw
add chain=prerouting src-address=203.0.113.0/24 action=drop comment="Drop traffic from this subnet before conntrack"

Explicação:

• Ao usar a tabela raw e chain=prerouting, os pacotes dessa origem são descartados antes do mecanismo de connection tracking. Isso evita criação de entradas de conexão e reduz uso de recursos quando se tem tráfego indesejado volumoso.

Exemplo 3 — Permitir acesso HTTP apenas de uma rede interna

/ip firewall filter
add chain=forward src-address=192.168.10.0/24 protocol=tcp dst-port=80 action=accept comment="Allow HTTP from internal network"
add chain=forward protocol=tcp dst-port=80 action=drop comment="Drop other HTTP attempts"

Explicação:

• Primeiro permitimos o acesso à porta 80 somente da rede interna, depois bloqueamos tentativas externas.

Recomendações práticas

• Sempre coloque regras específicas (Allow) antes de regras genéricas (Deny/Drop).
• Use connection-state=established,related para manter sessões válidas sem expor novas entradas indevidas.
• Utilize raw para descartar tráfego volumoso indesejado antes que o connection tracking consuma recursos.
• Prefira reject quando quiser feedback rápido a clientes legítimos; prefira drop quando desejar comportamento silencioso e maior opacidade para possíveis atacantes.
• Teste mudanças em um ambiente controlado sempre que possível e mantenha acesso de gestão (por exemplo, via regras específicas para seu IP) para evitar bloqueios administrativos acidentais.

Conclusão

Allow (accept) e Denied (drop/reject) têm comportamentos e impactos operacionais distintos no RouterOS. Entender a ordem de avaliação das regras, a interação com o connection tracking e a diferença entre drop e reject é essencial para projetar uma política de firewall eficiente e segura. Use regras específicas e a tabela raw quando necessário para otimizar recursos e priorizar o tráfego legítimo.