A széles IPsec-szelektor nem engedély minden szolgáltatásra

Két fél megállapodik, hogy egy egész alhálózatot véd, és valaki ezt a megállapodást úgy olvassa, mint engedélyt az abban lévő minden szolgáltatás elérésére. Ez a mítosz: a szelektor azt mondja meg, milyen forgalmat hajlandó az alagút szállítani, és semmit sem mond arról, milyen szolgáltatásokat engedélyez a szervezet. Két eszköz jogszerűen megegyezhet egy széles címartományban, miközben a benne lévő hozzáférési szabályzat két portot engedélyez, és mindkét állítás egyszerre igaz marad.

A védett lefedettség nem felhatalmazás

A forgalomszelektor az alagút-megállapodás része. Szűkíti vagy megerősíti, mit titkosítanak a felek egymás között, és a széles szelektor gyakran a legegyszerűbb üzemeltetni való, amikor mindkét oldalnak sok folyamot kell szállítania. A szolgáltatásszűrő egy másik vezérlés a pálya más pontján, és arról dönt, mi használható ténylegesen a csomag visszafejtése után. A szűrő eltávolítása, hogy egy teszt átmenjen, szabályzatdöntést változtat balesetté.

Tartsa a két nyilvántartást külön a tervezési dokumentumban, mert az olvasó, aki csak a szelektort látja, olyan felhatalmazásra következtet, amelyet soha nem adtak meg. Két sor a változási nyilvántartásban megakadályozza ezt, és kevesebb időt vesz igénybe, mint a következő vita.

Írjon le egy folyamot mindkét végéről

Írja fel a kezdeményezőt, a válaszolót, a forrást és a célt az ábrázolt formában, a protokollt és mindkét portot. Aztán fordítsa meg ezeket a címkéket a másik végpont számára, mert egy kliens rövid életű forrásportja a válasz célportjává válik, a távoli hálózat pedig a helyivé. Az e megfordítás nélkül egyik oldalról a másikra másolt konfiguráció az oka annak, hogy a szűrők végül éppen a rossz irányt engedélyezik. Írja meg a táblázatot egyszer, és építse belőle mindkét szűrőt.

Egyezzen meg a kiválasztási modellben, mielőtt bármit másol, mert a szabályzatalapú tervezés és az útvonalalapú tervezés ugyanazt a szándékot fejezi ki különböző objektumokon keresztül. Írja a modell nevét a folyam mellé, különben a következő mérnök egy délutánt tölt olyan objektumok párosításával, amelyek soha nem voltak összehasonlíthatók.

Keresse meg a ténylegesen érvényes szűrőt

Egy ASA-n a VPN-szűrő egy csoportházirendhez kapcsolt ACL, amelyet a visszafejtés utáni és a titkosítás előtti forgalomra alkalmaznak. A Cisco csoportházirend-dokumentációja az öröklődést is leírja, beleértve egy felhasználói szintű értéket, amely felülírja a csoportházirend értékét. Lehet, hogy a szerkesztett ACL nem az az ACL, amely az Ön előtti munkamenetet vezérli. Ugyanez igaz a felhasználói objektumra, amely sok látható nyom nélkül felülírhatja a csoportot.

A tényleges munkamenetet vizsgálja, ne azt az objektumot, amelyre emlékszik, hogy módosította, és jegyezze fel, melyik házirend-objektum biztosítja. Ez az egy lépés meglepően sok olyan jelentést megold, hogy a szűrő helyes, de nem működik.

Irány, portok és a fordított eset

A dokumentált konvenció a távoli hálózatot, illetve a hozzárendelt távoli klienscímeket a forrás helyére, a helyi hálózatot pedig a cél helyére teszi, a válaszokat a címhelyek felcserélésével fejezve ki. A portszabályok e konvenció fölött ülnek, és több gondosságot érdemelnek, mint a címek.

A dokumentált modell megengedheti, hogy egy célport-szabály befolyásolja azt a fordított kezdeményezést, amely ugyanazt a forrásportot használja, ami azt jelenti, hogy a szűrő nem csupán egyirányú kérési szabály ártalmatlan válaszokkal. Gondolja végig kifejezetten mindkét kezdeményezési irányt, és foglalja bele az elutasítani kívánt esetet.

Ugyanez a dokumentáció a szűrőt a kezdeti kapcsolatokra korlátozza, tehát nem minden másodlagos csatorna egyetemes érvényesítése, amelyet egy vizsgált alkalmazás megnyit. Ahol a teljes szabályzatnak erre a lefedettségre van szüksége, az külön határhoz tartozik, nem pedig egy célján túlfeszített ACL-hez.

Három esetet teszteljen, mielőtt késznek nyilvánítja

Fogadja el a szándékolt folyamot, utasítson el egy szolgáltatást, amelyet a szabályzat tilt, és gyakorolja a fordított irányú esetet, amelyet végiggondolt. Futtassa őket jóváhagyott terv szerint ugyanazokkal az identitásokkal és szelektorokkal, amelyeket telepíteni fog. Az a teszt, amely csak azt mutatja, hogy az engedélyezett szolgáltatás működik, az alagutat bizonyítja, nem a szabályzatot.

Tartsa a kialkudott lefedettséget és a hozzáférési döntést két nyilvántartásként, mert annak elmagyarázása, mit engedélyez egy VPN, mindkettőt igényli.