Testa brandväggsändringar utan att låsa ut dig själv

Regeln går in, terminalen du redan har fortsätter att svara, och nästa inloggning nekas. Just den luckan är hela svårigheten med att testa en brandväggsändring över anslutningen du ändrar. Anslutningsspårningen bestämmer en gång och slutar sedan titta, så ett etablerat flöde är det enda prov som inte kan se den nya policyn. Det som följer jämför de tre vägarna tillbaka och fastställer sedan ordningen i vilken reglerna ska ändras och kontrolleras.

Varför den överlevande sessionen är det svagaste beviset

En tillståndskänslig brandvägg utvärderar det första paketet i ett flöde och behåller den domen så länge posten lever. Regler som läggs till efteråt gäller flöden som börjar senare, och därför förblir fönstret du skriver i användbart medan alla andra nekas. Det du lär dig av det beskriver policyn som gällde för några minuter sedan. Även en inspelning tagen på det flödet visar ett beslut som maskinen redan har fattat.

Behandla den fungerande sessionen som en nödutgång och inte som en mätning. Varje kontroll som är värd att köra måste öppna ett nytt flöde från en källa som den nya regeln kommer att utvärdera, och den första kontrollen bör vara den där ett misslyckande skulle göra mest ont. När den sessionen är din enda väg in är ändringen inte redo att göras.

Tre vägar tillbaka, ordnade efter vad var och en beror på

Rangordna alternativen efter hur mycket de beror på enheten som testas, eftersom den rangordningen är det du griper efter när regeln visar sig vara fel. En konsol som aldrig går genom brandväggen är oberoende, en inövad återställning nästan det, och sessionen som redan är öppen inte.

Logga in via konsolen före ändringen och bevisa att den fungerar, eftersom en väg utanför bandet som du aldrig använt är ett diagram och inte en reserv. En återställning förtjänar sin plats först efter en övning på den plattformen, med den regeluppsättningen, enligt det godkända förfarandet i stället för improvisation på en levande maskin. Skriv ner stegen och låt någon annan läsa tillbaka dem. Om sekvensen behöver ditt minne för att bli klar är den ingen plan.

En ändring, sedan en anslutning som måste utvärderas

Spara den körande regeluppsättningen och filen som äger den, och gör sedan en enda snäv redigering. En ändring per test håller resultatet tillskrivbart; två samtidigt lämnar dig med en fungerande maskin och ingen aning om vilken redigering som gjorde jobbet. Där plattformen kan analysera en konfiguration utan att läsa in den, gör det först, så att ett skrivfel fallerar när ingenting står på spel.

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

Starta sedan en ny session från en källa som den ändrade regeln kommer att matcha, medan konsolen fortfarande är ansluten. Upprepa en gång om det lyckas, eftersom det första försöket kan landa på en post som tabellen redan hade. Om det misslyckas har du fortfarande en väg in och ett beslut att rulla tillbaka, och det är det billigaste dåliga utfallet som finns.

Räknare, tillstånd och filen svarar på olika frågor

Var och en av de tre observationerna kan se övertygande ut på egen hand och vilseleda dig om de andra två. Räknarna visar om flödet du just skapade nådde regeln du redigerade. Tillståndstabellen visar vilka flöden maskinen anser redan vara etablerade, och så kan en trasig regel fortfarande se frisk ut. Den sparade filen visar vad enheten gör efter nästa omläsning, och det är kanske inte vad den körande regeluppsättningen gör nu.

ss -tn state established

Läs räknarna som en delta och inte som en summa, eftersom det enda tal som betyder något är det som ditt testflöde flyttade. En regel vars räknare aldrig ökar matchar inte, hur korrekt den än ser ut på papper. Bekräfta också avvisningsfallet: en policy som aldrig har avvisat något har aldrig bevisat att den avvisar det du ville blockera. Gå igenom ett gränssnitt i varje familj som utrullningen faktiskt bär, eftersom en v4-regel inte säger något om ett v6-flöde.

Återställ från den sparade regeluppsättningen och få sedan filen att stämma

När ändringen misslyckas, läs in den sparade regeluppsättningen i stället för att lägga till tillåtande regler tills inloggningar fungerar igen. Varje extra tillåtelse dämpar symptomet och lämnar ett hål som överlever incidenten och minnet av den. Återställ, återanslut och håll sedan den misslyckade jämförelsen bredvid redogörelsen för vad du försökte.

Efter en lyckad ändring, låt filen på disken beskriva regeluppsättningen som körs, och bekräfta att en omläsning återger den. En körande regeluppsättning som har glidit ifrån sin egen konfigurationsfil är en fälla satt för nästa omstart.