Egy nem megbízható VPN három külön határ, nem egy

Az „nem bízom ebben a VPN-ben” általában három állítás egyetlen mondatba öltöztetve. A hálózat távoli partnerei elérhetik a gazdagép szolgáltatásait, az alagutat üzemeltető szereplő láthatja a rajta átfolyó forgalmat, és az Ön által telepített kliensszoftver módosíthatja a gép hálózati szabályzatát. A hit, amelyet érdemes helyesbíteni, az, hogy egy tűzfal-szabály, egy virtuális gép vagy a gondos operációsrendszer-választás mindháromra választ ad. Minden intézkedés pontosan egyre ad választ.

A mítosz: egyetlen kontroll lefedi a teljes kockázatot

A szokásos feltevés, hogy a nem megbízható hálózathoz csatlakozás egyetlen döntés egyetlen enyhítéssel. Az emberek azt a kontrollt választják, amelyben már bíznak, alkalmazzák, és a kockázatot elintézettnek tekintik: a tűzfal be van kapcsolva, a munkaterület eldobható, a kliens jó hírű szállítótól származik.

Ezek a kontrollok nem fedik egymást úgy, ahogy a feltevés sugallja. A gazdagép tűzfala korlátozza, mit érhet el egy távoli partner, és semmit sem tesz egy olyan üzemeltetővel szemben, aki lezárja az Ön TLS-ét. A virtuális gép elválasztja a munkaterületet a gazdagép fájljaitól, és semmit sem tesz egy olyan klienskomponenssel szemben, amelynek engedélyezett a mindkettő alatti hálózati verem újrakonfigurálása. Annak a határnak a megnevezése, amelyet az egyes kontrollok valóban létrehoznak, maga a teljes gyakorlat.

Szétválasztásuk azt is megmondja, melyik kockázatot választotta elfogadni. A legtöbb valódi döntés egy határt enyhít és egy másikat eltűr, ami rendben van, amíg a változásjegyzőkönyv megmondja, melyik melyik.

Mit érhet el valójában a távoli partner

Kezdje a figyelő szolgáltatásokkal. Az az alagút-interfész, amelyet széles körben megbízhatónak tekintenek, mert csomagjai titkosítva érkeztek, a szokásos hiba, és minden helyi figyelőt lehetséges célponttá tesz bárki számára azon a hálózaton. A titkosítás a két végpont közötti vezetéket védi; semmit sem mond a túloldali partner szándékáról.

ss -tulpn
sudo nft list ruleset
ip -br addr

A szolgáltatásokat ahhoz a címhez kösse, amelyre szükségük van, ne minden interfészhez, és csak a jóváhagyott feladat által igényelt műveleteket engedélyezze. Tartsa kifejezettnek a továbbítást, a hidat és az alkalmazásproxy-t, mert két hálózati csatlakozás önmagában nem hoz létre tranzitútvonalat, egy proxy-szabály viszont biztosan.

Egy jóváhagyott eldobható munkaterület csökkenti, mit érhet el a távoli hálózat, de csak akkor, ha megosztási konfigurációja megfelel az állításnak. A megosztott mappák, a vágólap-integráció, a hitelesítő ügynökök és a felügyeleti csatornák mind átlépik azt a határt, amelyet a munkaterületnek létre kellett volna hoznia. A munkaterület címkéje semmit sem bizonyít arról, melyek nyitottak közülük.

A NIST nulla bizalmon alapuló architektúrája kimondja az e mögött álló elvet: a hálózati hely önmagában nem ad hallgatólagos bizalmat. Az erőforrás-hitelesítésnek az alagút beengedése után is van munkája, és annak a kérdésnek is, ki más osztozik ezen a hálózaton.

Mit láthat az útvonalon lévő üzemeltető

A VPN áthelyezi a forgalmát az útvonal egy másik pontjára; nem ad hozzá alkalmazásttitkosítást. Ha a szolgáltató lezárja az Ön TLS-ét, a szolgáltató olvashatja azt, amit a böngészője egyébként védett volna, és ezen semmilyen helyi tűzfal-szabály nem változtat.

Őrizze meg a szokásos tanúsítvány-ellenőrzést a valódi célhoz, és értse a névfeloldó és a metaadatok útvonalát, mert egy DNS-lekérdezés többet árulhat el, mint az azt megelőző hasznos teher. A metaadatok önmagukban, vagyis hogy mely címeket és mikor kereste fel, gyakran megválaszolják az üzemeltető kérdését anélkül, hogy bármi szükség lenne a tartalom olvasására. Ezért „a forgalom titkosított” és „a forgalom magánjellegű” különböző állítások.

Ha ez a láthatóság a feladat szempontjából elfogadhatatlan, a válasz egy másik jóváhagyott architektúra, nem több helyi szűrés. A helyi szűrés nem tud eltávolítani egy megfigyelőt arról az útvonalról, amelyen még ül.

Mit változtathat a helyi kliens

Ez az a határ, amelyet az emberek kihagynak, és ez teszi a másik kettőt tárgytalanná. Linuxon a CAP_NET_ADMIN lefedi az interfész-konfigurációt, a tűzfal-felügyeletet és az útvonal-módosításokat a saját hálózati környezetében. Az ezzel a képességgel rendelkező szoftver átírhatja az éppen megírt szabályzatot.

getcap /usr/sbin/openvpn
systemd-analyze security vpn-client.service
ip netns list

A hálózati névtér valódi határ a hálózati állapot számára, és gyenge minden másra: nem izolálja a fájlrendszert vagy a hitelesítő tárat. Egy rétegként kezelje, ne az egész probléma konténereként.

Szerezze be a klienst és konfigurációját karbantartott forrásból, vizsgálja felül a kért jogosultságot, és tartsa a kiemelt összetevőket rendszergazdai ellenőrzés alatt. Egy virtuális gép lehet egy minősített értékelési határ része anélkül, hogy engedéllyé válna egy megmagyarázatlan telepítő futtatására értékes hitelesítő adatok mellett. A telepítő azzal a jogosultsággal fut, amelyet ad neki, és ez a jogosultság a határ.

Írja le, melyik határt fogadta el

Fejezze be egy mondattal, amely négy dolgot nevez meg: a megbízható helyi kódot, az engedélyezett távoli hozzáférést, a védett alkalmazásadatokat és a fennmaradó üzemeltetői viszonyt. Ez a mondat többet ér, mint az az általános állítás, hogy egy VM, egy operációs rendszer vagy egy vírusirtó termék biztonságossá tett egy ellenséges hálózatot.

Ezután erősítse meg, hogy a szűk művelet működik, és a szükséges elutasítás továbbra is fennáll, még azután is, hogy az alagút leesik. Az a határ, amely csak addig létezik, amíg az alagút áll, nem az a határ, amelyet dokumentált.

Egyetlen teszt sem bizonyítja, hogy minden sebezhetőség hiányzik, és az ellenkezőjét állító átvizsgálás túlzás. Az őszinte kimenet megnevezi a maradék kockázatot és az azt elfogadó személyt.