Como Configurar Regras de Firewall: Um Guia Técnico Completo

Uma regra de firewall é uma entrada de política que instrui um motor de firewall a permitir, negar ou registar tráfego de rede com base em critérios definidos, como endereço IP de origem/destino, número de porta, protocolo de transporte e direção do tráfego. As regras de firewall corretamente configuradas formam a camada de aplicação primária entre a sua infraestrutura e a internet pública, tornando-as o controlo de segurança mais importante em qualquer servidor ou dispositivo de rede.

Este guia aborda a arquitetura de regras de firewall, UFW no Linux, firewalld, Windows Defender Firewall, nftables, e as práticas operacionais que distinguem um ambiente seguro de um mal configurado.

O Que as Regras de Firewall Controlam Efetivamente

Cada regra num conjunto de regras de firewall é avaliada em relação a cinco atributos principais de pacotes, comumente chamados de 5-tuple:

• Endereço IP de origem — o host ou sub-rede de origem (ex., 192.168.1.0/24)
• Endereço IP de destino — o host ou intervalo alvo
• Porta de origem — a porta efémera no lado iniciador
• Porta de destino — a porta de serviço no lado recetor (ex., 443 para HTTPS, 22 para SSH)
• Protocolo — TCP, UDP, ICMP, ou número de protocolo

Além do 5-tuple, os firewalls com estado também rastreiam o estado da ligação (NEW, ESTABLISHED, RELATED, INVALID), o que lhes permite permitir tráfego de retorno para ligações de saída sem escrever regras de entrada explícitas para cada resposta.

Firewalls com Estado vs. Sem Estado

Para praticamente todas as implementações de servidores — incluindo Alojamento VPS e Servidores Dedicados — um firewall de host com estado é a escolha padrão correta.

Processamento de Regras de Firewall: O Problema da Ordem

Uma das fontes mais comuns de má configuração é a incompreensão da ordenação de regras. A maioria dos firewalls avalia as regras de cima para baixo e aplica a primeira regra correspondente, depois para. Isto significa:

• Uma regra ALLOW ampla colocada acima de uma regra DENY específica irá substituí-la silenciosamente.
• Um DENY ALL no topo de uma cadeia bloqueia tudo, independentemente do que se segue.
• Regras duplicadas ou sombreadas desperdiçam ciclos de processamento e criam confusão nas auditorias.

Melhor prática: Coloque sempre regras específicas antes das gerais. Coloque regras DENY explícitas para origens conhecidas como maliciosas perto do topo, seguidas de regras ALLOW específicas para serviços de confiança, e termine cada cadeia com uma política DENY predefinida.

Configurar Regras de Firewall no Linux com UFW

UFW (Uncomplicated Firewall) é uma interface para iptables e nftables em sistemas baseados em Debian/Ubuntu. Abstrai a sintaxe de cadeia de baixo nível em comandos legíveis por humanos, preservando o controlo total sobre filtragem de porta, protocolo, IP e interface.

Passo 1: Instalar e Ativar o UFW

O UFW vem pré-instalado no Ubuntu. Verifique o seu estado antes de ativar:

sudo ufw status verbose

Se inativo, ative-o:

sudo ufw enable

Aviso crítico: Se estiver ligado via SSH e ainda não tiver permitido a porta 22, ativar o UFW irá bloqueá-lo. Permita sempre o SSH antes de ativar o firewall num servidor remoto.

Passo 2: Definir Políticas Predefinidas

As políticas predefinidas definem o que acontece ao tráfego que não corresponde a nenhuma regra explícita. A linha de base segura é:

sudo ufw default deny incoming
sudo ufw default allow outgoing

Isto bloqueia todas as ligações de entrada não solicitadas enquanto permite todo o tráfego de saída. Se a sua política de segurança exigir filtragem de saída (ex., prevenção de exfiltração de dados ou callbacks C2), altere o padrão de saída:

sudo ufw default deny outgoing

Em seguida, permita explicitamente apenas os destinos de saída de que a sua aplicação necessita.

Passo 3: Permitir Serviços e Portas Específicos

O UFW suporta nomes de serviços de /etc/services ou números de porta explícitos:

# Allow SSH by service name
sudo ufw allow ssh

# Allow HTTP and HTTPS
sudo ufw allow http
sudo ufw allow https

# Allow a custom application port
sudo ufw allow 8080/tcp

# Allow a UDP service (e.g., DNS resolver)
sudo ufw allow 53/udp

Para permitir um intervalo de portas (ex., FTP passivo):

sudo ufw allow 49152:65535/tcp

Passo 4: Restringir o Acesso a IPs de Origem Específicos

Expor portas administrativas a 0.0.0.0/0 é uma das principais causas de comprometimento por força bruta. Bloqueie o SSH a um IP de gestão conhecido:

sudo ufw allow from 203.0.113.50 to any port 22 proto tcp

Para permitir uma sub-rede de gestão completa:

sudo ufw allow from 10.0.0.0/8 to any port 22 proto tcp

Passo 5: Negar Tráfego de IPs ou Sub-redes Específicos

Bloquear um IP conhecido como malicioso:

sudo ufw deny from 198.51.100.77

Bloquear uma sub-rede inteira (ex., um bloqueio geográfico ou um intervalo ASN abusivo):

sudo ufw deny from 198.51.100.0/24

Caso especial: As regras deny do UFW enviam uma resposta TCP RST ou ICMP port-unreachable, o que confirma que o host existe. Use reject para descartar pacotes silenciosamente:

sudo ufw reject from 198.51.100.0/24

Passo 6: Inspecionar Regras Ativas

sudo ufw status numbered

O sinalizador numbered atribui um índice a cada regra, necessário para eliminação direcionada:

[ 1] 22/tcp                     ALLOW IN    203.0.113.50
[ 2] 80/tcp                     ALLOW IN    Anywhere
[ 3] 443/tcp                    ALLOW IN    Anywhere

Para uma saída detalhada completa incluindo políticas predefinidas e ligações de interface:

sudo ufw status verbose

Passo 7: Eliminar Regras

Eliminar por número de regra (preferido — evita ambiguidade):

sudo ufw delete 3

Eliminar por especificação de regra:

sudo ufw delete allow 8080/tcp

Passo 8: Recarregar e Persistir Regras

As regras UFW persistem automaticamente após reinicializações. Após alterações em massa, recarregue sem interromper ligações existentes:

sudo ufw reload

Para repor completamente todas as regras e começar do zero:

sudo ufw reset

UFW Avançado: Perfis de Aplicação

O UFW suporta perfis de aplicação com nome armazenados em /etc/ufw/applications.d/. Isto permite definir regras multi-porta com um único nome:

sudo ufw app list
sudo ufw allow 'Nginx Full'
sudo ufw app info 'Nginx Full'

Criar um perfil personalizado para uma API Node.js:

[NodeAPI]
title=Node.js API Server
description=Custom Node.js application
ports=3000,3001/tcp

Em seguida, aplique-o:

sudo ufw allow NodeAPI

Configurar Regras de Firewall com firewalld (RHEL/CentOS/Fedora)

firewalld utiliza um modelo baseado em zonas em vez de um conjunto de regras plano. Cada interface de rede é atribuída a uma zona (ex., public, internal, dmz), e as regras são aplicadas por zona. Isto é arquiteturalmente mais flexível para servidores multi-homed.

Operações Básicas do firewalld

# Check status
sudo firewall-cmd --state

# List all active zones and their interfaces
sudo firewall-cmd --get-active-zones

# List rules in the public zone
sudo firewall-cmd --zone=public --list-all

Permitir e Remover Serviços

# Allow HTTPS permanently
sudo firewall-cmd --zone=public --add-service=https --permanent

# Allow a custom port
sudo firewall-cmd --zone=public --add-port=8443/tcp --permanent

# Remove a service
sudo firewall-cmd --zone=public --remove-service=http --permanent

# Reload to apply permanent changes
sudo firewall-cmd --reload

Regras Ricas para Políticas Específicas de IP

As regras ricas firewalld fornecem a granularidade de iptables com uma sintaxe mais legível:

# Allow SSH only from a specific IP
sudo firewall-cmd --zone=public 
  --add-rich-rule='rule family="ipv4" source address="203.0.113.50" service name="ssh" accept' 
  --permanent

# Block all traffic from a subnet
sudo firewall-cmd --zone=public 
  --add-rich-rule='rule family="ipv4" source address="198.51.100.0/24" drop' 
  --permanent

sudo firewall-cmd --reload

Configurar Regras de Firewall com nftables

nftables é o substituto moderno de iptables, oferecendo uma estrutura unificada para filtragem IPv4, IPv6, ARP e bridge com desempenho significativamente melhor e substituição atómica de regras.

Conjunto de Regras Básico do nftables

# Flush existing ruleset
sudo nft flush ruleset

# Create a basic filtering table
sudo nft add table inet filter

# Add input, forward, and output chains
sudo nft add chain inet filter input { type filter hook input priority 0 ; policy drop ; }
sudo nft add chain inet filter forward { type filter hook forward priority 0 ; policy drop ; }
sudo nft add chain inet filter output { type filter hook output priority 0 ; policy accept ; }

# Allow established and related connections
sudo nft add rule inet filter input ct state established,related accept

# Allow loopback
sudo nft add rule inet filter input iif lo accept

# Allow SSH from a specific IP
sudo nft add rule inet filter input ip saddr 203.0.113.50 tcp dport 22 accept

# Allow HTTP and HTTPS from anywhere
sudo nft add rule inet filter input tcp dport { 80, 443 } accept

Para tornar o conjunto de regras persistente, guarde-o no ficheiro de configuração predefinido:

sudo nft list ruleset > /etc/nftables.conf
sudo systemctl enable nftables

Configurar Regras de Firewall no Windows

O Windows Defender Firewall com Segurança Avançada fornece interfaces GUI e linha de comandos (netsh, PowerShell) para gestão de regras.

Utilizar a GUI

1. Abra o Windows Defender Firewall com Segurança Avançada via wf.msc.
2. Selecione Regras de Entrada ou Regras de Saída no painel esquerdo.
3. Clique em Nova Regra no painel direito.
4. Escolha o tipo de regra:

• Porta — filtrar por número de porta TCP/UDP
• Programa — filtrar por caminho do executável
• Predefinido — utilizar uma definição de serviço Windows incorporada
• Personalizado — controlo total sobre todos os parâmetros

1. Especifique a porta ou programa, escolha Permitir ou Bloquear, selecione os perfis aplicáveis (Domínio, Privado, Público) e nomeie a regra.

Utilizar PowerShell (Recomendado para Automação)

# Allow inbound HTTPS
New-NetFirewallRule -DisplayName "Allow HTTPS Inbound" `
  -Direction Inbound -Protocol TCP -LocalPort 443 -Action Allow

# Allow inbound SSH (Windows OpenSSH)
New-NetFirewallRule -DisplayName "Allow SSH Inbound" `
  -Direction Inbound -Protocol TCP -LocalPort 22 -Action Allow `
  -RemoteAddress 203.0.113.50

# Block inbound traffic from a specific IP
New-NetFirewallRule -DisplayName "Block Malicious IP" `
  -Direction Inbound -RemoteAddress 198.51.100.77 -Action Block

# View all inbound rules
Get-NetFirewallRule -Direction Inbound | Select-Object DisplayName, Enabled, Action

# Remove a rule by name
Remove-NetFirewallRule -DisplayName "Allow HTTPS Inbound"

Utilizar netsh (Legado mas Amplamente Suportado)

:: Allow inbound port 443
netsh advfirewall firewall add rule name="Allow HTTPS" protocol=TCP dir=in localport=443 action=allow

:: Block a specific IP
netsh advfirewall firewall add rule name="Block IP" dir=in remoteip=198.51.100.77 action=block

:: Delete a rule
netsh advfirewall firewall delete rule name="Allow HTTPS"

Armadilhas e Casos Especiais Críticos nas Regras de Firewall

A Permissão Implícita para Tráfego ESTABLISHED

Em firewalls com estado, não permitir explicitamente ligações ESTABLISHED e RELATED na cadeia de entrada irá interromper todas as sessões iniciadas de saída (ex., apt update, curl, pesquisas DNS) mesmo quando a cadeia de saída está definida como ACCEPT. Esta é a má configuração mais comum em configurações brutas de iptables ou nftables.

# This rule MUST appear before any DROP rules in the input chain
sudo iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

Paridade IPv6

Muitos administradores configuram regras IPv4 meticulosamente e esquecem completamente o IPv6. Se o seu servidor tiver um endereço IPv6 e o suporte IPv6 do UFW não estiver ativado, um atacante pode contornar todas as regras IPv4 ligando-se via ::. Verifique se /etc/default/ufw contém:

IPV6=yes

Interface de Loopback

Permita sempre explicitamente o tráfego na interface de loopback (lo). Muitos serviços locais (bases de dados, filas de mensagens, APIs internas) comunicam via 127.0.0.1 ou ::1. Bloquear o loopback interrompe silenciosamente a comunicação entre processos.

sudo ufw allow in on lo
sudo ufw allow out on lo

Limitação de Taxa para Prevenir Força Bruta

O UFW suporta limitação de taxa de ligação nativamente, o que é essencial para SSH e outros serviços de autenticação:

sudo ufw limit ssh

Isto permite um máximo de 6 tentativas de ligação por 30 segundos a partir de um único IP antes de acionar um bloqueio temporário automático — uma alternativa leve a fail2ban para implementações básicas.

Tráfego ICMP e de Diagnóstico

Bloquear todo o ICMP é uma prática comum mas contraproducente. Interrompe ping, traceroute, descoberta de MTU de caminho e alguns protocolos de roteamento. A abordagem correta é permitir tipos específicos de ICMP:

• Tipo 0 (Echo Reply) e Tipo 8 (Echo Request) — para ping
• Tipo 3 (Destination Unreachable) — para descoberta de MTU de caminho
• Tipo 11 (Time Exceeded) — para traceroute

Bloqueie o Tipo 17 (Address Mask Request) e o Tipo 18 (Address Mask Reply), que não têm uso moderno legítimo.

Regras de Firewall e Ambientes de Alojamento

A estratégia correta de firewall depende muito da sua camada de infraestrutura.

No Alojamento Web Partilhado, o firewall é gerido ao nível da plataforma pelo fornecedor. Os inquilinos normalmente configuram controlos de acesso ao nível da aplicação em vez de filtros de pacotes ao nível do kernel.

Num VPS com cPanel, o cPanel/WHM inclui o ConfigServer Security & Firewall (CSF), que envolve iptables com uma interface de alto nível, deteção automática de força bruta e suporte a port knocking. O CSF é a solução de firewall padrão para ambientes cPanel e deve ser utilizado em preferência ao UFW bruto nesses sistemas.

Em Alojamento VPS ou Servidores Dedicados não geridos, tem controlo total sobre o firewall do kernel. É aqui que UFW, firewalld e nftables são as ferramentas adequadas. A linha de base de segurança deve incluir:

• Política de entrada de negação predefinida
• SSH restrito a IPs de gestão conhecidos ou a um gateway VPN
• Todas as portas não essenciais fechadas
• Limitação de taxa em portas de autenticação
• Registo ativado para tráfego negado

Se estiver a executar cargas de trabalho GPU ou serviços de inferência ML em Alojamento GPU, preste especial atenção às portas expostas por notebooks Jupyter, TensorBoard e APIs de serviço de modelos — estas são frequentemente visadas por bots de criptomineração que procuram portas de números elevados abertas.

Lista de Verificação de Auditoria e Manutenção de Regras de Firewall

As auditorias regulares de regras são tão importantes quanto a configuração inicial. As regras acumulam-se ao longo do tempo e tornam-se obsoletas, criando superfície de ataque desnecessária.

Tarefas de auditoria a realizar trimestralmente:

• Execute sudo ufw status numbered ou equivalente e reveja cada regra em relação ao inventário de serviços atual
• Remova regras para serviços desativados, endereços IP antigos e exceções temporárias que nunca foram limpas
• Verifique se as políticas predefinidas ainda são deny incoming
• Verifique se as regras IPv6 espelham as regras IPv4
• Confirme que o registo está ativado e que os registos de tráfego negado estão a ser ingeridos pelo seu SIEM ou agregador de registos
• Teste as regras com nmap a partir de um host externo para verificar se a superfície de ataque corresponde à sua intenção

# Scan your own server from an external host to verify exposed ports
nmap -sS -sV -p 1-65535 --open YOUR_SERVER_IP

• Valide que as regras ESTABLISHED/RELATED estão presentes e corretamente ordenadas
• Reveja as regras de limitação de taxa e ajuste os limiares com base nos padrões de tráfego observados

Matriz de Decisão: Escolher a Ferramenta de Firewall Correta

Principais Conclusões Práticas

• Defina negação de entrada predefinida antes de escrever quaisquer regras de permissão. Isto garante que qualquer regra que se esqueça de escrever resulte numa ligação bloqueada, não numa aberta.
• Nunca exponha o SSH a 0.0.0.0/0 num servidor de produção. Restrinja-o a um IP de gestão, uma sub-rede VPN, ou utilize port knocking.
• Escreva regras de permissão tão específicas quanto possível. Prefira from 203.0.113.50 to any port 22 proto tcp em vez de allow 22.
• Espelhe as regras IPv4 em IPv6. Um firewall que apenas filtra IPv4 é meio firewall.
• Ative a limitação de taxa de ligação em todas as portas de autenticação como mitigação básica de força bruta.
• Registe o tráfego negado. Descartes silenciosos sem registo tornam a resposta a incidentes praticamente impossível.
• Audite as regras regularmente. Regras obsoletas são uma responsabilidade, não uma rede de segurança.
• Teste a partir do exterior. Utilize nmap ou um scanner de portas externo após cada alteração significativa de regras para confirmar a superfície de ataque efetiva.
• Utilize ufw reload em vez de ufw disable && ufw enable para evitar interromper ligações ativas durante atualizações de regras.
• Em nftables e iptables, coloque sempre a regra de aceitação ESTABLISHED/RELATED no topo da cadeia de entrada para evitar interromper sessões iniciadas de saída.

Perguntas Frequentes

Qual é a diferença entre uma regra de firewall e um grupo de segurança em ambientes de nuvem?

Um grupo de segurança (AWS, GCP, Azure) é um filtro de pacotes com estado, gerido pela nuvem, aplicado ao nível do hipervisor antes de o tráfego chegar à sua VM. Uma regra de firewall baseada em host (UFW, firewalld) é executada dentro do kernel do SO. Ambos devem ser utilizados simultaneamente para defesa em profundidade — o grupo de segurança na nuvem como perímetro externo e o firewall de host como camada de aplicação interna.

Por que o UFW mostra uma regra como ativa mas o tráfego ainda está bloqueado?

A causa mais comum é a ordenação de regras. Uma regra DENY anterior na cadeia está a corresponder antes da sua regra ALLOW. Execute sudo ufw status numbered e verifique a ordem. Verifique também se existem regras IPv6 caso o cliente esteja a ligar-se via IPv6, e confirme se a interface correta está visada se o servidor for multi-homed.

Devo bloquear completamente o ICMP por segurança?

Não. Bloquear todo o ICMP interrompe a descoberta de MTU de caminho, o que faz com que as sessões TCP fiquem suspensas em redes com MTUs não padrão. Também interrompe traceroute e torna os diagnósticos de rede significativamente mais difíceis. Bloqueie apenas os tipos de ICMP sem uso operacional legítimo (tipos 17 e 18). Permita echo request/reply, destination unreachable e time exceeded.

O que acontece às ligações SSH ativas quando recarrego o UFW?

sudo ufw reload recarrega o conjunto de regras sem limpar as entradas de estado conntrack existentes. As sessões SSH ativas permanecem ligadas porque a tabela de rastreamento de ligações do kernel ainda mantém o estado ESTABLISHED delas. Apenas sudo ufw disable seguido de sudo ufw enable limparia o estado e potencialmente interromperia ligações ativas.

Como posso evitar que as regras de firewall se percam após uma reinicialização do sistema?

O UFW persiste as regras automaticamente após reinicializações através de ficheiros de configuração /etc/ufw/. Para firewalld, utilize o sinalizador --permanent em cada regra e execute sudo firewall-cmd --reload. Para nftables bruto, guarde o conjunto de regras com sudo nft list ruleset > /etc/nftables.conf e certifique-se de que o serviço systemd nftables está ativado. Para iptables, utilize iptables-save > /etc/iptables/rules.v4 e instale o pacote iptables-persistent.