Test af firewallændringer uden at låse dig selv ude

Din regel kommer ind, terminalen, du allerede har, svarer stadig, og den næste login afvises. Netop det gab er hele vanskeligheden ved at teste en firewallændring over den forbindelse, du ændrer. Forbindelsessporing beslutter én gang og holder så op med at kigge, så et etableret flow er den eneste probe, der ikke kan se den nye politik. Det følgende sammenligner de tre veje tilbage og fastlægger derefter rækkefølgen, hvori reglerne skal ændres og kontrolleres.

Hvorfor den overlevende session er det svageste bevis

En stateful firewall evaluerer den første pakke i et flow og beholder den dom, så længe posten lever. Regler, der tilføjes bagefter, gælder for flows, der starter senere, og derfor forbliver vinduet, du skriver i, brugbart, mens alle andre afvises. Hvad du lærer af det, beskriver den politik, der var gældende for få minutter siden. Selv en optagelse på det flow viser en beslutning, som maskinen allerede har truffet.

Behandl den fungerende session som en nødudgang snarere end en måling. Hver kontrol, der er værd at køre, skal åbne et nyt flow fra en kilde, som den nye regel vil evaluere, og den første kontrol bør være den, hvor et nederlag ville gøre mest ondt. Når den session er din eneste vej ind, er ændringen ikke klar til at blive lavet.

Tre veje tilbage, ordnet efter hvad hver afhænger af

Rangordn mulighederne efter, hvor meget de afhænger af den enhed, der testes, for den rangorden er det, du griber til, når reglen viser sig forkert. En konsol, der aldrig går gennem firewalle, er uafhængig, en indøvet tilbagerulning næsten, og den session, der allerede er åben, er ikke.

Log ind via konsollen før ændringen, og bevis, at den virker, for en out-of-band-vej, du aldrig har brugt, er et diagram og ikke en fallback. En tilbagerulning fortjener sin plads først efter en prøve på den platform, med det regelsæt, efter den godkendte procedure i stedet for improvisation på en levende maskine. Skriv trinene ned, og lad en anden læse dem højt tilbage. Hvis sekvensen har brug for din hukommelse for at blive færdig, er den ikke en plan.

Én ændring, derefter en forbindelse, der skal evalueres

Gem det kørende regelsæt og den fil, der ejer det, og lav derefter én snæver redigering. Én ændring per test holder resultatet tilskrivbart; to på én gang efterlader dig med en fungerende maskine og ingen anelse om, hvilken redigering der gjorde arbejdet. Hvor platformen kan parse en konfiguration uden at indlæse den, gør det først, så en tastefejl fejler, mens intet står på spil.

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

Start derefter en ny session fra en kilde, som den ændrede regel vil matche, mens konsollen stadig er tilsluttet. Gentag det én gang, hvis det lykkes, for det første forsøg kan lande på en post, som tabellen allerede havde. Hvis det fejler, har du stadig en vej ind og en beslutning at rulle tilbage, hvilket er det billigste dårlige udfald, der findes.

Tællere, tilstand og filen svarer på forskellige spørgsmål

Hver af de tre observationer kan se overbevisende ud på egen hånd og vildlede dig om de to andre. Tællere viser, om det flow, du netop har oprettet, nåede den regel, du redigerede. Tilstandstabellen viser, hvilke flows maskinen mener allerede er etableret, og det er sådan en brudt regel stadig kan se sund ud. Den gemte fil viser, hvad enheden vil gøre efter den næste genindlæsning, og det er måske ikke det, det kørende regelsæt gør nu.

ss -tn state established

Læs tællere som en delta snarere end en sum, for det eneste tal, der betyder noget, er det, dit testflow har flyttet. En regel, hvis tæller aldrig stiger, matcher ikke, hvor rigtigt det end ser ud på papiret. Bekræft også afvisningstilfældet: en politik, der aldrig har afvist noget, har aldrig bevist, at den afviser det, du ville blokere. Gå gennem ét interface i hver familie, som udrulningen faktisk bærer, for en v4-regel siger intet om et v6-flow.

Gendan fra det gemte regelsæt, og få derefter filen til at stemme

Når ændringen fejler, skal du indlæse det gemte regelsæt i stedet for at tilføje tilladende regler, indtil login virker igen. Hver ekstra tilladelse dæmper symptomet og efterlader et hul, der overlever hændelsen og erindringen om den. Gendan, genopret forbindelsen, og opbevar derefter den mislykkede sammenligning ved siden af optegnelsen af, hvad du forsøgte.

Efter en vellykket ændring skal filen på disken beskrive det regelsæt, der kører, og bekræft, at en genindlæsning gengiver det. Et kørende regelsæt, der er drevet væk fra sin egen konfigurationsfil, er en fælde sat til den næste genstart.