Ændring af firewallregel virker ikke: regelrækkefølge og forbindelsestilstand

Du redigerede reglen, genindlæste regelsættet, og tunnelen opfører sig præcis som før. Det resultat har to almindelige årsager, og de kræver forskellige tests. Enten ligger den nye regel efter en tidligere regel, der allerede har accepteret pakken, eller også er den udveksling, du ser på, en sporet forbindelse, som ændringen aldrig revurderer. En regel i en fil udtrykker hensigt; det, der afgør pakkens skæbne, er den aktive vej, den møder. Gå gennem kontrollerne nedenfor i rækkefølge, og hold en vej tilbage, mens du gør det.

Regelrækkefølge og forbindelsestilstand er forskellige fejl

Ordrede kæder evalueres oppefra og ned, og den første regel, der når en afsluttende kendelse, afslutter gennemgangen af den kæde. Sæt en bred accept over en omhyggeligt skrevet lockdown-regel, og lockdown-reglen bliver dokumentation: den står i regelsættet, dens tæller er nul, og ingen pakke vil nogensinde nå den. Den samme tekst anvendt på en anden kæde beviser heller intet. I nftables knyttes basiskæder til hooks ved prioriteter, så en accept i én kæde forhindrer ikke en anden kæde på et andet hook eller en anden prioritet i at se den samme pakke.

Forbindelsessporing frembringer det andet symptom, og udefra ser det identisk ud. Når et flow først er i tilstandstabellen, returnerer en accept for etableret-eller-relateret nær toppen af kæden, før din nye regel overhovedet bliver konsulteret. NAT-mappinger har samme egenskab: oversættelsen blev fastlagt, da flowet begyndte, så en redigeret postrouting-regel omskriver ikke en session, der allerede kører. Derfor ser en ændring ud til at virke kl. 09:00 for en ny forbindelse og ser ud til at gøre ingenting for den session, nogen åbnede kl. 08:55.

Cloud-sikkerhedsgrupper tilføjer en tredje model, der fanger folk, som lærte på iptables. Deres indgående regler er en tilladelsesliste, der evalueres som et sæt i stedet for en gennemgang efter første match, de er stateful, og fjernelse af en tilladelsesregel afslutter ikke flows, der allerede spores. At antage første-match-semantik på en platform, der ikke har den, fører til selvsikre, forkerte konklusioner.

Læs det aktive regelsæt, ikke den fil, du redigerede

Begynd med det, kernen håndhæver lige nu. En gemt konfiguration, der aldrig blev anvendt, forklarer overraskende mange uændrede adfærdsmønstre, og det koster én kommando at udelukke den:

nft list ruleset
iptables-save

Spørg så, om din regel overhovedet bliver nået. Pakketællere svarer direkte på det og svarer bedre end enhver ræsonneren om hensigt:

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

En lockdown-regel med nul pakker efter et reelt testforsøg er ikke et politikproblem, det er et positionsproblem. At flytte den er en ændring på én linje, og syntaksen er præcis det, der forårsagede den oprindelige fejl. Med iptables -I indsætter, og -A tilføjer i slutningen; med nftables insert placerer en regel i starten af kæden, mens add tilføjer i slutningen. Når en regel skal vinde, så sig det eksplicit i stedet for at stole på den rækkefølge, der tilfældigvis blev indlæst.

Bevis, om flowet spores

Før du bebrejder reglen, så kontroller, om trafikken overhovedet er en sporet forbindelse. Spørg tilstandstabellen om det specifikke flow i stedet for at dumpe det hele:

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

Oplistningen viser tilstanden og den resterende timeout, og det er sådan, du skelner en etableret session fra et friskt forsøg; tilstanden for begivenheder udskriver opdateringer, efterhånden som de sker, hvilket er nyttigt, mens du genopretter en klient. Hvis flowet er til stede med etableret tilstand, før du rørte noget, vil ingen ændring af filterreglerne ændre dets skæbne. Det er ikke en fejl i firewallen, det er kontrakten for stateful filtrering.

Modstå genvejen med at tømme hele tabellen på en produktionsgateway. conntrack -F er tilgængelig, og det ødelægger også hvert sporet flow på maskinen, inklusive den administrationssession, du arbejder fra, og den tunnel, der bærer din shell. Enkelte poster kan slettes, når du virkelig har brug for det, men et friskt flow fra en ny kildeport er normalt et renere eksperiment.

Nogle veje spores ikke, og de opfører sig modsat. Trafik mærket notrack i raw-tabellen, nogle tunneler, der omgår de normale hooks, og asymmetrisk routing, der deler et flow mellem to gateways, giver alle pakker, der evalueres én ad gangen, eller tilstand, der aldrig oprettes i begge ender. Hvis tællerne bevæger sig for hver pakke, så mistænk den slags vej, før du mistænker rækkefølgen.

Test fra et friskt flow med en vej tilbage

Før du tester en regel, der kan afskære fjernadgang, så etabler en gendannelsesvej: udbyderens konsol, en seriel konsol, en administrationsadresse uden for båndet eller et andet interface, som reglen ikke kan matche. En rollback-timer er en rimelig følgesvend, da den gendanner det forrige regelsæt, selv hvis din session dør midt i testen.

Test derefter med en udveksling, som tilstanden ikke allerede kunne have dækket. Afbryd og genopret klienten, så en ny femling oprettes, og overvåg begge ender, mens det sker:

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

Kør testen i begge retninger. En regel, der blokerer det nye indgående håndtryk, kan stadig tillade svarvejen, eller omvendt, og et ensrettet resultat er den sædvanlige grund til, at en lockdown kun virker halvt. Genopret forbindelsen én gang efter testen for at bekræfte den stabile tilstand, og kontroller, at legitim administrationsadgang overlevede; en regel skrevet til én port har for vane at matche et bredere område end tilsigtet.

Notér formål og position sammen med reglen

En regel uden et noteret formål er en regel, som ingen tør fjerne. Ved hver lockdown-post skal du gemme det flow, den beskytter, den kæde og det hook, den lever i, den position, den skal holde i forhold til bredere accepter, og den test, der beviste det. Når nogen redigerer det omkringliggende regelsæt seks måneder senere, er den note den eneste advarsel om, at positionen var bevidst.

Før du lukker ændringen, så bekræft fire ting: det kørende regelsæt matcher filen, den nye regel har tællere forskellige fra nul efter et friskt forsøg, den modsatte retning og administrationsadgang virker stadig, og du har genoprettet forbindelsen én gang for at bevise den stabile tilstand i stedet for tilstanden af en session, der er ældre end ændringen. Hvis noget af det er uverificeret, er ændringen ikke færdig, uanset hvad tunnelen gør.