Endring av brannmurregel virker ikke: regelrekkefølge og tilkoblingstilstand

Du redigerte regelen, lastet regelsettet på nytt, og tunnelen oppfører seg nøyaktig som før. Det resultatet har to vanlige årsaker, og de krever forskjellige tester. Enten ligger den nye regelen etter en tidligere regel som allerede har godtatt pakken, eller så er utvekslingen du ser på en sporet tilkobling som endringen aldri vurderer på nytt. En regel i en fil uttrykker hensikt; det som avgjør pakken, er den aktive veien den møter. Gå gjennom kontrollene nedenfor i rekkefølge, og hold en vei tilbake mens du gjør det.

Regelrekkefølge og tilkoblingstilstand er forskjellige feil

Ordnete kjeder evalueres ovenfra og ned, og den første regelen som når en endelig avgjørelse, avslutter gjennomgangen av den kjeden. Sett en bred godkjenning over en nøye skrevet låseregel, og låseregelen blir dokumentasjon: den står i regelsettet, telleren er null, og ingen pakke vil noen gang nå den. Den samme teksten brukt på en annen kjede beviser heller ingenting. I nftables festes grunnkjeder til kroker etter prioriteter, så en godkjenning i én kjede hindrer ikke en annen kjede på en annen krok eller prioritet i å se den samme pakken.

Tilkoblingssporing gir det andre symptomet, og utenfra ser det identisk ut. Når en flyt først er i tilstandstabellen, returnerer en godkjenning for etablert-eller-relatert nær toppen av kjeden før den nye regelen din i det hele tatt blir konsultert. NAT-mappinger har samme egenskap: oversettelsen ble fastsatt da flyten startet, så en redigert postrouting-regel skriver ikke om en økt som allerede kjører. Derfor ser en endring ut til å virke kl. 09:00 for en ny tilkobling og ser ut til å gjøre ingenting for økten noen åpnet kl. 08:55.

Skysikkerhetsgrupper legger til en tredje modell som fanger folk som lærte på iptables. Innkommende regler er en tillatelsesliste som evalueres som et sett i stedet for en gjennomgang etter første treff, de er stateful, og å fjerne en tillatelsesregel avslutter ikke flyter som allerede spores. Å anta første-treff-semantikk på en plattform som ikke har den, fører til selvsikre, gale konklusjoner.

Les det aktive regelsettet, ikke filen du redigerte

Begynn med det kjernen håndhever akkurat nå. En lagret konfigurasjon som aldri ble brukt, forklarer overraskende mange uendrede atferder, og det koster én kommando å utelukke den:

nft list ruleset
iptables-save

Spør så om regelen din i det hele tatt blir nådd. Pakketellere svarer direkte på det, og de svarer bedre enn noen resonnement om hensikt:

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

En låseregel med null pakker etter et reelt testforsøk er ikke et politikkproblem, det er et posisjonsproblem. Å flytte den er en endring på én linje, og syntaksen er nøyaktig det som forårsaket den opprinnelige feilen. Med iptables -I setter inn, og -A legger til på slutten; med nftables insert plasserer en regel i starten av kjeden mens add legger til på slutten. Når en regel må vinne, si det eksplisitt i stedet for å stole på rekkefølgen som tilfeldigvis ble lastet.

Bevis om flyten spores

Før du klandrer regelen, sjekk om trafikken i det hele tatt er en sporet tilkobling. Spør tilstandstabellen om den konkrete flyten i stedet for å dumpe hele:

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

Listen viser tilstanden og gjenstående tidsavbrudd, og slik skiller du en etablert økt fra et ferskt forsøk; hendelsesmodus skriver ut oppdateringer etter hvert som de skjer, noe som er nyttig mens du kobler til en klient på nytt. Hvis flyten er til stede med etablert tilstand før du rørte noe, vil ingen endring av filterreglene endre skjebnen dens. Det er ikke en feil i brannmuren, det er kontrakten for stateful filtrering.

Motstå snarveien med å tømme hele tabellen på en produksjonsgateway. conntrack -F er tilgjengelig, og det ødelegger også hver sporet flyt på maskinen, inkludert administrasjonsøkten du arbeider fra og tunnelen som bærer skallet ditt. Enkeltoppføringer kan slettes når du virkelig trenger det, men en fersk flyt fra en ny kildeport er vanligvis et renere eksperiment.

Noen veier spores ikke, og de oppfører seg motsatt. Trafikk merket notrack i raw-tabellen, noen tunneler som omgår de vanlige krokene, og asymmetrisk ruting som deler en flyt mellom to gateways gir alle pakker som evalueres én om gangen, eller tilstand som aldri opprettes i begge ender. Hvis tellerne beveger seg for hver pakke, mistenker du den slags vei før du mistenker rekkefølgen.

Test fra en fersk flyt med en vei tilbake

Før du tester en regel som kan kutte fjernadgang, etabler en gjenopprettingsvei: leverandørens konsoll, en seriell konsoll, en administrasjonsadresse utenfor båndet eller et andre grensesnitt som regelen ikke kan treffe. En tilbakerullingstimer er en rimelig følgesvenn, siden den gjenoppretter det forrige regelsettet selv om økten din dør midt i testen.

Test deretter med en utveksling som tilstanden ikke allerede kunne ha dekket. Koble fra og tilkoble klienten på nytt slik at en ny femling opprettes, og følg med på begge ender mens det skjer:

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

Kjør testen i begge retninger. En regel som blokkerer den nye innkommende håndtrykket, kan fortsatt tillate svarveien, eller omvendt, og et enveis resultat er den vanlige grunnen til at en lås bare virker halvveis. Koble til på nytt én gang etter testen for å bekrefte den stabile tilstanden, og kontroller at legitim administrasjonstilgang overlevde; en regel skrevet for én port har for vane å treffe et bredere område enn tiltenkt.

Noter formål og posisjon sammen med regelen

En regel uten et notert formål er en regel ingen tør fjerne. Ved hver låseoppføring holder du flyten den beskytter, kjeden og kroken den lever i, posisjonen den må holde overfor bredere godkjenninger, og testen som beviste det. Når noen redigerer det omkringliggende regelsettet seks måneder senere, er den noten den eneste advarselen om at posisjonen var bevisst.

Før du lukker endringen, bekreft fire ting: det kjørende regelsettet samsvarer med filen, den nye regelen har tellere ulike null etter et ferskt forsøk, motsatt retning og administrasjonstilgang virker fortsatt, og du har koblet til på nytt én gang for å bevise den stabile tilstanden i stedet for tilstanden til en økt som er eldre enn endringen. Hvis noe av dette er ubekreftet, er endringen ikke ferdig, uansett hva tunnelen gjør.