Změna pravidla firewallu nefunguje: pořadí pravidel a stav spojení

Upravili jste pravidlo, znovu načetli sadu pravidel a tunel se chová přesně jako dřív. Tento výsledek má dvě časté příčiny a ty vyžadují různé testy. Buď nové pravidlo stojí za dřívějším pravidlem, které už paket přijalo, nebo je výměna, kterou sledujete, sledované spojení, které změna nikdy znovu nevyhodnotí. Pravidlo v souboru vyjadřuje záměr; o osudu paketu rozhoduje aktivní cesta, na kterou narazí. Projděte níže uvedené kontroly popořadě a přitom si ponechte cestu zpět.

Pořadí pravidel a stav spojení jsou různé závady

Seřazené řetězce se vyhodnocují shora dolů a první pravidlo, které dospěje k závěrečnému verdiktu, ukončí průchod tímto řetězcem. Vložte široké povolení nad pečlivě napsané pravidlo uzamčení a pravidlo uzamčení se stane dokumentací: je v sadě pravidel, má nulový čítač a žádný paket se k němu nikdy nedostane. Stejný text použitý na jiný řetězec také nic nedokazuje. V nftables se základní řetězce připojují k hookům s prioritami, takže povolení v jednom řetězci nebrání jinému řetězci na jiném hooku či prioritě vidět stejný paket.

Sledování spojení vytváří druhý symptom a zvenčí vypadá stejně. Jakmile je tok v tabulce stavů, povolení pro navázané či související se u vrcholu řetězce vrátí dřív, než se vaše nové pravidlo vůbec posoudí. Překlady NAT mají stejnou vlastnost: překlad se zafixoval, když tok začínal, takže upravené pravidlo v postroutingu nepřepíše relaci, která už běží. Proto změna vypadá, že v 09:00 funguje pro nové spojení, a vypadá, že nic nedělá pro relaci, kterou někdo otevřel v 08:55.

Cloudové bezpečnostní skupiny přidávají třetí model, který chytá lidi, kteří se učili na iptables. Jejich příchozí pravidla jsou seznam povolení vyhodnocovaný jako množina, nikoli jako průchod prvním shodným, jsou stavová a odebrání pravidla povolení neukončí toky, které se už sledují. Předpokládat sémantiku prvního párování na platformě, která ji nemá, vede k sebevědomým, chybným závěrům.

Čtěte aktivní sadu pravidel, ne soubor, který jste upravili

Začněte tím, co jádro právě vynucuje. Uložená konfigurace, která nebyla nikdy aplikována, vysvětluje překvapivé množství nezměněného chování a vyloučit ji stojí jeden příkaz:

nft list ruleset
iptables-save

Pak se ptejte, zda se vaše pravidlo vůbec dostane na řadu. Počítadla paketů odpovídají přímo a odpovídají lépe než jakékoli uvažování o záměru:

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

Pravidlo uzamčení s nulou paketů po skutečném testovacím pokusu není problém politiky, je to problém pozice. Přesunout ho je změna na jeden řádek a syntaxe je přesně to, co způsobilo původní chybu. S iptables -I vkládá a -A přidává na konec; s nftables insert umisťuje pravidlo na začátek řetězce, zatímco add přidává na konec. Když má pravidlo vyhrát, řekněte to výslovně, místo abyste věřili pořadí, které se zrovna načetlo.

Dokažte, zda se tok sleduje

Než obviníte pravidlo, zkontrolujte, zda je provoz vůbec sledované spojení. Zeptejte se tabulky stavů na konkrétní tok, místo abyste ji celou vysypali:

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

Výpis ukazuje stav a zbývající časový limit a právě tak rozeznáte navázanou relaci od nového pokusu; režim událostí vypisuje aktualizace, jak nastávají, což je užitečné, když znovu připojujete klienta. Pokud je tok přítomný se stavem navázáno dřív, než jste se čehokoli dotkli, žádná úprava filtračních pravidel nezmění jeho osud. To není chyba firewallu, to je smlouva stavového filtrování.

Odolejte zkratce vyprázdnit celou tabulku na produkční bráně. conntrack -F je k dispozici a také zničí každý sledovaný tok na stroji, včetně relace správy, ze které pracujete, a tunelu, který nese vaši konzoli. Jednotlivé záznamy lze smazat, když to skutečně potřebujete, ale nový tok z nového zdrojového portu je obvykle čistší experiment.

Některé cesty se nesledují a chovají se opačně. Provoz označený notrack v tabulce raw, některé tunely obcházející běžné hooky a asymetrické směrování, které rozděluje tok mezi dvě brány, to vše vytváří pakety vyhodnocované jeden po druhém, nebo stav, který na obou koncích nikdy nevznikne. Pokud se počítadla hýbou u každého paketu, podezřívejte takovou cestu dřív než pořadí.

Testujte z nového toku s cestou zpět

Než otestujete pravidlo, které by mohlo odříznout vzdálený přístup, vytvořte cestu obnovy: konzoli poskytovatele, sériovou konzoli, adresu správy mimo pásmo nebo druhé rozhraní, které pravidlo nemůže zachytit. Časovač návratu je rozumný společník, protože obnoví předchozí sadu pravidel, i kdyby vaše relace během testu zahynula.

Poté testujte výměnou, kterou stav už nemohl pokrýt. Odpojte a znovu připojte klienta, aby vznikla nová pětice, a sledujte přitom oba konce:

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

Proveďte test oběma směry. Pravidlo, které blokuje nový příchozí handshake, může stále povolovat cestu odpovědi, nebo naopak, a jednosměrný výsledek je obvyklý důvod, proč uzamčení funguje napůl. Po testu se ještě jednou připojte, abyste potvrdili ustálený stav, a zkontrolujte, zda přežil legitimní přístup správy; pravidlo napsané pro jeden port má ve zvyku odpovídat širšímu rozsahu, než byl zamýšlen.

Zaznamenejte účel a pozici spolu s pravidlem

Pravidlo bez zaznamenaného účelu je pravidlo, které si nikdo netroufne odstranit. U každého záznamu uzamčení uchovávejte tok, který chrání, řetězec a hook, v němž žije, pozici, kterou musí držet vůči širším povolením, a test, který to prokázal. Když někdo za šest měsíců upraví okolní sadu pravidel, ta poznámka je jediným varováním, že pozice byla úmyslná.

Než změnu uzavřete, potvrďte čtyři věci: běžící sada pravidel odpovídá souboru, nové pravidlo má po čerstvém pokusu nenulová počítadla, opačný směr i přístup správy stále fungují a jednou jste se znovu připojili, abyste prokázali ustálený stav, nikoli stav relace starší než změna. Pokud cokoli z toho není ověřeno, změna není hotová, ať tunel dělá cokoli.