Pravidla firewallu pouze pro NEW nezavírají všechny cesty přes WAN

Odmítnutí nových odchozích spojení na WAN vypadá jako politika uzavřeného selhání, ale je to užší slib, než se zdá. Pakety patřící k již existujícím tokům jí neodpovídají, stejně jako mnohé odpovědi. Tuto mezeru lze snadno přehlédnout, protože se pravidlo čte, jako by pokrývalo rozhraní, a ne jeden stav spojení na něm. A čtení shody stavu jako rozsudku je to, co vytváří falešný pocit uzavření.

Stav je podmínka shody, ne rozsudek

Sledování spojení klasifikuje pakety podle toho, co firewall už viděl, ne podle toho, čemu věří aplikace. Tok pozorovaný v obou směrech je navázaný a jeho pozdější pakety zůstávají navázané, i když se trasa pod ním změní z tunelu na běžné odchozí rozhraní. Odpověď na příchozí spojení může být také navázaný provoz. Tyto pakety už nikdy nebudou nové.

Proto pravidlo omezené na nová spojení nemůže prokázat, že každý chráněný paket je zablokován. Ostatní stavy nechává na tom, co s nimi dělá zbytek sady pravidel, což může být povolení umístěné dříve v řetězci.

Čtěte pravidlo v jeho okolí

Široké povolení pro navázaný a související provoz umístěné před blokem propustí paket dřív, než se blok vůbec vyhodnotí. Odebrání podmínky stavu z pozdějšího pravidla to nezmění, protože vyhodnocení se k němu nikdy nedostane. Výsledek určuje pořadí a shoda stavu určuje, které pakety se k tomuto pořadí dostanou.

Prohlédněte si účinnou sadu pravidel, ne soubor, který jste upravili, včetně skoků do jiných řetězců a všeho, co platforma generuje. Na routeru spravovaném přes iptables ukazuje výpis řetězce definice pravidel a řetězce, na které odkazuje, je také třeba sledovat. Nativní systém nftables vyžaduje kontrolu vlastní sady pravidel a priorit hooků, protože firmware jen zřídka generuje totožné řetězce.

Počítadla ukazují, které pravidlo skutečně odpovídalo, a obvykle jsou informativnější než zachycení paketů pořízené po rozhodnutí. Pravidlo s nulovým počítadlem nebylo dosaženo, ať jeho pozice naznačuje cokoli.

Vyjádřete zákaz nezávisle na stavu

Pokud se skupina klientů nikdy nesmí dostat na internet mimo tunel, řekněte to přímo, místo abyste to přibližovali jedním stavem. Pravidlo musí vybírat podle zdroje, výstupu a cíle bez závislosti na stavu spojení a musí stát tam, kde ho žádné dřívější povolení nemůže obejít. Správní přístup a výjimky pro místní síť pak dostanou vlastní výslovná pravidla, takže je záměr v politice vidět.

Volba reject místo drop mění, jak zvolený provoz selhává, a nerozšiřuje množinu paketů, které pravidlo vybírá. Odmítnuté spojení a tiché vypršení jsou různé příznaky ukazující na stejnou volbu.

Politika, která záměrně povoluje odpovědi na přístup iniciovaný zvenčí přes WAN, je obhajitelná. Jen se musí popsat právě tak, místo aby se vydávala za úplnou izolaci pouze tunelem.

Zkontrolujte, kdo je ve skupině doopravdy

Příklad pokrývá přeposílaný provoz IPv4 z jednoho prefixu přes jedno rozhraní. Nic neříká o IPv6, druhém odchozím rozhraní ani o provozu, který sám router vytváří. Router vystupující jako DNS resolver posílá vlastní dotazy směrem ven a ty řetězcem forward vůbec neprocházejí.

Ověřte, že chránění klienti stále mají adresy uvnitř zvoleného prefixu, protože zařízení, které z něj vyjelo, je přímé náhodou, ne politikou. Rozšíření bloku na celou LAN bez přezkumu návrhu výjimek navíc obvykle odstraní vaši vlastní správní cestu.

iptables -S FORWARD
iptables -L FORWARD -v -n
cat /proc/net/nf_conntrack | grep -c ESTABLISHED

Pak vyzkoušejte starý tok vedle nového. Nový pokus o spojení a už aktivní obousměrný přenos se pod tímto pravidlem chovají odlišně, a jen test obojího ukáže, jakou politiku vlastně máte.