A alteração da regra da firewall não funciona: ordem das regras e estado da ligação

Alterou a regra, recarregou o conjunto de regras e o túnel comporta-se exatamente como antes. Esse resultado tem duas causas comuns, e exigem testes diferentes. Ou a nova regra fica depois de uma regra anterior que já aceitou o pacote, ou a troca que está a observar é uma ligação rastreada que a alteração nunca reavalia. Uma regra num ficheiro exprime intenção; o que decide o pacote é o caminho ativo que ele encontra. Percorra as verificações abaixo por ordem e mantenha um caminho de volta enquanto o faz.

A ordem das regras e o estado da ligação são falhas diferentes

As cadeias ordenadas são avaliadas de cima para baixo, e a primeira regra que chega a um veredicto final termina a passagem por essa cadeia. Coloque uma aceitação ampla acima de uma regra de bloqueio escrita com cuidado e a regra de bloqueio torna-se documentação: está no conjunto de regras, o contador está a zero e nenhum pacote chegará alguma vez a ela. O mesmo texto aplicado a outra cadeia também não prova nada. No nftables, as cadeias base ligam-se a hooks por prioridades, por isso uma aceitação numa cadeia não impede outra cadeia num hook ou prioridade diferentes de ver o mesmo pacote.

O rastreio de ligações produz o segundo sintoma, e de fora parece idêntico. Assim que um fluxo está na tabela de estados, uma aceitação para established-or-related perto do topo da cadeia regressa antes de a nova regra ser consultada. Os mapeamentos NAT têm a mesma propriedade: a tradução foi fixada quando o fluxo começou, por isso uma regra de postrouting editada não reescreve uma sessão que já está a correr. É por isso que uma alteração parece funcionar às 09:00 para uma ligação nova e parece não fazer nada para a sessão que alguém abriu às 08:55.

Os grupos de segurança da nuvem acrescentam um terceiro modelo que apanha quem aprendeu com iptables. As suas regras de entrada são uma lista de permissões avaliada como conjunto em vez de uma passagem pela primeira correspondência, são stateful, e remover uma regra de permissão não termina fluxos que já estão a ser rastreados. Assumir semântica de primeira correspondência numa plataforma que não a tem leva a conclusões confiantes e erradas.

Leia o conjunto de regras ativo, não o ficheiro que editou

Comece pelo que o kernel está a aplicar agora. Uma configuração guardada que nunca foi aplicada explica um número surpreendente de comportamentos inalterados, e excluí-la custa um único comando:

nft list ruleset
iptables-save

Depois pergunte se a sua regra chega a ser atingida. Os contadores de pacotes respondem a isso diretamente, e respondem melhor do que qualquer raciocínio sobre a intenção:

iptables -L FORWARD -v -n --line-numbers
nft list chain inet filter forward

Uma regra de bloqueio com zero pacotes depois de uma tentativa de teste real não é um problema de política, é um problema de posição. Movê-la é uma alteração de uma linha, e a sintaxe é exatamente o que causou o erro original. Com iptables, -I insere e -A acrescenta no fim; com nftables, insert coloca uma regra no início da cadeia enquanto add acrescenta no fim. Quando uma regra tem de ganhar, diga-o explicitamente em vez de confiar na ordem que foi carregada por acaso.

Prove se o fluxo está a ser rastreado

Antes de culpar a regra, verifique se o tráfego é sequer uma ligação rastreada. Pergunte à tabela de estados pelo fluxo concreto em vez de a despejar toda:

conntrack -L -p tcp --dport 1194
conntrack -E -p tcp --dport 1194

A listagem mostra o estado e o tempo de espera restante, e é assim que distingue uma sessão estabelecida de uma tentativa nova; o modo de eventos imprime atualizações à medida que acontecem, o que é útil enquanto volta a ligar um cliente. Se o fluxo estiver presente com estado estabelecido antes de tocar em alguma coisa, nenhuma edição das regras de filtro mudará o seu destino. Isso não é um erro da firewall, é o contrato da filtragem com estado.

Resista ao atalho de esvaziar a tabela inteira num gateway de produção. conntrack -F está disponível, e também destrói cada fluxo rastreado na máquina, incluindo a sessão de gestão a partir da qual trabalha e o túnel que transporta a sua shell. As entradas individuais podem ser apagadas quando realmente precisa, mas um fluxo novo a partir de uma porta de origem nova costuma ser uma experiência mais limpa.

Alguns caminhos não são rastreados, e comportam-se ao contrário. O tráfego marcado como notrack na tabela raw, alguns túneis que contornam os hooks normais e o encaminhamento assimétrico que divide um fluxo entre dois gateways produzem todos pacotes avaliados um a um, ou um estado que nunca é criado nos dois extremos. Se os contadores se movem a cada pacote, suspeite desse tipo de caminho antes de suspeitar da ordem.

Teste a partir de um fluxo novo com um caminho de volta

Antes de testar uma regra que pode cortar o acesso remoto, estabeleça um caminho de recuperação: a consola do fornecedor, uma consola série, um endereço de gestão fora de banda ou uma segunda interface que a regra não consiga corresponder. Um temporizador de reversão é um companheiro razoável, pois restaurará o conjunto de regras anterior mesmo que a sua sessão morra a meio do teste.

Depois teste com uma troca que o estado não pudesse já ter coberto. Desligue e volte a ligar o cliente para que seja criada uma nova quíntupla, e observe ambos os extremos enquanto isso acontece:

tcpdump -ni eth0 'tcp port 1194'
journalctl -k -n 50 --no-pager

Execute o teste nos dois sentidos. Uma regra que bloqueia o novo handshake de entrada pode ainda permitir o caminho de resposta, ou o contrário, e um resultado unidirecional é a razão habitual para um bloqueio funcionar apenas a meio. Volte a ligar uma vez após o teste para confirmar o estado estacionário, e verifique se o acesso de gestão legítimo sobreviveu; uma regra escrita para uma porta tem o hábito de corresponder a um intervalo mais amplo do que o pretendido.

Registe o propósito e a posição junto com a regra

Uma regra sem um propósito registado é uma regra que ninguém ousa remover. Ao lado de cada entrada de bloqueio, guarde o fluxo que protege, a cadeia e o hook em que vive, a posição que tem de manter em relação às aceitações mais amplas e o teste que o provou. Quando alguém editar o conjunto de regras em volta seis meses depois, essa nota é o único aviso de que a posição era deliberada.

Antes de fechar a alteração, confirme quatro coisas: o conjunto de regras em execução corresponde ao ficheiro, a nova regra tem contadores diferentes de zero após uma tentativa nova, o sentido inverso e o acesso de gestão ainda funcionam, e voltou a ligar-se uma vez para provar o estado estacionário em vez do estado de uma sessão anterior à alteração. Se algo disso não estiver verificado, a alteração não está terminada, faça o que fizer o túnel.