Rajzolja meg a visszafejtett útvonalat: hol érvényesít szabályt a VPN-eszköz
A titkosított figyelőnél megálló ábra nem mutatja meg a fontos szabályt. Rajzolja meg a visszafejtett útvonalat, majd hasonlítsa össze az elhelyezéseket aszerint, mit keresztez a kérés.
A szállítói ábrák általában a titkosított figyelőnél érnek véget, mert az a rész, amelynek nyilvános címe van. A biztonsági helyzetet eldöntő kérdés az, mi történik a visszafejtés után, amikor a csomag közönséges IP-vé válik, és elérhet mindent, amit az útválasztási tábla enged. Ha senki nem rajzolta meg ezt a szakaszt, akkor nincs gazdája. Az alábbi runbook először ezt rajzolja meg, majd aszerint hasonlítja össze az elhelyezéseket, hogy a visszafejtett kérés valójában mit keresztez.
A csomagot a visszafejtés után rajzolja meg, ne előtte
A külső útvonal az a rész, amelyet a szállítók dokumentálnak: egy nyilvános végpont, egy átviteli szabály, amely beengedi a kapcsolatot, és egy szolgáltatás, amely lezárja. A belső útvonal abban a pillanatban kezdődik, amikor a csomag elveszíti az alagút fejlécét, és onnantól olyan útválasztási és szűrési szabályok vezérlik, amelyeknek semmi közük az alagúthoz. Tegye mindkettőt ugyanarra az oldalra, mert a csak az elsőt mutató ábra azt sugallja, hogy a beengedés és a felhatalmazás egyetlen döntés. Nem az, és a kettő közötti rés az, ahol a legtöbb elhelyezés elhibázza.
A belső szakaszt számozott sorrendként írja le megnevezett eszköztípusokkal, ne nyílként. A nyíl elrejti, hogy a kérés keresztez-e szűrőt, és a keresztezés vagy annak hiánya maga a kérdés. Az alábbi minden ugrás megnevezi az eszközt és az ott ható szabálykészletet, így a hiányzó szűrő hézagként jelenik meg, nem pedig vonallal sugallt dologként.
- Távoli kliens: a felhasználói eszköz, amely az alagutat létrehozza.
- Peremszabály: a szabálykészlet, amely a külső átvitelt a nyilvános figyelőhöz beengedi.
- Lezáró eszköz: a VPN-végpont, amely dekapszulál, és a csomagot közönséges IP-nek adja át.
- Belső szűrő: a továbbítási vagy biztonságicsoport-szabálykészlet, amely az ügyféltől a szolgáltatás felé irányuló forgalmat korlátozza.
- Alkalmazásgazda: a szolgáltatás, amely a visszafejtett kérést fogadja.
Két szabály, két gazda
A külső szabály arra válaszol, ki létesíthet alagutat, és azokban a szabályokban fejeződik ki, amelyek az átvitelt a lezáró szolgáltatáshoz beengedik. A belső szabály arra válaszol, melyik szolgáltatást érheti el egy hitelesített felhasználó, és továbbítási szabályokban, biztonsági csoportokban vagy magában az alkalmazásban él. Egy eszköz mindkettőt befogadhatja, és a több eszközből álló tervezés is mindkettővel rendelkezik. Az, hogy külön nevezi meg őket, az teszi lehetővé, hogy megmondja, melyik hibázott, amikor a felhasználó nem ér el egy alkalmazást.
A beengedés vezérlése, például a tanúsítványok és a többtényezős hitelesítés, azonosságra válaszol, és semmi másra. Nem dönt az elhelyezésről, és nem ad erőforrás-onkénti engedélyt, miután a felhasználó bent van.
Az elhelyezés dönti el, melyik határt keresztezi a kérés
Három elhelyezés gyakori, és mindegyik megváltoztatja, melyik határt keresztezi a visszafejtett kérés. Hasonlítsa össze őket aszerint, mi záródik le ott, mi láthat nyílt szöveget, melyik vezérlés tudja még elutasítani a kérést, és mi hibázik az eszközzel együtt. Az alábbi táblázat ezt a négy oszlopot használja egy általános kérdés helyett, mert minden válasz külön tervezési döntés.
| Placement | What terminates there | What sees plaintext | Which control can still deny | Failure domain |
|---|---|---|---|---|
| Termination in a dedicated segment | A dedicated VPN endpoint | The endpoint and anything on its segment | The filter between that segment and the application | The segment path can bypass the filter if no rule sits on it |
| Termination on the edge firewall | The firewall's public listener | The firewall, after decapsulation | The firewall's inner rule set | Admission and inspection fail together |
| Termination on the protected LAN | The appliance's LAN leg | Every host on the protected LAN | Only a host control or a downstream gateway | The appliance and the protected hosts fail together |
A harmadik elhelyezés az, amely csendesen megszünteti az érvényesítést, mert a védett szegmensen lévő szakasz közvetlen útvonalat ad az eszköznek, amelyet az ábra talán nem mutat. A képet ne, a csatolókat és az útvonalakat vizsgálja: ip route get 10.20.5.10 megmondja, melyik csatolón hagyná el a csomag, és a válasz gyakran nem az, amelyet a tervezés feltételezett. A tűzfal klasszikus szerepe, hogy a testtartások közötti forgalmat vezérelje, ahogyan a következő dokumentum leírja:NIST SP 800-41, itt hasznos próba, mert a védett hálózat felé korlátlan szakasszal rendelkező eszköz nem sokat vezérel. Az útvonalkeresés őszintébb ábra, mint a prezentációban látható.
Az adminisztráció a saját, kifejezetten engedélyezett útvonalára tartozik. Ha a felhasználók elérhetnek egy alkalmazást, az soha nem igényli, hogy az eszköz vezérlőfelületét is elérjék, és a két engedélyt különböző szabályokból kell megadni. Mindkét útvonalat külön ellenőrizze, mert a megosztott szabály elrejti, melyiket nyitották meg.
A fordítás megváltoztatja, mit láthatnak a további szabályok
A forrásfordítás kényelmes, és tönkreteszi az információt. A masquerade után minden ügyfél úgy néz ki, mint az eszköz, így a felhasználók megkülönböztetésére írt további szabály már nem tudja ezt tenni. Ez nem csak naplózási probléma, hanem szabályprobléma: az ügyfélcímre kulcsolt szabály csendesen az átjáróra kulcsolt szabállyá válik. Ha a felhasználónkénti szabály számít, őrizze meg a forrást, vagy érvényesítse a szabályt a fordítás előtt.
A válaszútvonal ugyanezt a vizsgálatot érdemli. Jegyezze fel, melyik útvonalat választja a cél a visszatérő csomaghoz, mert az aszimmetrikus visszatérés megkerüli az állapotfüggő vizsgálatot, és olyan kapcsolatot hoz létre, amely létrejön, majd elakad. Mindkét iránynak kereszteznie kell a megrajzolt határt, különben a határ díszlet.
sudo tcpdump -ni inside0 host 10.20.5.10
ip route get 10.20.5.10
sudo iptables -t nat -S POSTROUTINGFogadjon el egy engedélyezett és egy megtagadott műveletet
A valódi távoli kliensről teszteljen, ne egy kezelőgazdáról, mert a kezelőgazda rendszerint ott ül, ahol a felhasználó soha nem lesz. Egy engedélyezett művelet bizonyítja, hogy az útvonal működik, egy megtagadott pedig azt, hogy a szabály egyáltalán tesz valamit. Mindkettőt futtassa minden elhelyezésváltozás után, és jegyezze fel a használt forrásazonosságot és célt. A csak sikert bizonyító teszt nem tudja megkülönböztetni a helyes szabályt a hiányzótól.
Ezután tesztelje az állapotot változtató eseteket: az újracsatlakozást, a kulcsrotációt túlélő munkamenetet és magát az eszköz meghibásodását. Hasonlítsa össze a frissítéseket, a kapacitást és a helyreállítást ugyanazon elrendezés részeként, mert az egy eszköz, amely több logikai vezérlést hordoz, egyetlen hibadomain több címkével. A második doboz sem független, ha a megosztott adminisztratív hitelesítő adat vagy a korlátlan útvonal legyőzi a határt, amelyet létre kellett volna hoznia.
Dokumentálja a végpontot, a visszafejtett útvonalat és az azt korlátozó vezérlést. Ez a három sor akkor is értelmes marad, bárminek nevezik is a megvalósítást.