O firewalld no CentOS é um gerenciador de firewall dinâmico que organiza regras por zonas, permite testar alterações em runtime e depois torná-las permanentes com segurança. Use firewall-cmd, mantenha sessão SSH reserva e verifique o backend (nftables/iptables) para evitar conflitos e perda de acesso.
firewalld no CentOS é a forma moderna e dinâmica de controlar o tráfego do servidor — mas como evitar um bloqueio acidental e configurar zonas, serviços e portas corretamente? Neste guia prático você vai entender os conceitos essenciais e receber passos testados para aplicar mudanças com segurança.
O que é o firewalld e por que usar no CentOS
firewalld é um gerenciador de firewall dinâmico e moderno usado no CentOS.
Ele organiza regras em zonas, o que facilita o controle do tráfego.
Zonas permitem separar redes e aplicar políticas diferentes por interface de forma simples.
As mudanças podem ser temporárias (runtime) ou permanentes, com reload seguro posterior.
Alterações runtime aplicam-se de imediato e não exigem reinício do serviço.
Isso permite testar regras sem risco de interromper conexões essenciais do servidor.
Use firewall-cmd no terminal para adicionar portas, serviços e regras rápidas.
Para quem prefere interface gráfica, existe o firewall-config em algumas distribuições.
Uma boa prática é manter uma sessão SSH de emergência antes de testar mudanças remotas.
Abra apenas as portas necessárias, como 80 e 443 para servidores web.
Seja cuidadoso ao misturar firewalld com iptables para evitar conflitos inesperados.
No CentOS mais recente, firewalld costuma operar bem com backend nftables quando disponível.
Dica prática: use zonas, teste no runtime e salve apenas quando tiver validado tudo.
Instalando e ativando o firewalld para iniciar no boot
firewalld é fácil de instalar no CentOS usando o gerenciador de pacotes.
Em CentOS 7 e 8 você pode usar yum ou dnf para instalar.
Execute no terminal:
sudo yum install -y firewalldDepois habilite e inicie o serviço para rodar agora e no boot.
Use o comando:
sudo systemctl enable --now firewalldConfirme o estado com:
sudo systemctl status firewalldou
firewall-cmd --stateMantenha sempre uma sessão SSH ativa antes de testar regras remotamente.
No servidor com interface gráfica, instale firewall-config para gestão visual.
Se preferir separar ações, use
sudo systemctl enable firewallde depois
sudo systemctl start firewalld.
Para atualizar o pacote, rode:
sudo dnf update firewalldVerifique que o serviço iniciou após reiniciar o sistema para garantir o boot.
firewalld vs iptables: diferenças e quando evitar misturar
firewalld e iptables protegem suas conexões, mas funcionam bem diferente.
O firewalld usa zonas para aplicar regras por nível de confiança.
Zonas tornam simples permitir serviços para redes conhecidas.
O iptables usa tabelas e cadeias, aplicando regras numa ordem fixa.
Isso dá controle fino, mas exige cuidado com a sequência das regras.
Outra diferença é o backend: firewalld pode usar nftables como base.
Já iptables pode rodar em modo legado sobre o netfilter clássico.
Misturar os dois pode gerar regras conflitantes ou regras apagadas ao reiniciar.
Regras diretas com iptables podem ser sobrescritas pelo firewalld a qualquer momento.
Isso complica o diagnóstico quando o tráfego não passa como esperado.
Evite misturar em servidores de produção ou em ambientes críticos.
Se precisar usar iptables direto, documente tudo e teste em ambiente isolado.
Checar o backend ajuda a decidir: use comandos para ver qual está ativo.
Prefira administrar com firewall-cmd se já usa firewalld no sistema.
Para ver regras do firewalld, execute
firewall-cmd --list-allPara inspecionar o iptables, use
sudo iptables -L -nSe for migrar, faça a migração em janela de manutenção e mantenha sessão SSH reserva.
Entendendo zonas: níveis de confiança e aplicações práticas
firewalld organiza regras em zonas para definir níveis de confiança na rede.
As zonas aplicam políticas diferentes conforme a interface ou a origem do tráfego.
Uma zona com mais confiança permite mais serviços e portas abertas por padrão.
Já zonas restritas bloqueiam conexões não autorizadas sem aviso prévio.
Zonas comuns
- public: uso geral, restrito e ideal para servidores públicos.
- home: redes domésticas com confiança moderada e serviços de compartilhamento.
- work: redes empresariais com mais serviços permitidos que public.
- internal: rede interna da empresa, para serviços backend e banco de dados.
- trusted: abre quase tudo, só use em redes muito seguras.
- drop: descarta pacotes sem resposta; útil para portas sensíveis.
- block: rejeita conexões com resposta, para controle explícito de acesso.
Atribuir uma interface à zona muda automaticamente as regras aplicadas a ela.
Use
firewall-cmd --zone=home --change-interface=eth0para testar rapidamente a mudança.
Lembre que mudanças runtime não são permanentes por padrão.
Para salvar, use
firewall-cmd --runtime-to-permanentou adicione a flag –permanent ao comando.
Permita serviços por zona, não por interface, quando quiser controle mais claro.
Exemplo: servidores web ficam em public com portas 80 e 443 liberadas.
Banco de dados deve ficar em internal ou trusted, não em public.
Evite dar confiança excessiva a zonas sem monitoramento e logs ativos.
Teste sempre em runtime antes de persistir mudanças no sistema.
Mantenha uma sessão SSH reserva ao alterar zonas remotamente no servidor.
Zonas pré-definidas: do drop ao trusted (casos de uso)
firewalld oferece zonas pré-definidas que facilitam aplicar políticas por interface com segurança.
A zona drop descarta pacotes sem responder, útil contra scanners e ataques automáticos.
Use drop para portas sensíveis ou serviços que não devem responder externamente.
A zona block rejeita conexões e informa que o acesso foi negado ao remetente.
public é a zona padrão para servidores expostos com regras moderadas por padrão.
home e work permitem mais serviços, boas para redes familiares e empresariais internas.
internal isola recursos internos, ideal para bancos de dados e serviços backend críticos.
trusted abre quase tudo; use-a só em redes muito seguras e monitoradas.
- Web server: configure a zona public e abra só as portas 80 e 443.
- Database: coloque em internal ou trusted e bloqueie acessos externos não autorizados.
- IoT: use drop ou block para dispositivos inseguros sem serviços públicos expostos.
- Admin: mantenha SSH numa zona separada e use trusted apenas em rede segura.
Altere rapidamente a zona de uma interface para testar comportamento em runtime.
sudo firewall-cmd --zone=home --change-interface=eth0Teste todas as regras no runtime antes de torná-las permanentes no sistema.
sudo firewall-cmd --runtime-to-permanentVerifique o estado atual da zona com list-all para confirmar as configurações aplicadas.
firewall-cmd --zone=public --list-allPlaneje as zonas conforme risco e exposição dos serviços, e documente cada mudança.
Mantenha sempre uma sessão SSH de emergência quando alterar zonas remotamente no servidor.
Runtime vs permanente: testar antes de salvar mudanças
firewalld oferece dois modos: runtime e permanente, que controlam como regras são salvas.
O modo runtime aplica mudanças na hora, mas elas somem após reiniciar o serviço.
O modo permanente grava regras nos arquivos do sistema e persiste após reinicializações.
É comum testar em runtime primeiro para evitar travar conexões críticas do servidor.
Use runtime para validar portas e serviços antes de torná-los permanentes no sistema.
sudo firewall-cmd --add-port=2222/tcpEsse comando abre a porta apenas no runtime, sem gravar a alteração.
sudo firewall-cmd --permanent --add-port=2222/tcpPara salvar mudanças testadas, converta runtime para permanente com runtime-to-permanent.
sudo firewall-cmd --runtime-to-permanent sudo firewall-cmd --reloadOutra abordagem é usar –permanent direto e depois usar –reload para aplicar.
Sempre mantenha uma sessão SSH reserva antes de testar regras remotamente no servidor.
Cheque o estado com firewall-cmd --state e liste regras com --list-all.
Testar antes de salvar reduz riscos e facilita correções sem emergência.
Como checar a zona padrão e interfaces ativas
Para checar a zona padrão use o comando abaixo no terminal.
firewall-cmd --get-default-zoneEle retorna o nome da zona usada por padrão no sistema.
Para ver as zonas ativas e as interfaces vinculadas, rode este comando.
firewall-cmd --get-active-zonesO resultado lista cada zona e as interfaces atribuídas a ela.
Para listar as interfaces de uma zona específica, use:
firewall-cmd --zone=public --list-interfacesSe quiser checar as interfaces permanentes, adicione a flag --permanent ao comando.
firewall-cmd --permanent --zone=public --list-interfacesPara mudar a zona de uma interface temporariamente, execute:
sudo firewall-cmd --zone=home --change-interface=eth0Se quiser aplicar a mudança para sempre, repita com --permanent e recarregue.
sudo firewall-cmd --permanent --zone=home --change-interface=eth0 sudo firewall-cmd --reloadMantenha sempre uma sessão SSH de emergência antes de alterar zonas remotamente.
Verifique o estado do serviço com firewall-cmd --state e systemctl status firewalld.
Use firewall-cmd --list-all para ver todas as regras aplicadas na zona.
Explorando a configuração padrão do public e home
firewalld organiza zonas e define regras padrão para diferentes ambientes de rede.
A zona public serve para servidores expostos e aceita poucas exceções por padrão.
No public, serviços como HTTP e HTTPS são tipicamente liberados com cuidado.
A zona home assume mais confiança e permite serviços locais de compartilhamento.
No home você costuma ver descoberta de dispositivos e compartilhamento de arquivos locais.
Ambas as zonas trazem regras pré-configuradas que cobrem casos de uso frequentes.
Para ver as regras aplicadas, rode firewall-cmd --zone=public --list-all no terminal do sistema.
Use --permanent para checar as regras salvas no disco, não apenas temporárias.
Teste em runtime para validar antes de tornar mudanças permanentes no servidor.
Mantenha sempre uma conexão SSH reserva ao alterar zonas remotamente no servidor.
Exemplo prático: deixe o servidor web em public e dispositivos locais em home.
Documente cada alteração e verifique acesso aos serviços após qualquer mudança.
Atribuindo interfaces a zonas: mudar temporariamente e permanentemente
firewalld permite atribuir interfaces a zonas temporária e permanentemente no sistema.
Para mudar imediatamente sem gravar, use este comando no terminal do servidor.
sudo firewall-cmd --zone=home --change-interface=eth0Essa alteração vale só até reiniciar o serviço ou o sistema operacional.
Para tornar a alteração permanente, adicione a flag --permanent ao comando.
sudo firewall-cmd --permanent --zone=home --change-interface=eth0Depois recarregue as regras para aplicar as mudanças salvas no arquivo do firewall.
sudo firewall-cmd --reloadVocê pode converter o estado runtime para permanente com um comando simples.
sudo firewall-cmd --runtime-to-permanentVerifique a zona ativa e interfaces antes e depois de qualquer mudança com estes comandos.
firewall-cmd --get-active-zones firewall-cmd --zone=home --list-interfacesMantenha sempre uma sessão SSH de emergência aberta durante alterações remotas no servidor.
Testar em runtime ajuda a evitar bloqueios e confirma que os serviços continuam acessíveis.
Alterando a zona padrão do sistema com segurança
firewalld permite alterar a zona padrão com comandos simples e seguros.
Antes de mudar, confira a zona atual com este comando no terminal.
firewall-cmd --get-default-zoneTeste a nova zona em runtime antes de gravar alterações permanentes.
sudo firewall-cmd --set-default-zone=homeVerifique o resultado e as regras aplicadas com list-all para a zona nova.
firewall-cmd --zone=home --list-allSe tudo estiver OK, torne a mudança permanente com a flag –permanent.
sudo firewall-cmd --permanent --set-default-zone=home sudo firewall-cmd --reloadOutra opção é usar runtime-to-permanent após validar no runtime.
sudo firewall-cmd --runtime-to-permanentMantenha sempre uma sessão SSH alternativa antes de aplicar mudanças remotas.
Confirme que o SSH está permitido na nova zona para evitar bloqueios.
firewall-cmd --zone=home --list-servicesFaça backup das configurações em /etc/firewalld antes de alterar zonas críticas.
sudo cp -r /etc/firewalld /root/firewalld-backup-$(date +%F)Documente a mudança e monitore logs após aplicar a nova zona padrão.
Se algo der errado, restaure o backup ou use console de emergência para recuperar o acesso.
Permitindo serviços com –add-service e verificações
firewalld permite liberar serviços usando comandos simples no terminal do servidor remoto.
Use o comando --add-service para liberar um serviço no runtime primeiro rapidamente.
Exemplo: para HTTP e HTTPS em runtime, execute estes comandos no terminal agora.
sudo firewall-cmd --add-service=http sudo firewall-cmd --add-service=httpsDepois de testar bem, torne as mudanças permanentes com a flag --permanent.
sudo firewall-cmd --permanent --add-service=http sudo firewall-cmd --permanent --add-service=https sudo firewall-cmd --reloadVerifique os serviços liberados na zona com --list-services para confirmar as regras.
firewall-cmd --zone=public --list-servicesUse --zone=public --list-all para ver serviços, portas e outras configurações da zona.
Tenha cuidado com SSH e mantenha sempre uma sessão reserva antes de testar remotamente.
Se precisar de um serviço personalizado, crie um arquivo XML no diretório de serviços.
Depois de criar o serviço, carregue-o com --add-service ou recarregue o firewalld.
Sempre teste em runtime antes de salvar regras permanentes para evitar bloqueios inesperados.
Documente as alterações e verifique logs se o tráfego não responder como esperado.
Abrindo portas e ranges com –add-port (tcp/udp)
firewalld permite abrir portas específicas para controlar o tráfego de rede.
Use --add-port para liberar portas no modo runtime de forma imediata.
Exemplo para abrir a porta 8080 TCP temporariamente no servidor.
sudo firewall-cmd --add-port=8080/tcpPara salvar a regra use a flag --permanent e recarregue o serviço.
sudo firewall-cmd --permanent --add-port=8080/tcp sudo firewall-cmd --reloadVocê também pode liberar um range de portas como 1000-2000 para TCP.
sudo firewall-cmd --add-port=1000-2000/tcp --permanentPara UDP, troque tcp por udp no parâmetro do comando.
Verifique as portas abertas com o comando --list-ports na zona desejada.
firewall-cmd --zone=public --list-portsCuidado ao abrir portas remotas; mantenha uma sessão SSH reserva sempre ativa.
Abra só as portas necessárias e documente cada mudança no servidor.
Testar em runtime evita bloqueios e permite reversão rápida se necessário.
Criando serviços personalizados via arquivos .xml
Criar serviços personalizados no firewalld permite definir portas e protocolos sem confusão.
Os arquivos ficam em /etc/firewalld/services e precisam ter extensão .xml, nome e sintaxe corretos.
Um exemplo simples mostra como declarar o serviço e a porta necessária.
<?xml version="1.0" encoding="utf-8"?> <service> <short>Meu Serviço</short> <description>Serviço exemplo que abre a porta 1234/tcp</description> <port protocol="tcp" port="1234"/> </service>No XML, use <short> para o nome curto e <port> para porta e protocolo.
Salve o arquivo com nome descritivo, por exemplo meu-servico.xml no diretório apropriado.
Recarregue o firewalld para que o serviço novo seja reconhecido pelo daemon.
sudo firewall-cmd --reloadAdicione o serviço com firewall-cmd –add-service=meu-servico para testar em runtime rapidamente, sem gravar.
sudo firewall-cmd --add-service=meu-servicoSe tudo funcionar, torne permanente usando –permanent e recarregue o serviço do firewall.
sudo firewall-cmd --permanent --add-service=meu-servico sudo firewall-cmd --reloadDocumente o novo serviço e verifique logs se o tráfego não estiver passando como esperado.
Criar serviços personalizados ajuda a manter regras claras e fáceis de auditar no sistema.
Valide o XML com ferramentas como xmllint se quiser confirmar a sintaxe do arquivo.
Criando zonas customizadas e aplicando políticas específicas
Você pode criar zonas customizadas no firewalld para políticas específicas de rede.
Uma zona customizada isola serviços e regras sem afetar as zonas padrão.
Crie a zona temporária com o comando abaixo para testar antes de salvar.
sudo firewall-cmd --new-zone=dmzDepois defina regras no runtime, por exemplo liberar portas ou serviços específicos.
sudo firewall-cmd --zone=dmz --add-service=httpPara portas, use o formato porta/protocolo, como 3306/tcp para MySQL.
sudo firewall-cmd --zone=dmz --add-port=3306/tcpTeste tudo em runtime e confirme que os serviços respondem como esperado.
Quando validar as regras, torne-as permanentes com a flag –permanent e recarregue.
sudo firewall-cmd --permanent --new-zone=dmz sudo firewall-cmd --permanent --zone=dmz --add-service=http sudo firewall-cmd --reloadVocê pode editar o arquivo XML em /etc/firewalld/zones/dmz.xml para ajustes finos.
Documente as políticas, registre quem alterou e quando para auditoria futura.
Mantenha sempre uma sessão SSH reserva antes de aplicar mudanças remotas no servidor.
Use logs e monitoramento para garantir que as regras funcionam como esperado depois.
Erro comum: regras permanentes sem reload e como corrigir
Um erro comum é usar –permanent e esquecer de recarregar o serviço.
As regras ficam gravadas no disco, mas não entram em vigor imediatamente.
Para aplicar as mudanças, execute no terminal:
sudo firewall-cmd --reloadSe testou em runtime e quer salvar o estado atual, use este comando.
sudo firewall-cmd --runtime-to-permanentAo adicionar regra permanentemente, faça assim e depois recarregue o firewall.
sudo firewall-cmd --permanent --add-port=1234/tcp sudo firewall-cmd --reloadVerifique regras permanentes com o comando abaixo para confirmar a configuração salva.
sudo firewall-cmd --permanent --list-allCheque as regras ativas separadamente com firewall-cmd --list-all no runtime.
Mantenha sempre uma sessão SSH reserva antes de testar mudanças remotas no servidor.
Se perder acesso, restaure backup dos arquivos em /etc/firewalld ou use console físico.
Documente cada alteração e registre quem aplicou e quando no servidor.
Testar em runtime antes de salvar reduz riscos e facilita reverter se necessário.
Evitar travar SSH: perguntas, teste e manter sessão de backup
firewalld pode bloquear o acesso SSH se regras forem aplicadas sem cuidado.
Antes de mudar regras, pergunte: tenho sessão local ou acesso de console?
Mantenha sempre uma sessão SSH reserva antes de testar alterações remotamente.
Abra uma segunda conexão SSH em outra janela ou em outro host confiável.
Use comandos em runtime para testar mudanças sem gravar no sistema.
Por exemplo, rode este comando em runtime para abrir uma porta temporária.
sudo firewall-cmd --add-port=2222/tcpTestes devem confirmar que a nova porta aceita conexões SSH antes de salvar.
Se a conexão funcionar, salve as regras permanentemente ou converta o estado runtime.
sudo firewall-cmd --permanent --add-port=2222/tcp sudo firewall-cmd --reloadVerifique se o SSH está permitido na zona atual antes de qualquer alteração.
firewall-cmd --zone=public --list-servicesTenha comandos de rollback prontos para usar em emergência, como remover porta.
sudo firewall-cmd --remove-port=2222/tcp sudo firewall-cmd --reloadUse console físico ou acesso de out-of-band se perder a conexão SSH principal.
Documente cada teste, mantenha logs e anote quem aplicou as mudanças.
Diagnóstico final: nftables, conflitos com iptables e checklist de verificação
Para diagnosticar conflitos, verifique primeiro qual backend o firewalld está usando no sistema.
Rode no terminal:
firewall-cmd --statee depois verifique o backend com
firewall-cmd --info-backend.
Se o backend for nftables, inspecione o conjunto de regras com o comando nft.
sudo nft list rulesetSe usar iptables, liste as regras com um comando simples para inspeção.
sudo iptables -L -nVerifique se existem shims como iptables-nft que traduzem regras entre os backends.
Conflitos aparecem quando regras são aplicadas por ambas as ferramentas ao mesmo tempo.
Isso pode causar bloqueios inesperados ou regras que somem após reinício do sistema.
Checklist rápido: verifique firewalld ativo, backend, regras nft, regras iptables e serviços.
Faça backup antes de alterar qualquer arquivo em /etc/firewalld ou regras atuais.
Se decidir migrar para nftables, converta regras iptables e remova duplicações com cuidado.
Use comandos de teste em runtime antes de salvar mudanças permanentemente no sistema.
Ao corrigir, limpe regras antigas, reinicie o firewalld e valide o tráfego com testes.
Monitore logs em /var/log/messages ou com journalctl para identificar erros do firewall.
Se não tiver certeza, mantenha um plano de rollback e peça ajuda de um colega experiente.
Resumo e recomendações finais
firewalld facilita o gerenciamento de firewall no CentOS com zonas e comandos simples.
Teste sempre em runtime antes de salvar mudanças permanentes no sistema.
Mantenha uma sessão SSH reserva, documente alterações e faça backups regulares.
Verifique conflitos entre nftables e iptables, e prefira um único backend quando possível.
Com boas práticas, é possível proteger serviços sem interromper o acesso remoto.
FAQ – Perguntas frequentes sobre firewalld no CentOS
O que é o firewalld e por que devo usar?
O firewalld é um gerenciador de firewall dinâmico que usa zonas. Ele facilita aplicar políticas por interface e testar mudanças sem reiniciar o serviço.
Qual a diferença entre firewalld e iptables?
firewalld usa zonas e abstrações; iptables trabalha com tabelas e cadeias. Misturar os dois pode causar conflitos e regras inesperadas.
Como evito travar o SSH ao aplicar regras?
Mantenha uma sessão SSH reserva, teste em runtime e só salve quando confirmar que o acesso continua funcionando.
Como salvo mudanças de runtime para permanente?
Use –permanent ao adicionar regras e rode sudo firewall-cmd –reload. Ou converta com sudo firewall-cmd –runtime-to-permanent.
Como criar um serviço personalizado no firewalld?
Crie um arquivo XML em /etc/firewalld/services com a porta e protocolo, recarregue o firewalld e adicione o serviço.
Como checar a zona padrão e interfaces ativas?
Use firewall-cmd –get-default-zone para a zona padrão e firewall-cmd –get-active-zones para ver interfaces e zonas ativas.
