Nakreslite dešifrovanú cestu: kde VPN zariadenie presadzuje politiku

Diagramy dodávateľov sa zvyčajne končia pri šifrovanom listeneri, pretože to je časť s verejnou adresou. Otázka, ktorá určuje bezpečnostnú pozíciu, znie, čo sa deje po dešifrovaní, keď sa paket stane obyčajnou IP a môže dosiahnuť všetko, čo smerovacia tabuľka dovolí. Ak tú nohu nikto nenakreslil, nikto ju nevlastní. Runbook nižšie ju kreslí najprv a potom porovnáva umiestnenia podľa toho, čo dešifrovaná požiadavka skutočne prechádza.

Kreslite paket po dešifrovaní, nie pred ním

Vonkajšia cesta je časť, ktorú dodávatelia dokumentujú: verejný koncový bod, transportná politika, ktorá pripustí spojenie, a služba, ktorá ho ukončí. Vnútorná cesta začína v okamihu, keď paket stratí hlavičku tunela, a odtiaľ ho riadia pravidlá smerovania a filtrovania, ktoré s tunelom nemajú nič spoločné. Dajte obe na jednu stránku, pretože diagram len s prvou naznačuje, že prijatie a autorizácia sú jedno rozhodnutie. Nie sú, a práve medzera medzi nimi je miesto, kde sa väčšina umiestnení pokazí.

Vnútornú nohu píšte ako číslovanú postupnosť s pomenovanými typmi zariadení, nie ako šípku. Šípka skrýva, či požiadavka prechádza filtrom, a prechádzanie alebo neprechádzanie je celá otázka. Každý krok nižšie pomenúva zariadenie a súbor pravidiel, ktorý tam pôsobí, takže chýbajúci filter sa objaví ako medzera, a nie ako niečo naznačené čiarou.

1. Vzdialený klient: používateľské zariadenie, ktoré vytvára tunel.
2. Politika na okraji: súbor pravidiel, ktorý pripúšťa vonkajší transport k verejnému listeneru.
3. Ukončujúce zariadenie: koncový bod VPN, ktorý dekapsuluje a odovzdá paket obyčajnej IP.
4. Vnútorný filter: súbor pravidiel preposielania alebo bezpečnostných skupín, ktorý obmedzuje prevádzku od klienta k službe.
5. Hostiteľ aplikácie: služba, ktorá prijíma dešifrovanú požiadavku.

Dve politiky, dvaja vlastníci

Vonkajšia politika odpovedá, kto smie vytvoriť tunel, a vyjadrujú ju pravidlá, ktoré pripúšťajú transport k ukončujúcej službe. Vnútorná politika odpovedá, ku ktorej službe sa smie autentizovaný používateľ dostať, a žije v pravidlách preposielania, bezpečnostných skupinách alebo v samotnej aplikácii. Jedno zariadenie môže hostiť obe a návrh s viacerými zariadeniami má stále obe. Práve ich oddelené pomenovanie umožňuje povedať, ktorá zlyhala, keď sa používateľ nedostane k aplikácii.

Prijímacie kontroly ako certifikáty a viacfaktorová autentizácia odpovedajú na identitu a na nič iné. Nerozhodujú o umiestnení a neudeľujú oprávnenie k jednotlivému zdroju, keď je používateľ vnútri.

Umiestnenie rozhoduje, ktorú hranicu požiadavka prekračuje

Tri umiestnenia sú obvyklé a každé mení, ktorú hranicu dešifrovaná požiadavka prekračuje. Porovnajte ich podľa toho, čo tam končí, čo môže vidieť čistý text, ktorá kontrola ešte môže požiadavku odmietnuť a čo zlyhá spolu so zariadením. Tabuľka nižšie používa tieto štyri stĺpce namiesto všeobecnej otázky, pretože každá odpoveď je samostatné návrhové rozhodnutie.

Tretie umiestnenie je to, ktoré ticho odstraňuje presadzovanie, pretože noha na chránenom segmente dáva zariadeniu priamu cestu, ktorú diagram nemusí ukazovať. Skúmajte rozhrania a trasy, nie obrázok: ip route get 10.20.5.10 hovorí, ktorým rozhraním by paket vyšiel, a odpoveď často nie je tá, ktorú návrh predpokladal. Klasická úloha firewallu riadiť prevádzku medzi postojmi, ako je opísané vNIST SP 800-41, je tu užitočný test, pretože zariadenie s neobmedzenou nohou do chránenej siete veľa neovláda. Vyhľadanie trasy je čestnejší diagram ako ten v prezentácii.

Administrácia patrí na svoju vlastnú výslovne povolenú cestu. Dovoliť používateľom dosiahnuť aplikáciu nikdy nevyžaduje dovoliť im dosiahnuť riadiace rozhranie zariadenia a obe oprávnenia by sa mali udeľovať rôznymi pravidlami. Auditujte obe cesty oddelene, pretože zdieľané pravidlo skrýva, ktorá bola otvorená.

Preklad mení, čo môžu vidieť nižšie položené pravidlá

Preklad zdroja je pohodlný a ničí informácie. Po maskaráde vyzerá každý klient ako zariadenie, takže pravidlo nižšie napísané na rozlíšenie používateľov to už nedokáže. Nie je to len problém logov, je to problém politiky: pravidlo kľúčované adresou klienta sa ticho stane pravidlom kľúčovaným bránou. Ak politika pre jednotlivého používateľa záleží, zachovajte zdroj alebo politiku vynúťte pred prekladom.

Cesta odpovede si zaslúži rovnakú pozornosť. Zaznamenajte, ktorú trasu cieľ zvolí pre spätný paket, pretože asymetrický návrat obchádza stavovú inšpekciu a vytvára spojenie, ktoré sa nadviaže a potom sa zasekne. Oba smery musia prekročiť hranicu, ktorú ste nakreslili, inak je hranica dekorácia.

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

Prijmite povolenú a zamietnutú operáciu

Testujte zo skutočného vzdialeného klienta, nie z administratívneho hostiteľa, pretože administratívny hostiteľ zvyčajne sedí tam, kde používateľ nikdy nebude. Jedna povolená operácia dokazuje, že cesta funguje, a jedna zamietnutá dokazuje, že politika vôbec niečo robí. Spustite obe po každej zmene umiestnenia a zaznamenajte identitu zdroja a cieľ, ktoré ste použili. Test, ktorý dokazuje len úspech, nedokáže rozlíšiť správne pravidlo od chýbajúceho.

Potom testujte prípady, ktoré menia stav: opätovné pripojenie, reláciu, ktorá prežije rotáciu kľúčov, a zlyhanie samotného zariadenia. Porovnajte aktualizácie, kapacitu a obnovu ako súčasť rovnakého usporiadania, pretože jedno zariadenie držiace niekoľko logických kontrol je jedna doména zlyhania s niekoľkými štítkami. Ani druhá krabica nie je nezávislá, keď zdieľané administratívne prihlasovacie údaje alebo neobmedzená trasa porazí hranicu, ktorú mala vytvoriť.

Zdokumentujte koncový bod, dešifrovanú cestu a kontrolu, ktorá ju obmedzuje. Tie tri riadky zostávajú zmysluplné, nech sa implementácia volá akokoľvek.