Testar alterações de firewall sem ficar trancado do lado de fora

A regra entra, o terminal que já tem continua a responder e o próximo login é recusado. Essa lacuna é toda a dificuldade de testar uma alteração de firewall sobre a ligação que está a alterar. O rastreio de ligações decide uma vez e depois deixa de olhar, por isso um fluxo estabelecido é a única sonda que não consegue ver a nova política. O que se segue compara as três vias de regresso e depois fixa a ordem em que se alteram e verificam as regras.

Porque é a sessão sobrevivente a prova mais fraca

Uma firewall com estado avalia o primeiro pacote de um fluxo e mantém esse veredicto enquanto a entrada viver. As regras acrescentadas depois aplicam-se aos fluxos que começam mais tarde, e é por isso que a janela em que escreve continua utilizável enquanto todos os outros são recusados. O que aprende com ela descreve a política que estava em vigor há minutos. Mesmo uma captura feita nesse fluxo mostra uma decisão que a máquina já tomou.

Trate a sessão funcional como uma saída de emergência e não como uma medição. Todas as verificações que valham a pena devem abrir um fluxo novo a partir de uma origem que a nova regra vai avaliar, e a primeira verificação deve ser aquela cuja falha doeria mais. Quando essa sessão é a sua única via de entrada, a alteração não está pronta a ser feita.

Três vias de regresso, ordenadas pelo que cada uma depende

Ordene as opções pelo quanto dependem do dispositivo em teste, porque é a essa ordem que recorre quando a regra se revela errada. Uma consola que nunca passa pela firewall é independente, um retrocesso ensaiado é quase isso, e a sessão já aberta não é.

Antes da alteração, inicie sessão pela consola e prove que funciona, porque uma via fora de banda que nunca usou é um esquema e não um recurso. Um retrocesso só ganha o seu lugar depois de um ensaio nessa plataforma, com esse conjunto de regras, seguindo o procedimento aprovado em vez de improvisar numa máquina em produção. Escreva os passos e peça a outra pessoa que os leia de volta. Se a sequência precisa da sua memória para terminar, não é um plano.

Uma alteração, depois uma ligação que tem de ser avaliada

Guarde o conjunto de regras em execução e o ficheiro que o possui, e faça depois uma única edição estreita. Uma alteração por teste mantém o resultado atribuível; duas ao mesmo tempo deixam-no com uma máquina a funcionar e nenhuma ideia de qual edição fez o trabalho. Onde a plataforma consegue analisar uma configuração sem a carregar, faça isso primeiro, para que um erro de escrita falhe quando nada está em jogo.

nft list ruleset > /root/ruleset.before
nft -c -f /etc/nftables.conf

Depois inicie uma sessão nova a partir de uma origem que a regra alterada vai corresponder, enquanto a consola ainda está ligada. Repita uma vez se tiver êxito, porque a primeira tentativa pode cair numa entrada que a tabela já tinha. Se falhar, ainda tem uma via de entrada e uma decisão a reverter, que é o pior resultado barato disponível.

Os contadores, o estado e o ficheiro respondem a perguntas diferentes

Cada uma das três observações pode parecer convincente por si só e enganá-lo quanto às outras duas. Os contadores mostram se o fluxo que acabou de criar chegou à regra que editou. A tabela de estado mostra que fluxos a máquina considera já estabelecidos, e é assim que uma regra avariada ainda pode parecer saudável. O ficheiro guardado mostra o que o dispositivo fará após a próxima recarga, e pode não ser o que o conjunto de regras em execução está a fazer agora.

ss -tn state established

Leia os contadores como um delta e não como um total, porque o único número que importa é o que o seu fluxo de teste moveu. Uma regra cujo contador nunca aumenta não corresponde, por mais correta que pareça no papel. Confirme também o caso de recusa: uma política que nunca recusou nada nunca provou que recusa o que queria bloquear. Percorra uma interface em cada família que a implementação realmente transporta, porque uma regra v4 não diz nada sobre um fluxo v6.

Restaure a partir do conjunto de regras guardado e depois faça o ficheiro coincidir

Quando a alteração falhar, carregue o conjunto de regras guardado em vez de acrescentar regras permissivas até os logins voltarem a funcionar. Cada autorização extra acalma o sintoma e deixa um buraco que sobrevive ao incidente e à memória dele. Restaure, volte a ligar e depois guarde a comparação falhada ao lado do registo do que tentou.

Depois de uma alteração bem-sucedida, faça com que o ficheiro no disco descreva o conjunto de regras em execução e confirme que uma recarga o reproduz. Um conjunto de regras vivo que se afastou do seu próprio ficheiro de configuração é uma armadilha montada para o próximo arranque.