Introdução
As regras adicionadas com o comando iptables alteram o firewall do kernel em execução, mas uma alteração aplicada apenas ao ambiente ativo não constitui uma configuração persistente. Os administradores normalmente serializam as regras IPv4 com iptables-save e recarregam esse formato com iptables-restore. Em sistemas Debian e Ubuntu, /etc/iptables/rules.v4 é um arquivo convencional de persistência quando há um carregador apropriado habilitado durante a inicialização.
Pense nesse fluxo como três camadas distintas. O conjunto de regras ativo corresponde ao que o kernel aplica no momento. Um arquivo de regras salvo é apenas texto armazenado em disco até que alguma ferramenta ou serviço o restaure. Um backup de referência representa um ponto inicial conhecido, mantido para permitir uma reversão. Alterar uma camada não atualiza silenciosamente as outras duas; por isso, os administradores precisam salvar, restaurar e verificar cada transição de forma deliberada.
Neste laboratório, você preservará o firewall original como ponto de reversão, adicionará e salvará uma regra específica para um serviço, validará o arquivo salvo antes de aplicá-lo, simulará a recarga do conjunto de regras e, por fim, restaurará o estado original. Esse fluxo separa três estados importantes: as regras ativas, o arquivo de regras salvo e a cópia usada para reversão.
Fazer backup do firewall IPv4 ativo
Nesta etapa, você registrará o estado inicial do firewall antes de fazer qualquer alteração. Um arquivo de reversão fornece um estado conhecido e válido caso os comandos posteriores não se comportem como esperado.
Acesse o diretório do projeto.
cd /home/labex/project
Confirme se o serviço de teste está disponível antes de alterar as regras.
curl --noproxy '*' --fail --silent http://127.0.0.1:18087/status
Este é um teste de controle. 127.0.0.1 usa a interface de loopback, --noproxy '*' mantém a solicitação local mesmo que variáveis de proxy estejam configuradas, e --fail --silent produz uma resposta limpa com um status de saída confiável. Estabelecer uma referência funcional facilita a interpretação do comportamento do firewall posteriormente.
Use iptables-save para exibir o conjunto completo de regras IPv4. O pipe envia essa saída para tee, que grava baseline.v4 e, ao mesmo tempo, permite executar o comando com a conta normal do laboratório.
sudo iptables-save | tee baseline.v4 >/dev/null
A separação de privilégios é intencional: sudo iptables-save lê o conjunto de regras protegido do kernel, enquanto o tee sem privilégios grava no diretório do projeto. O redirecionamento final envia para /dev/null a saída duplicada que o tee exibiria na tela; ele não esvazia o arquivo. O backup resultante contém todas as tabelas e cadeias IPv4 serializadas informadas por este host, e não apenas a regra que será adicionada mais tarde.
Inspecione o início do arquivo salvo.
head -n 12 baseline.v4
Os contadores exatos podem variar, mas o arquivo usa o formato de iptables-restore, organizado em seções de tabelas. Uma seção filter mínima se parece com:
*filter
:INPUT ACCEPT ...
...
COMMIT
Cada seção começa com um nome de tabela, como *filter, declara suas cadeias e políticas, lista as regras e termina com COMMIT. O iptables-restore aplica uma seção de tabela somente quando alcança esse marcador. Não trate o arquivo como uma lista arbitrária de comandos shell independentes.
Confirme que o arquivo contém um marcador de tabela filter e um marcador de confirmação.
grep -E '^\*filter$|^COMMIT$' baseline.v4
Adicionar e salvar a regra do serviço
Nesta etapa, você adicionará uma regra explícita de permissão ao firewall ativo e salvará o conjunto de regras resultante no caminho convencional de persistência IPv4.
Insira, no início de INPUT, uma regra que aceite tráfego TCP de loopback destinado à porta 18087. As restrições de interface e porta mantêm a regra específica para este exercício.
sudo iptables -I INPUT 1 -i lo -p tcp --dport 18087 -j ACCEPT
INPUT abrange o tráfego destinado ao próprio host. -I INPUT 1 coloca a regra em primeiro lugar, -i lo restringe o tráfego à interface de loopback, -p tcp --dport 18087 seleciona o serviço de teste e -j ACCEPT permite o tráfego correspondente. Uma regra explícita e restrita é mais fácil de auditar e remover do que uma regra ampla que aceite vários serviços.
Verifique a regra ativa. Um status de saída igual a zero significa que a correspondência e o destino exatos existem; a implementação baseada em nftables deste host também exibe uma forma normalizada da regra correspondente.
sudo iptables -C INPUT -i lo -p tcp --dport 18087 -j ACCEPT
Salve o conjunto completo de regras IPv4 ativo. O uso de sudo tee é necessário porque /etc/iptables exige acesso administrativo para gravação.
sudo iptables-save | sudo tee /etc/iptables/rules.v4 >/dev/null
Esse comando cria uma nova cópia do estado depois que a regra foi adicionada. sudo é necessário nos dois lados do pipe por motivos diferentes: o lado esquerdo lê o estado do firewall, enquanto o lado direito abre um arquivo de destino pertencente ao root. Criar rules.v4 não o ativa nem agenda sua aplicação; apenas prepara um arquivo que poderá ser consumido por um comando de restauração ou por um serviço executado durante a inicialização.
Procure a porta do serviço no arquivo salvo. O -- depois de grep encerra o processamento de opções, o que é útil quando o padrão de busca pode começar com um hífen.
sudo grep -- '--dport 18087' /etc/iptables/rules.v4
A saída deve incluir uma regra INPUT terminada em -j ACCEPT. Neste momento, tanto o conjunto de regras ativo quanto o arquivo salvo contêm a regra pretendida.
Evite comparar o novo arquivo byte a byte com o backup de referência. Os contadores de pacotes e as regras mantidas por outros softwares podem mudar legitimamente. Para este exercício, a evidência importante é que a regra pretendida existe tanto no estado ativo quanto no artefato salvo.
Validar e restaurar o conjunto de regras salvo
Nesta etapa, você removerá a regra ativa, validará o arquivo salvo sem aplicá-lo e, em seguida, fará sua recarga. Isso simula a parte essencial de uma restauração durante a inicialização, permanecendo dentro de uma única sessão do laboratório.
Exclua a regra da cadeia INPUT ativa.
sudo iptables -D INPUT -i lo -p tcp --dport 18087 -j ACCEPT
Essa exclusão altera apenas o conjunto de regras atual do kernel. Ela não modifica /etc/iptables/rules.v4, por isso a regra salva poderá ser restaurada em um comando posterior. Essa diferença intencional demonstra a distinção entre o estado ativo e o estado salvo.
Confirme que a regra está ausente. A verificação deve falhar; por isso, || exibe uma mensagem e permite que o fluxo continue.
sudo iptables -C INPUT -i lo -p tcp --dport 18087 -j ACCEPT 2>/dev/null || echo "Live rule is absent"
Antes de aplicar um firewall salvo, use iptables-restore --test. Esse comando analisa o arquivo completo e informa erros de sintaxe sem substituir o conjunto de regras ativo.
sudo iptables-restore --test < /etc/iptables/rules.v4
O operador < faz com que o shell forneça o arquivo como entrada padrão para iptables-restore. Uma saída silenciosa significa que a sintaxe foi aceita; não significa que o arquivo já tenha sido aplicado. A validação é uma verificação de segurança importante, pois um conjunto de regras malformado ou incompleto pode interromper a conectividade quando for restaurado.
Uma validação bem-sucedida termina sem saída. Agora restaure as regras salvas no firewall ativo.
sudo iptables-restore < /etc/iptables/rules.v4
Ao contrário da adição de uma única regra com iptables, iptables-restore processa todas as seções de tabelas presentes no arquivo. Trate-o como uma operação administrativa de alto impacto: valide primeiro, mantenha uma cópia para reversão e verifique imediatamente os acessos essenciais depois da restauração. Neste laboratório controlado, o arquivo salvo foi obtido do mesmo host poucos instantes antes.
Verifique se a regra do serviço voltou.
sudo iptables -C INPUT -i lo -p tcp --dport 18087 -j ACCEPT
Confirme que a aplicação continua acessível após a restauração.
curl --noproxy '*' --fail --silent http://127.0.0.1:18087/status
Reverter para o estado original
Nesta etapa, você usará o backup da Etapa 1 para remover a alteração do laboratório do firewall ativo, mantendo o conjunto de regras de destino salvo disponível para inspeção.
Valide o estado de referência antes de aplicá-lo.
sudo iptables-restore --test < baseline.v4
Aqui, baseline.v4 e /etc/iptables/rules.v4 têm propósitos intencionalmente diferentes. O arquivo de referência representa o estado ativo original, enquanto rules.v4 representa o estado de destino que contém a regra do serviço. Restaurar um arquivo não modifica o outro.
Restaure o conjunto de regras ativo original.
sudo iptables-restore < baseline.v4
Confirme que a regra do laboratório não está mais ativa.
sudo iptables -C INPUT -i lo -p tcp --dport 18087 -j ACCEPT 2>/dev/null || echo "Original firewall baseline restored"
O arquivo de destino salvo é um artefato separado e ainda contém a regra usada no exercício.
sudo grep -- '--dport 18087' /etc/iptables/rules.v4
Essa verificação comprova claramente a separação entre os estados: o firewall ativo foi revertido, mas o artefato de persistência ainda registra a regra de destino. Um administrador poderia restaurá-la novamente mais tarde ou configurar um serviço de persistência para carregá-la durante a inicialização.
Por fim, verifique se o retorno ao estado de referência original, que permite o tráfego, mantém o serviço local acessível.
curl --noproxy '*' --fail --silent http://127.0.0.1:18087/status
Em produção, confirme qual serviço carrega o arquivo de persistência da distribuição durante a inicialização. Por exemplo, sistemas baseados em Debian frequentemente usam um pacote como iptables-persistent juntamente com netfilter-persistent, mas a disponibilidade e as políticas variam de acordo com o host. Salvar um arquivo rules.v4 correto prepara o conjunto de regras; a existência e a habilitação de um carregador determinam se ele será restaurado automaticamente.
Resumo
Você fez backup do firewall IPv4 ativo, adicionou e salvou uma regra específica para o serviço, validou o conjunto de regras serializado com iptables-restore --test, recarregou-o no kernel e reverteu para o estado de referência original. Você também distinguiu o firewall ativo de seus arquivos salvos de persistência e de reversão — um hábito essencial antes de alterar ou restaurar o estado de filtragem de pacotes.
