Rocky Linux / Como configurar firewalld: zonas, serviços e portas

O Rocky Linux usa firewalld como seu serviço padrão de gerenciamento de firewall, e o comando firewall-cmd gerencia zonas, serviços, portas e regras baseadas em origem. Em um servidor remoto, uma sequência prudente é testar uma alteração na configuração em tempo de execução mantendo a sessão SSH atual aberta, verificar uma nova conexão e somente então salvar a regra permanentemente.

Os exemplos exigem uma máquina Rocky Linux com firewalld instalado, ferramentas de rede e uma conta autorizada a usar sudo. SSH (Secure Shell) é o acesso remoto usado neste guia. Substitua public pela zona que realmente recebe o tráfego; nomes de conexão, endereços e portas são exemplos, não uma configuração universal. Em uma máquina remota, mantenha uma segunda forma de acesso ao console.

Este guia explica os comandos necessários para a administração rotineira do firewall do Rocky Linux e as verificações que ajudam a prevenir um bloqueio acidental.

Verificar o estado de firewalld e as zonas ativas

sudo firewall-cmd --state
sudo systemctl status firewalld
sudo firewall-cmd --get-active-zones
sudo firewall-cmd --get-default-zone

Quando o serviço está funcionando, --state informa running. As consultas de zonas mostram nomes, interfaces e origens; anote a associação que será alterada. systemctl status pode abrir um paginador, encerrado com q. Se firewalld estiver parado, não trate uma falha de consulta como uma configuração vazia.

Uma zona do firewalld é uma coleção de regras associadas a um nível de confiança. Uma zona pode ser atribuída a uma interface de rede, uma conexão do NetworkManager ou um endereço de origem. Verifique as zonas ativas antes de fazer alterações, porque omitir --zone pode modificar a zona padrão em vez da zona que lida com o tráfego que você pretende controlar.

Se uma interface não aparecer onde você espera, inspecione a conexão ativa do NetworkManager antes de adicionar regras. Uma regra correta na zona errada não permitirá o tráfego pretendido.

Iniciar firewalld e habilitar na inicialização

enable --now habilita o início automático e também inicia o serviço imediatamente. Antes de executar pela rede, confira se a configuração permanente permite a porta SSH real e se existe recuperação por console: iniciar o firewall pode aplicar regras que bloqueiam novos acessos.

sudo systemctl enable --now firewalld

Verifique tanto a configuração de inicialização quanto o estado atual do serviço:

systemctl is-enabled firewalld
systemctl is-active firewalld

Os resultados usuais são enabled para o início automático e active para o serviço em execução. Esses estados são independentes; um serviço pode estar ativo sem estar habilitado para a próxima inicialização.

Não desative todo o firewall em um servidor de produção apenas para tornar uma aplicação acessível. Permita apenas o serviço, porta, protocolo e origem necessários. Em um ambiente de nuvem, lembre-se de que um grupo de segurança, uma lista de controle de acesso de rede ou o firewall do provedor podem bloquear o tráfego independentemente do firewalld.

Diferença entre configuração runtime e permanente

Para um servidor remoto, adicione a regra à configuração de runtime primeiro. Teste a aplicação e abra uma segunda conexão SSH antes de copiar a configuração de runtime funcional para a configuração permanente.

Execute o bloco por etapas: as duas primeiras linhas adicionam e consultam HTTP; a terceira salva a configuração. --runtime-to-permanent copia toda a configuração runtime e sobrescreve a permanente, não apenas a última regra. Revise outras zonas e alterações temporárias antes de salvar.

sudo firewall-cmd --zone=public --add-service=http
sudo firewall-cmd --zone=public --query-service=http
sudo firewall-cmd --runtime-to-permanent

--query-service=http responde yes com estado de saída 0 quando o serviço foi adicionado, ou no e estado 1 quando não foi. Isso confirma a regra, não uma conexão com o servidor web. Teste a aplicação de outra máquina e uma nova sessão SSH antes de executar a linha de gravação.

Se fizer uma alteração com --permanent, revise-a e recarregue o firewalld para ativá-la:

sudo firewall-cmd --reload

Runtime não significa reversão automática após alguns minutos. Para desfazer uma adição deste guia, remova a mesma permissão com --remove-service, --remove-port ou --remove-rich-rule, conforme o caso. Use --reload como retorno à configuração anterior somente se a configuração permanente for conhecida e tiver acesso de administração confirmado; ele também elimina outras alterações runtime não salvas.

Um recarregamento substitui a configuração em tempo de execução pela configuração permanente. Alterações não salvas apenas em tempo de execução, portanto, são perdidas.

Permitir e remover serviços predefinidos

Listar definições de serviço disponíveis

firewall-cmd --get-services
firewall-cmd --info-service=http

Quando o firewalld já define um serviço padrão, como HTTP, HTTPS ou SSH, usar o nome do serviço geralmente comunica o propósito de forma mais clara do que abrir portas individuais. Uma definição de serviço também pode incluir mais de uma porta ou protocolo e componentes auxiliares.

Permitir um serviço na configuração runtime

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

Abrir o firewall não inicia o servidor web. Confirme que a aplicação está em execução e ouvindo no endereço e porta esperados:

ss -lntup

A lista mostra sockets TCP e UDP em escuta e seus endereços. A coluna de processos pode ficar incompleta sem privilégios suficientes. Uma aplicação presa ao endereço de loopback, como 127.0.0.1, não se torna acessível externamente apenas porque a porta foi aberta.

Remover um serviço permitido

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

Antes de remover o acesso SSH em uma máquina remota, confirme que outra regra de acesso testada e um console fora de banda estão disponíveis. Mantenha a sessão SSH existente aberta até que uma nova conexão seja bem-sucedida.

Gerenciar portas personalizadas

Permitir uma porta TCP ou UDP

TCP (Transmission Control Protocol) e UDP (User Datagram Protocol) são protocolos de transporte diferentes. Uma permissão para um deles não abre automaticamente a mesma porta no outro.

sudo firewall-cmd --zone=public --add-port=8443/tcp
sudo firewall-cmd --zone=public --add-port=5000/udp

TCP e UDP exigem regras separadas. Verifique a documentação da aplicação e abra apenas o protocolo e a porta que ela realmente utiliza.

Permitir um intervalo de portas

sudo firewall-cmd --zone=public --add-port=6000-6010/tcp

Antes de abrir um intervalo amplo, confirme o intervalo exato que a aplicação requer. Quando possível, também restrinja o acesso a endereços de origem conhecidos ou a uma rede de gerenciamento dedicada.

Remover e listar portas

sudo firewall-cmd --zone=public --remove-port=8443/tcp
sudo firewall-cmd --zone=public --list-ports

Inspecionar as regras atuais

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

O primeiro comando mostra as regras em tempo de execução para a zona especificada, enquanto o último comando mostra suas regras permanentes. Se os resultados diferirem, o servidor pode se comportar de maneira diferente após a próxima recarga ou reinicialização. Compare ambas as configurações antes de concluir uma alteração de manutenção.

Restringir o acesso a um endereço de origem

Criar uma rich rule para uma origem SSH

Uma rich rule combina condições, como família de endereços e origem, com uma ação. A regra abaixo adiciona uma permissão para a origem indicada; sozinha, não remove permissões gerais de SSH nem garante que outras origens estejam bloqueadas. Confira também a porta definida por firewall-cmd --info-service=ssh; um servidor SSH em porta personalizada pode exigir outra definição ou regra.

sudo firewall-cmd --zone=public --add-rich-rule='rule family="ipv4" source address="192.0.2.10/32" service name="ssh" accept'

A máscara /32 seleciona um único endereço IPv4. A ação accept permite o tráfego que corresponde à origem e ao serviço, conforme a documentação oficial da linguagem de rich rules. Verifique outras permissões por porta, regras, políticas e IPv6 antes de considerar o acesso restrito.

192.0.2.10 é um endereço de documentação, não um endereço para copiar em uma regra de produção. Substitua-o pelo endereço IP público fixo do administrador ou por uma rede interna confiável. Para IPv6, use uma origem IPv6 apropriada e a família correspondente, em vez de copiar o exemplo de IPv4.

Testar antes e depois de remover o acesso geral via SSH

Depois de adicionar a regra específica para a origem, mantenha a sessão atual aberta e estabeleça uma nova conexão SSH a partir do endereço permitido. Verifique o acesso de recuperação do console antes de remover a regra mais ampla do serviço SSH.

sudo firewall-cmd --zone=public --list-rich-rules
sudo firewall-cmd --zone=public --remove-service=ssh

1. Mantenha a sessão atual e o console disponíveis ao remover a permissão geral deste exemplo.
2. Depois da remoção, abra outra conexão a partir da origem permitida. A conexão anterior pode continuar funcionando por estado já estabelecido e não comprova que um novo acesso será aceito.
3. Confira as demais permissões e, em um teste controlado, a resposta a uma origem não permitida. Só então revise e salve a configuração.
4. Se o novo acesso falhar, use a sessão preservada ou o console para restaurar a permissão geral do exemplo com sudo firewall-cmd --zone=public --add-service=ssh e investigue antes de restringir novamente.

Uma restrição de origem pode bloquear o administrador quando seu endereço público mudar. Para acesso estável, use um endereço fixo, uma rede privada virtual (VPN) ou uma rede de administração dedicada.

Associar uma conexão do NetworkManager a uma zona

nmcli connection show --active
firewall-cmd --get-active-zones

Atribuir uma zona a um perfil de conexão do NetworkManager mantém a configuração de rede e a associação à zona do firewalld juntas. Substitua o nome de conexão do exemplo pelo nome exato mostrado por nmcli.

sudo nmcli connection modify 'System eth0' connection.zone public

Para uma conexão já ativa, a documentação do NetworkManager sobre connection.zone informa que essa propriedade entra em vigor imediatamente. Confira com firewall-cmd --get-active-zones; não é necessário reativar a conexão apenas para mudar a zona. Se outras alterações do perfil exigirem reativação, faça isso com console e janela de manutenção.

Se a associação ficar incorreta, restaure o valor anterior de connection.zone no mesmo perfil e confira a zona novamente. Anote esse valor antes da alteração; não suponha que o perfil se chama System eth0 nem que a zona anterior era public.

Como investigar uma conexão bloqueada

1. Execute systemctl is-active firewalld para confirmar que o firewalld está ativo.
2. Use firewall-cmd --get-active-zones para encontrar a zona associada à interface ou origem relevante.
3. Compare a saída em tempo de execução e permanente de --list-all para essa zona.
4. Execute ss -lntup para confirmar que o aplicativo está escutando no endereço, porta e protocolo esperados.
5. Verifique os grupos de segurança na nuvem, firewalls do provedor, listas de controle de acesso do roteador e regras de NAT.
6. Revise as negações do SELinux e os logs da aplicação.

Uma porta aberta no firewalld não garante uma conexão bem-sucedida. A aplicação deve estar em execução e escutando em um endereço acessível, e todas as outras camadas de firewall ou roteamento no caminho também devem permitir o tráfego.

Perguntas frequentes

Por que uma regra adicionada com --permanent não entrou em vigor imediatamente?

Uma regra permanente é armazenada para uso futuro e normalmente se torna ativa após firewall-cmd --reload. Em um servidor remoto, teste primeiro a regra equivalente em tempo de execução, confirme o acesso e então salve-a com --runtime-to-permanent.

Por que um serviço está inacessível mesmo com sua porta aberta?

Verifique a zona ativa, o endereço e protocolo em que a aplicação está escutando, firewalls em nuvem ou em outras partes da rede, NAT e SELinux. O firewalld controla apenas uma camada do caminho de conexão.

Devo usar uma regra de serviço ou uma regra de porta?

Use um serviço predefinido quando ele representar com precisão a aplicação, pois a regra é mais fácil de entender e pode incluir todos os protocolos necessários. Use uma porta e protocolo explícitos para uma aplicação personalizada ou uma porta não padrão.

É seguro parar o firewalld para solução de problemas?

Parar todo o firewall pode expor todos os serviços que estão escutando e é perigoso em um servidor de produção. Inspecione a zona ativa, os logs e as regras atuais, e então faça a menor alteração temporária em tempo de execução necessária para um teste controlado.

Resumo

Um fluxo de trabalho seguro do firewalld no Rocky Linux começa identificando a zona ativa, testando a menor regra de tempo de execução necessária e salvando-a somente após a conexão funcionar. Prefira serviços nomeados para aplicativos padrão, especifique tanto a porta quanto o protocolo para serviços personalizados e compare as regras de tempo de execução com as permanentes antes de finalizar.

Para administração remota via SSH, preserve a sessão atual e um caminho de recuperação de console até que uma segunda conexão seja bem-sucedida. Esta precaução é mais importante do que qualquer opção individual do firewall-cmd.

Referências oficiais

• Documentação do Rocky Linux: firewalld para iniciantes
• Documentação do firewalld: abrir uma porta ou serviço
• Página de manual do firewall-cmd