Firewallwijzigingen testen zonder jezelf buiten te sluiten

Je regel gaat erin, de terminal die je al hebt blijft antwoorden, en de volgende login wordt geweigerd. Precies dat gat is de hele moeilijkheid van het testen van een firewallwijziging over de verbinding die je aan het wijzigen bent. Connection tracking beslist één keer en stopt dan met kijken, dus een gevestigde stroom is de enige test die het nieuwe beleid niet kan zien. Wat volgt vergelijkt de drie wegen terug en legt daarna de volgorde vast waarin de regels gewijzigd en gecontroleerd moeten worden.

Waarom de overlevende sessie het zwakste bewijs is

Een stateful firewall evalueert het eerste pakket van een stroom en houdt dat oordeel zolang de entry leeft. Regels die daarna worden toegevoegd, gelden voor stromen die later beginnen, en daarom blijft het venster waarin je typt bruikbaar terwijl iedereen anders wordt geweigerd. Wat je ervan leert, beschrijft het beleid dat minuten geleden gold. Zelfs een capture op die stroom laat een beslissing zien die de machine al heeft genomen.

Behandel de werkende sessie als een nooduitgang en niet als een meting. Elke controle die de moeite waard is, moet een nieuwe stroom openen vanaf een bron die de nieuwe regel zal evalueren, en de eerste controle moet degene zijn waarvan falen het meest pijn zou doen. Wanneer die sessie je enige weg naar binnen is, is de wijziging nog niet klaar om te maken.

Drie wegen terug, geordend naar waar elk van afhangt

Rangschik de opties naar hoeveel ze afhangen van het geteste apparaat, want die rangorde is waar je naar grijpt als de regel verkeerd blijkt. Een console die nooit door de firewall gaat, is onafhankelijk, een geoefende terugdraai is bijna zo, en de sessie die al open is niet.

Log voor de wijziging in via de console en bewijs dat die werkt, want een out-of-band-route die je nooit hebt gebruikt, is een schema en geen terugvaloptie. Een terugdraai verdient zijn plek pas na een oefening op dat platform, met die regelset, volgens de goedgekeurde procedure in plaats van improviseren op een live machine. Schrijf de stappen op en laat iemand anders ze teruglezen. Als de volgorde je geheugen nodig heeft om te voltooien, is het geen plan.

Eén wijziging, dan een verbinding die geëvalueerd moet worden

Bewaar de actieve regelset en het bestand dat hem bezit, en maak dan één smalle bewerking. Eén wijziging per test houdt de uitkomst toerekenbaar; twee tegelijk laten je achter met een werkende machine en geen idee welke bewerking het werk deed. Waar het platform een configuratie kan analyseren zonder die te laden, doe dat eerst, zodat een typefout faalt terwijl er niets op het spel staat.

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

Start dan een nieuwe sessie vanaf een bron waarop de gewijzigde regel zal passen, terwijl de console nog verbonden is. Herhaal het één keer als het lukt, want de eerste poging kan op een entry landen die de tabel al had. Als het mislukt, heb je nog een weg naar binnen en een beslissing om terug te draaien, en dat is de goedkoopste slechte uitkomst die er is.

Tellers, status en het bestand beantwoorden verschillende vragen

Elk van de drie observaties kan op zichzelf overtuigend lijken en je over de andere twee misleiden. Tellers laten zien of de stroom die je net hebt gemaakt de regel heeft bereikt die je hebt bewerkt. De statustabel laat zien welke stromen de machine al als gevestigd beschouwt, en zo kan een kapotte regel er nog steeds gezond uitzien. Het bewaarde bestand laat zien wat het apparaat doet na de volgende herlaad, en dat is misschien niet wat de actieve regelset nu doet.

ss -tn state established

Lees tellers als een delta en niet als een totaal, want het enige getal dat ertoe doet, is het getal dat je teststroom heeft verplaatst. Een regel waarvan de teller nooit oploopt, past niet, hoe juist die er op papier ook uitziet. Bevestig ook het weigeringsgeval: een beleid dat nooit iets heeft geweigerd, heeft nooit bewezen dat het weigert wat je wilde blokkeren. Loop één interface door in elke familie die de uitrol werkelijk voert, want een v4-regel zegt niets over een v6-stroom.

Herstel uit de bewaarde regelset en breng daarna het bestand in overeenstemming

Als de wijziging mislukt, laad dan de bewaarde regelset in plaats van toestemmende regels toe te voegen tot logins weer werken. Elke extra toestemming sust het symptoom en laat een gat achter dat het incident en de herinnering eraan overleeft. Herstel, verbind opnieuw en bewaar daarna de mislukte vergelijking naast het verslag van wat je hebt geprobeerd.

Zorg na een geslaagde wijziging dat het bestand op schijf de actieve regelset beschrijft, en bevestig dat een herlaad die reproduceert. Een actieve regelset die is afgedreven van zijn eigen configuratiebestand is een valstrik voor de volgende herstart.