Uma Introdução ao Firewalld: Gerenciamento Dinâmico de Firewall no Linux

Firewalld é um daemon de gestão de firewall em espaço de utilizador para Linux que fornece uma interface dinâmica baseada em zonas sobre os backends de filtragem de pacotes ao nível do kernel iptables e nftables. Ao contrário das ferramentas de firewall estáticas que requerem um reinício completo do serviço para aplicar alterações de regras, o Firewalld modifica as regras netfilter em tempo real — preservando as sessões TCP ativas e eliminando o tempo de inatividade durante as atualizações de políticas.

Este guia abrange todas as camadas operacionais do Firewalld: o seu modelo arquitetural, abstrações de zonas e serviços, regras ricas, configuração em tempo de execução versus permanente, e os comandos exatos necessários para gerir um servidor de produção de forma segura.

Por que o Firewalld Substituiu os Fluxos de Trabalho Estáticos do iptables

A gestão tradicional do iptables implica escrever regras em scripts de shell ou ficheiros de configuração simples, depois limpar e recarregar todo o conjunto de regras sempre que é necessária uma alteração. Num servidor ocupado, esse ciclo de limpeza e recarga interrompe as ligações em curso e introduz uma breve janela em que nenhuma filtragem está ativa.

O Firewalld resolve isto através de um daemon ativado por D-Bus (firewalld) que mantém o estado autoritativo das regras e comunica as alterações ao kernel de forma incremental. O resultado são atualizações atômicas de regras sem interrupção de ligações — crítico para qualquer servidor que execute cargas de trabalho persistentes como bases de dados, túneis VPN ou ligações API de longa duração.

Quando aprovisiona um ambiente de VPS Hosting e precisa de o proteger sem reiniciar ou interromper serviços, o Firewalld é a escolha operacional natural nas distribuições da família RHEL e em muitas distribuições da família Debian.

Arquitetura Central: Como o Firewalld Interage com o Kernel

Compreender a pilha por baixo do Firewalld previne configurações incorretas e ajuda a depurar comportamentos inesperados.

User Space
┌─────────────────────────────────────────────┐
│ firewall-cmd / firewall-config / D-Bus API  │
└────────────────────┬────────────────────────┘
                     │ D-Bus
┌────────────────────▼────────────────────────┐
│              firewalld daemon               │
│  (zone engine, service definitions, rich    │
│   rule parser, direct rule passthrough)     │
└────────────────────┬────────────────────────┘
                     │ nftables / iptables backend
Kernel Space
┌────────────────────▼────────────────────────┐
│           netfilter (kernel module)         │
└─────────────────────────────────────────────┘

Desde o RHEL 8 e o Fedora 32, o Firewalld usa por padrão o backend nftables. Em sistemas mais antigos ou em ambientes explicitamente configurados, utiliza o backend iptables. Pode inspecionar ou substituir o backend ativo em /etc/firewalld/firewalld.conf através da diretiva FirewallBackend.

Armadilha crítica: Nunca misture comandos diretos iptables ou nft com o Firewalld na mesma interface. O Firewalld é proprietário das tabelas netfilter que cria; as regras manuais inseridas fora do daemon serão silenciosamente substituídas na próxima recarga.

Conceitos Chave no Firewalld

Zonas

Uma zona é um nível de confiança nomeado aplicado a uma interface de rede ou intervalo de endereços de origem. Cada pacote que entra no sistema é correspondido com a zona atribuída à sua interface de entrada, e o conjunto de regras da zona determina o que é permitido.

O Firewalld é fornecido com as seguintes zonas predefinidas, ordenadas da mais para a menos permissiva:

Nuance arquitetural: Uma zona pode ser vinculada a uma interface de rede (ex., eth0) ou a um CIDR de origem (ex., 192.168.1.0/24). A vinculação baseada em origem tem precedência sobre a vinculação baseada em interface, o que permite aplicar políticas diferentes ao tráfego que chega na mesma interface física a partir de sub-redes diferentes — um padrão comum em ambientes multi-tenant ou em contentores.

Serviços

Um serviço no Firewalld é um ficheiro de definição XML armazenado em /usr/lib/firewalld/services/ (padrões do sistema) ou /etc/firewalld/services/ (substituições do utilizador). Cada ficheiro declara as portas, protocolos e módulos auxiliares opcionais necessários para uma aplicação nomeada.

Por exemplo, a definição do serviço https abre a porta TCP 443 e não carrega módulos auxiliares adicionais do kernel. O serviço ftp abre a porta TCP 21 e carrega o auxiliar nf_conntrack_ftp para gerir a negociação de porta dinâmica do canal de dados FTP.

Usar nomes de serviços em vez de números de porta brutos torna a sua política de firewall autodocumentada e reduz o risco de erros tipográficos que deixam uma porta inadvertidamente aberta ou fechada.

Para listar todas as definições de serviços disponíveis no seu sistema:

firewall-cmd --get-services

Para inspecionar a definição XML de um serviço específico:

cat /usr/lib/firewalld/services/https.xml

Regras Ricas

As regras ricas estendem o modelo de zona com lógica condicional que a abstração simples de serviço/porta não consegue expressar. Suportam correspondência em endereços de origem e destino, intervalos de portas, protocolos, janelas de tempo e estado de ligação, e podem desencadear ações incluindo accept, drop, reject, log e audit.

A sintaxe das regras ricas segue uma gramática estruturada:

rule [family="ipv4|ipv6"]
  [source address="addr[/mask]" [invert="true"]]
  [destination address="addr[/mask]" [invert="true"]]
  [service name="service-name"] | [port port="port" protocol="tcp|udp"]
  [log [prefix="prefix"] [level="level"] [limit value="rate/duration"]]
  [audit]
  [accept|drop|reject [type="reject-type"]]

Um exemplo prático — limitar a taxa de tentativas de login SSH a 3 por minuto a partir de qualquer fonte IPv4 única, depois registar e descartar o excesso:

firewall-cmd --zone=public --add-rich-rule='
  rule family="ipv4"
  service name="ssh"
  log prefix="SSH_RATELIMIT " level="warning" limit value="3/m"
  accept' --permanent

firewall-cmd --zone=public --add-rich-rule='
  rule family="ipv4"
  service name="ssh"
  drop' --permanent

Caso extremo: A ordem das regras ricas é importante. O Firewalld avalia as regras ricas na ordem em que foram adicionadas dentro de uma zona. Se adicionar uma regra drop ampla antes de uma regra accept específica, a accept nunca será alcançada. Adicione sempre primeiro as regras mais específicas.

Configuração em Tempo de Execução vs. Permanente

Esta é a distinção operacionalmente mais importante no Firewalld e a fonte dos erros de produção mais comuns.

Fluxo de trabalho de melhores práticas para alterações em produção:

1. Aplique a regra apenas em tempo de execução (sem a flag --permanent) e verifique se se comporta conforme esperado.
2. Se estiver correto, aplique a mesma regra com --permanent para a escrever no disco.
3. Execute firewall-cmd --reload para sincronizar a configuração permanente no estado em tempo de execução e confirmar a paridade.

Este fluxo de trabalho previne o cenário clássico em que um administrador adiciona uma regra --permanent, recarrega e descobre que se bloqueou a si próprio do SSH — porque o teste em tempo de execução teria revelado o problema antes de se tornar permanente.

Instalar e Ativar o Firewalld

O Firewalld é instalado por padrão no RHEL, CentOS Stream, Fedora, AlmaLinux e Rocky Linux. No Debian e Ubuntu deve ser instalado explicitamente.

RHEL / CentOS Stream / AlmaLinux / Rocky Linux:

sudo dnf install firewalld

Debian / Ubuntu:

sudo apt-get update && sudo apt-get install firewalld

Nota para utilizadores Ubuntu: Se ufw estiver ativo, desative-o antes de ativar o Firewalld para evitar conflitos de regras netfilter:

sudo ufw disable
sudo systemctl disable ufw

Inicie e ative o daemon:

sudo systemctl start firewalld
sudo systemctl enable firewalld

Verifique se o daemon está em execução e o backend do kernel está ativo:

sudo firewall-cmd --state
sudo firewall-cmd --info-zone=public

Comandos Essenciais do Firewalld

Inspecionar o Estado Atual

Verificar o estado do daemon:

sudo firewall-cmd --state

Listar todas as zonas ativas com as suas interfaces e fontes atribuídas:

sudo firewall-cmd --get-active-zones

Exibir o conjunto de regras completo para uma zona específica:

sudo firewall-cmd --zone=public --list-all

Exibir o conjunto de regras completo para todas as zonas simultaneamente:

sudo firewall-cmd --list-all-zones

Gerir a Zona Padrão

A zona padrão é aplicada a qualquer interface não atribuída explicitamente a outra zona:

sudo firewall-cmd --get-default-zone
sudo firewall-cmd --set-default-zone=public

Atribuir uma Interface a uma Zona

sudo firewall-cmd --zone=internal --change-interface=eth1 --permanent
sudo firewall-cmd --reload

Armadilha: Em sistemas que utilizam NetworkManager, as atribuições de interface para zona feitas via firewall-cmd podem ser substituídas pelo perfil de ligação do NetworkManager ao reconectar. Defina a zona de forma persistente no perfil de ligação do NetworkManager:

nmcli connection modify "Wired connection 1" connection.zone internal

Adicionar e Remover Serviços

Permitir HTTP na zona pública em tempo de execução:

sudo firewall-cmd --zone=public --add-service=http

Torná-lo permanente:

sudo firewall-cmd --zone=public --add-service=http --permanent

Remover um serviço:

sudo firewall-cmd --zone=public --remove-service=http --permanent

Abrir e Fechar Portas Específicas

Abrir a porta TCP 8080 em tempo de execução:

sudo firewall-cmd --zone=public --add-port=8080/tcp

Abrir um intervalo de portas UDP de forma permanente:

sudo firewall-cmd --zone=public --add-port=60000-61000/udp --permanent

Remover uma porta:

sudo firewall-cmd --zone=public --remove-port=8080/tcp --permanent

Lista de Permissões e Bloqueios de Endereços IP

Permitir todo o tráfego de uma sub-rede de gestão confiável:

sudo firewall-cmd --zone=trusted --add-source=10.0.0.0/24 --permanent

Bloquear todo o tráfego de um IP específico (descarte baseado em origem):

sudo firewall-cmd --zone=drop --add-source=203.0.113.45/32 --permanent

Encaminhamento de Portas

Encaminhar a porta TCP externa 2222 para a porta SSH interna 22 (útil para ocultar a porta SSH padrão sem alterar sshd_config):

sudo firewall-cmd --zone=public --add-forward-port=port=2222:proto=tcp:toport=22 --permanent
sudo firewall-cmd --reload

Mascaramento IP (NAT)

Ativar o mascaramento na zona externa para permitir que um VPS a funcionar como gateway faça NAT do tráfego de uma sub-rede privada:

sudo firewall-cmd --zone=external --add-masquerade --permanent
sudo firewall-cmd --reload

Recarregar e Sincronizar a Configuração

Aplicar todas as alterações permanentes ao estado em execução sem interromper ligações:

sudo firewall-cmd --reload

Efetuar um reinício completo (interrompe todas as ligações — use apenas em emergências):

sudo systemctl restart firewalld

Criar Zonas Personalizadas e Definições de Serviços

Zona Personalizada

sudo firewall-cmd --new-zone=management --permanent
sudo firewall-cmd --zone=management --add-source=10.10.0.0/16 --permanent
sudo firewall-cmd --zone=management --add-service=ssh --permanent
sudo firewall-cmd --zone=management --add-service=cockpit --permanent
sudo firewall-cmd --reload

Definição de Serviço Personalizado

Criar um ficheiro de serviço para uma aplicação personalizada a escutar na porta TCP 9200 (ex., Elasticsearch):

sudo nano /etc/firewalld/services/elasticsearch.xml

<?xml version="1.0" encoding="utf-8"?>
<service>
  <short>Elasticsearch</short>
  <description>Elasticsearch HTTP API and transport port</description>
  <port protocol="tcp" port="9200"/>
  <port protocol="tcp" port="9300"/>
</service>

sudo firewall-cmd --reload
sudo firewall-cmd --zone=internal --add-service=elasticsearch --permanent
sudo firewall-cmd --reload

Firewalld vs. Alternativas: Escolher a Ferramenta Certa

Para equipas que gerem Servidores Dedicados em escala, a API D-Bus do Firewalld permite a gestão programática de regras a partir de ferramentas de gestão de configuração como Ansible (módulo ansible.posix.firewalld) ou Puppet, o que representa uma vantagem operacional significativa em relação à manutenção de scripts iptables brutos.

Padrões Práticos de Endurecimento de Segurança

Proteger um Servidor Web

Uma configuração típica para um servidor a executar HTTPS com SSH restrito a um IP de gestão:

# Set the default zone
sudo firewall-cmd --set-default-zone=public --permanent

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

# Allow HTTP only to redirect to HTTPS (optional)
sudo firewall-cmd --zone=public --add-service=http --permanent

# Restrict SSH to a specific management IP only
sudo firewall-cmd --zone=public --remove-service=ssh --permanent
sudo firewall-cmd --zone=public --add-rich-rule='
  rule family="ipv4"
  service name="ssh"
  source address="198.51.100.10/32"
  accept' --permanent

sudo firewall-cmd --reload

Se estiver a executar um servidor web juntamente com uma implementação de Certificados SSL, garantir que a porta 443 está aberta na zona correta antes da emissão do certificado (especialmente para desafios ACME HTTP-01 ou TLS-ALPN-01) é um passo pré-requisito frequentemente ignorado.

Proteger um Servidor de Correio

Para servidores a executar stacks de Email Hosting (Postfix, Dovecot), o conjunto de serviços necessário é:

sudo firewall-cmd --zone=public --add-service=smtp --permanent
sudo firewall-cmd --zone=public --add-service=smtps --permanent
sudo firewall-cmd --zone=public --add-service=imap --permanent
sudo firewall-cmd --zone=public --add-service=imaps --permanent
sudo firewall-cmd --zone=public --add-service=pop3s --permanent
sudo firewall-cmd --reload

Registar Pacotes Descartados para Análise Forense

sudo firewall-cmd --zone=public --add-rich-rule='
  rule family="ipv4"
  log prefix="DROPPED_PUBLIC " level="warning" limit value="10/m"
  drop' --permanent
sudo firewall-cmd --reload

Os registos aparecem em /var/log/messages ou no journal do systemd (journalctl -k -g DROPPED_PUBLIC). Limite a taxa de registo (conforme mostrado acima) para evitar inundação de registos num cenário de DDoS.

Firewalld num VPS Gerido por cPanel

Se estiver a utilizar um VPS com cPanel, tenha em atenção que o cPanel instala e gere a sua própria camada de firewall (CSF/LFD por padrão). Executar o Firewalld juntamente com o CSF sem coordenação explícita produzirá regras netfilter conflituantes. A abordagem recomendada é escolher uma camada de gestão de firewall por servidor e desativar a outra, ou utilizar a interface de passagem direta de regras do Firewalld para integrar com os requisitos do cPanel.

Resolução de Problemas Comuns do Firewalld

Problema: A regra adicionada com --permanent não está em vigor.

Causa: As regras permanentes requerem uma recarga para entrar no estado em tempo de execução.

Solução:

sudo firewall-cmd --reload

Problema: Ligação SSH interrompida após alteração da firewall.

Causa: O serviço SSH foi removido da zona ativa, ou uma regra rica drop foi adicionada antes da regra accept.

Solução: Aceda ao servidor via consola out-of-band (consola VNC/KVM do seu fornecedor de alojamento), depois restaure o serviço SSH:

sudo firewall-cmd --zone=public --add-service=ssh --permanent
sudo firewall-cmd --reload

Problema: firewall-cmd retorna FirewallD is not running.

Causa: O daemon falhou ou nunca foi iniciado.

Solução:

sudo systemctl start firewalld
sudo journalctl -u firewalld -n 50

Problema: As regras parecem corretas mas o tráfego ainda está bloqueado.

Causa: Existe uma regra iptables ou nft conflituante fora das tabelas geridas pelo Firewalld, ou o SELinux/AppArmor está a bloquear a ligação na camada de aplicação.

Solução: Verifique regras manuais e negações do SELinux:

sudo iptables -L -n -v
sudo ausearch -m avc -ts recent

Problema: Interface não atribuída à zona esperada após reinício.

Causa: O perfil de ligação do NetworkManager substitui a atribuição de interface do Firewalld.

Solução: Defina a zona no perfil do NetworkManager conforme descrito na secção de atribuição de interface acima.

Matriz de Decisão e Lista de Verificação Técnica

Utilize esta lista de verificação antes de implementar o Firewalld num servidor de produção:

• Confirme que o backend de firewall ativo (FirewallBackend em /etc/firewalld/firewalld.conf) corresponde ao suporte nftables/iptables do seu kernel.
• Verifique se não há ferramentas de firewall conflituantes (UFW, CSF, scripts iptables diretos) ativas nas mesmas interfaces.
• Atribua cada interface de rede explicitamente a uma zona — nunca dependa apenas da zona padrão para servidores com múltiplas interfaces.
• Aplique todas as alterações em tempo de execução primeiro, verifique a conectividade, depois confirme com --permanent e --reload.
• Restrinja o acesso SSH a IPs de origem específicos via regras ricas antes de remover o serviço SSH da zona pública.
• Adicione regras ricas de limitação de taxa para todos os serviços de autenticação expostos publicamente (SSH, SMTP, endpoints de login HTTPS).
• Ative o registo para a zona drop com um limite de taxa para capturar informações sobre ameaças sem inundar o armazenamento.
• Para servidores geridos via Painéis de Controlo VPS, confirme que as portas necessárias do painel de controlo estão na lista de permissões antes de aplicar uma política padrão restritiva.
• Teste a configuração permanente executando firewall-cmd --reload e verificando imediatamente que todos os serviços críticos permanecem acessíveis.
• Documente cada zona personalizada, regra rica e definição de serviço no controlo de versões juntamente com o seu código de infraestrutura.

FAQ

Qual é a diferença entre --reload e sudo systemctl restart firewalld?

--reload aplica alterações de configuração permanentes ao daemon em execução sem interromper as ligações estabelecidas. systemctl restart reinicia completamente o processo do daemon, o que limpa todas as regras netfilter e interrompe brevemente as ligações ativas. Prefira sempre --reload em sistemas de produção.

O Firewalld e o iptables podem coexistir no mesmo servidor?

Não de forma segura na mesma interface. O Firewalld gere as suas próprias cadeias netfilter; os comandos iptables diretos que modificam as mesmas cadeias serão substituídos na próxima recarga do Firewalld. Se precisar de injetar regras personalizadas, utilize a interface --direct do Firewalld ou regras ricas.

Como posso tornar uma regra em tempo de execução permanente sem a redigitar?

Não existe um comando integrado para promover todas as regras em tempo de execução para permanentes num único passo. O fluxo de trabalho correto é aplicar cada regra duas vezes — uma sem --permanent para teste, depois com --permanent para persistência — seguido de --reload. Em alternativa, utilize firewall-cmd --runtime-to-permanent (disponível no Firewalld 0.9+) para criar um instantâneo do estado em tempo de execução atual para o disco.

Por que a minha atribuição de zona é reposta após uma reconexão do NetworkManager?

O NetworkManager armazena as atribuições de zona nos seus próprios perfis de ligação. Uma atribuição firewall-cmd --change-interface é uma substituição em tempo de execução que o NetworkManager pode sobrescrever. Persista a atribuição com nmcli connection modify <profile-name> connection.zone <zone>.

O Firewalld suporta IPv6?

Sim. O Firewalld gere regras netfilter IPv4 e IPv6 simultaneamente. As regras ricas requerem o atributo family="ipv6" para direcionar especificamente o tráfego IPv6. As regras de zona e serviço aplicam-se a ambas as famílias de endereços por padrão, a menos que a definição de serviço ou a regra rica restrinja o âmbito.