Žádné tun0? Porovnávejte dešifrovaný IPsec v nftables pomocí meta ipsec

Očekáváte rozhraní tunelu, hledáte ho a ve firewallu není nic, s čím by se dalo porovnat. To je u brány založené na politikách normální: šifrovaná výměna přichází na fyzické rozhraní a dešifrovaný vnitřní paket, který se pak přeposílá, je také pozorován jako přicházející na totéž rozhraní. Žádné tun0 není, protože ho nic nevytvořilo.

Vnitřní požadavek je stále samostatný paket s vlastním zdrojem, cílem a službou a jádro ví, ze které bezpečnostní asociace vyšel. Právě tuto znalost může pravidlo firewallu porovnat.

Dva pakety, jedno rozhraní

Představte si příchozí směr. Přijde paket zapouzdřený v ESP nebo UDP, jádro najde odpovídající politiku, dešifruje ho a předá čistý paket přeposílací cestě. Pravidlo, které se dívá jen na název rozhraní, nedokáže tento paket odlišit od jakéhokoli jiného provozu přicházejícího po stejném kabelu.

Odlišuje ho kontext příchozí bezpečnostní cesty připojený k paketu. nftables ho vystavuje jako meta ipsec exists, což platí, když paket přišel bezpečnostní cestou IPsec. Zkombinujte ho s bazénem klientů, cílem a službou a pravidlo bude dost konkrétní na to, aby bylo bezpečné.

Vynechání kontextu je častá chyba a je to chyba zabezpečení, ne kosmetická. Pravidlo, které přijímá vše z bazénu klientů, stejně ochotně přijme podvržený paket z místní sítě, protože zdrojová adresa sama o sobě není důkazem ničeho. Kontext bezpečnostní cesty je nejlevnější způsob, jak dát zdroji význam. Pište pravidlo s ním od začátku, místo abyste ho přidávali po auditu.

Napište pravidlo pro přeposílání

Předpokládejte autentizovanou službu vzdáleného přístupu IPv4 s klienty v 10.90.0.0/24 a jedním schváleným cílem na 203.0.113.40. Fragment pravidla pro tento tok vypadá takto.

meta ipsec exists ip saddr 10.90.0.0/24 \
  ip daddr 203.0.113.40 tcp dport 443 \
  oifname "eth0" counter accept

Adresy a rozhraní jsou příklady k nahrazení. Umístěte zkontrolovaný ekvivalent do přeposílací politiky před pravidlo, které by tok jinak odmítlo, a nerušte existující sadu pravidel, abyste ho nainstalovali; brána není experiment v čisté místnosti.

Termín oifname stojí za to ponechat. Dokumentuje rozhodnutí o výstupu a brání tomu, aby pravidlo odpovídalo ve směru, který jste nezamýšleli, což je důležité na bráně s několika cestami do internetu. Na testovacím stroji s jedním výstupním spojením vypadá termín nadbytečně, a právě proto se odstraní dřív, než stroj získá druhé spojení.

Oprávnění pro vnější výměnu jsou oddělená. Vstupní cesta brány potřebuje porty IKE a ESP nebo UDP zapouzdření, které skutečně používá, a tato oprávnění nic nepovolují ohledně dešifrovaného paketu uvnitř. Míchání obojího je způsob, jak funkční tunel skončí s firewallem, který přeposílá všechno.

Příchozí kontext není odchozí kontext

Stejná rodina výrazů pokrývá druhý směr pomocí rt ipsec, který popisuje odchozí bezpečnostní asociaci, kterou paket použije. Odpovídá na jinou otázku: ne odkud tento paket přišel, ale zda bude na dalším úseku chráněn.

Tento rozdíl je důležitý na bráně, která zároveň ukončuje jeden tunel a přeposílá do jiného. Paket může přijít dešifrovaný a přesto muset odejít šifrovaný, a přijetí napsané jen pro příchozí kontext neříká nic o odchozím požadavku. Pokud politika tuto ochranu vyžaduje, sada pravidel by ji měla vyjádřit, místo aby předpokládala, že to vyřeší směrování.

Držte obě otázky v oddělených pravidlech, aby čtenář viděl, které se vynucuje. Jedno chytré pravidlo, které kontroluje obojí, se hůř kontroluje a mnohem hůř se ladí, když jedna jeho polovina přestane odpovídat. Dvě pravidla s čítači vám také řeknou, který požadavek selhává, což jedno sloučené pravidlo nikdy neudělá.

NAT není rozhodnutí firewallu

Provoz do internetu z privátního bazénu klientů obvykle potřebuje překlad zdroje, aby odpověď našla cestu zpět. Ale provoz vybraný pro jinou odchozí politiku IPsec si musí zachovat požadovanou výjimku a maskování každého privátního zdroje bez přemýšlení o dalším rozhodnutí o ochraně to rozbíjí.

Přijetí uvnitř řetězce NAT také není obecné povolení. NAT a filtrování mají různé úlohy a řetězec NAT neprohlíží každý pozdější paket navázaného toku, a právě proto spoléhání na něj v otázkách zabezpečení dává pravidla, která vypadají funkčně při testu a selhávají pod zátěží.

Opak je také pravdivý a lidi zaskočí: přijetí někde v jednom základním filtračním řetězci nemá žádnou váhu proti pozdějšímu odmítnutí v jiném použitelném řetězci. Výsledek rozhoduje pořadí a rozsah řetězce, ne přítomnost přijetí v souboru.

Ověřte přesnou vnitřní službu

Otestujte konkrétní cíl a port, které jste povolili, z reálného klienta a potvrďte, že odpověď se vrací. Pak otestujte něco, co jste nepovolili, a ověřte, že to neprojde, protože příliš široké pravidlo projde prvním testem stejně dobře jako správné. Požadavek, který nikdy neopustí klienta, také není výsledkem firewallu, takže čtěte čítače, abyste viděli, zda byl paket vůbec vyhodnocen. Dva testy a jedno odečtení čítače vám řeknou víc než celé odpoledne čtení sady pravidel.

Referenční příručka nftables dokumentuje meta ipsec, rt ipsec a výrazy specifické pro směr a právě tam je místo, kde ověřit syntaxi proti nainstalované verzi. A držte rozsah explicitní: toto je příklad IPv4, nic neříká o IPv6 a nepřevádí svévolné veřejné přeposílání portů na součást služby VPN.