Nakreslete dešifrovanou cestu: kde VPN zařízení vynucuje politiku

Diagramy dodavatelů obvykle končí u šifrovaného listeneru, protože to je část s veřejnou adresou. Otázka, která určuje bezpečnostní postoj, zní, co se děje po dešifrování, kdy se paket stane obyčejnou IP a může dosáhnout všeho, co směrovací tabulka dovolí. Když tu nohu nikdo nenakreslil, nikdo ji nevlastní. Runbook níže ji kreslí nejdřív a potom porovnává umístění podle toho, co dešifrovaný požadavek skutečně překračuje.

Kreslete paket po dešifrování, ne před ním

Vnější cesta je část, kterou dodavatelé dokumentují: veřejný koncový bod, transportní politika, která připustí spojení, a služba, která ho ukončí. Vnitřní cesta začíná okamžikem, kdy paket ztratí hlavičku tunelu, a odtud ji řídí směrovací a filtrační pravidla, která s tunelem nemají nic společného. Dejte obě na stejnou stránku, protože diagram jen s první z nich naznačuje, že přijetí a autorizace jsou jedno rozhodnutí. Nejsou a právě v mezeře mezi nimi se většina umístění pokazí.

Vnitřní nohu pište jako číslovanou posloupnost s pojmenovanými typy zařízení, ne jako šipku. Šipka skrývá, zda požadavek prochází filtrem, a procházení nebo neprocházení je celá otázka. Každý krok níže pojmenuje zařízení a sadu pravidel, která tam působí, takže chybějící filtr se objeví jako mezera, a ne jako něco naznačeného čarou.

1. Vzdálený klient: uživatelské zařízení, které tunel vytváří.
2. Politika na okraji: sada pravidel, která připouští vnější transport k veřejnému listeneru.
3. Ukončující zařízení: koncový bod VPN, který dekapsuluje a předá paket obyčejné IP.
4. Vnitřní filtr: sada pravidel předávání nebo bezpečnostních skupin, která omezuje provoz od klienta ke službě.
5. Hostitel aplikace: služba, která přijímá dešifrovaný požadavek.

Dvě politiky, dva vlastníci

Vnější politika odpovídá na to, kdo smí vytvořit tunel, a vyjadřují ji pravidla, která připouštějí transport k ukončující službě. Vnitřní politika odpovídá na to, ke které službě se autentizovaný uživatel smí dostat, a žije v pravidlech předávání, bezpečnostních skupinách nebo v aplikaci samotné. Jedno zařízení může hostit obě a návrh s několika zařízeními má pořád obě. Právě jejich oddělené pojmenování vám umožní říct, která selhala, když se uživatel nedostane k aplikaci.

Přijímací kontroly jako certifikáty a vícefaktorová autentizace odpovídají na identitu a na nic jiného. Nerozhodují o umístění a neudělují oprávnění k jednotlivému zdroji, jakmile je uživatel uvnitř.

Umístění rozhoduje, kterou hranici požadavek překračuje

Tři umístění jsou obvyklá a každé mění, kterou hranici dešifrovaný požadavek překračuje. Porovnejte je podle toho, co tam končí, co může vidět čistý text, která kontrola ještě může požadavek odmítnout a co selže spolu se zařízením. Tabulka níže používá tyto čtyři sloupce místo obecné otázky, protože každá odpověď je samostatné návrhové rozhodnutí.

Třetí umístění je to, které tiše odstraňuje vynucování, protože noha na chráněném segmentu dává zařízení přímou cestu, kterou diagram nemusí ukazovat. Zkoumejte rozhraní a trasy, ne obrázek: ip route get 10.20.5.10 říká, kterým rozhraním by paket vyšel, a odpověď často není ta, kterou návrh předpokládal. Klasická role firewallu řídit provoz mezi postoji, jak je popsáno vNIST SP 800-41, je tu užitečný test, protože zařízení s neomezenou nohou do chráněné sítě moc neřídí. Vyhledání trasy je poctivější diagram než ten v prezentaci.

Administrace patří na svou vlastní výslovně povolenou cestu. Dovolit uživatelům dosáhnout aplikace nikdy nevyžaduje dovolit jim dosáhnout řídicího rozhraní zařízení a obě oprávnění se mají udělovat různými pravidly. Auditujte obě cesty odděleně, protože sdílené pravidlo skrývá, která z nich byla otevřena.

Překlad mění, co níže položená pravidla vidí

Překlad zdroje je pohodlný a ničí informace. Po maskarádě vypadá každý klient jako zařízení, takže pravidlo níže napsané k rozlišení uživatelů to už nedokáže. Není to jen problém logů, je to problém politiky: pravidlo klíčované adresou klienta se tiše stane pravidlem klíčovaným bránou. Pokud záleží na politice pro jednotlivého uživatele, zachovejte zdroj nebo politiku vynuťte před překladem.

Cesta odpovědi si zaslouží stejnou pozornost. Zaznamenejte, kterou trasu cíl zvolí pro zpětný paket, protože asymetrický návrat obchází stavovou inspekci a vytváří spojení, které se naváže a pak se zasekne. Oba směry musí překročit hranici, kterou jste nakreslili, jinak je hranice dekorace.

sudo tcpdump -ni inside0 host 10.20.5.10
ip route get 10.20.5.10
sudo iptables -t nat -S POSTROUTING

Přijměte povolenou operaci a jednu zamítnutou

Testujte ze skutečného vzdáleného klienta, ne z administrativního hostitele, protože administrativní hostitel obvykle sedí tam, kde uživatel nikdy nebude. Jedna povolená operace dokazuje, že cesta funguje, a jedna zamítnutá dokazuje, že politika vůbec něco dělá. Spusťte obě po každé změně umístění a zaznamenejte identitu zdroje a cíl, které jste použili. Test, který dokazuje jen úspěch, nedokáže rozeznat správné pravidlo od chybějícího.

Pak testujte případy, které mění stav: opětovné připojení, relaci, která přežije rotaci klíčů, a selhání samotného zařízení. Porovnejte aktualizace, kapacitu a obnovu jako součást stejného uspořádání, protože jedno zařízení držící několik logických kontrol je jedna doména selhání s několika štítky. Ani druhý box není nezávislý, když sdílené administrativní přihlašovací údaje nebo neomezená trasa porazí hranici, kterou měl vytvořit.

Zdokumentujte koncový bod, dešifrovanou cestu a kontrolu, která ji omezuje. Ty tři řádky zůstávají smysluplné, ať se implementace jmenuje jakkoli.