VPN-címhez rögzített NFS-export: mit nem bizonyít
Az exportszabály azt ellenőrzi, honnan jött a csomag; az AUTH_SYS helyi UID-t állít, a Kerberos pedig felhasználót hitelesít. Döntse el, melyikre van szüksége a fájlszolgáltatásának.
Egy gazdagép egy könyvtárat exportál egy VPN-címre, a csatolás sikerül, és a terv úgy kerül dokumentálásra, hogy hitelesített. Amit ez a szabály valójában korlátoz, az az, honnan tűnnek a csomagok érkezőnek. Hogy a fájlműveletet vezérlő személy az-e, akinek mondja magát, az NFS biztonsági ízétől függ, és az ilyen exportok többségénél senki nem változtatta meg az alapértelmezéshez képest.
Három identitás jelenhet meg egyetlen kérésben
A VPN-társ egy bejegyzett identitást hordoz, például ügyféltanúsítványt vagy társ kulcsot. A belső IP-csomag forrás címet hordoz. A fájlművelet azt a felhasználói hitelesítő adatot hordozza, amelyet NFS-mechanizmusa biztosít. Az a terv, amely a címet mindhárom helyettesítőjeként kezeli, csendben éppen azt a részt feltételezte, amelyet ellenőrizni kellett volna.
| Identity | What it proves | What it does not |
|---|---|---|
| VPN peer | Which peer was accepted by the tunnel | Which user runs on that machine |
| Inner source address | Where the packet appears to originate | That only the intended client can use it |
| NFS credential | What the file service believes about the caller | Anything, if the flavour only asserts local IDs |
Ennek a három sornak a leírása az egész gyakorlat. A vitának a legnagyobb része arról, hogy biztonságos-e egy export, összeomlik, amint világossá válik, melyik sorban él az egyes ellenőrzések.
A cím tulajdonjoga megvalósítási részlet
Egy átjáró tunnelcímet rendelhet egy elfogadott társhoz, vagy engedélyezhet számára egy irányított alhálózatot. Hogy a megvalósítás ezután elutasít-e egy olyan csomagot, amelynek belső forrása egy másik ügyfélhez tartozik, e megvalósítás tulajdonsága, és érdemes ellenőrizni a feltételezés helyett.
A hagyományos Community OpenVPN felhasználói térben futó kiszolgálókódja például elutasíthat egy másik ügyfélhez tartozó forrást, mielőtt a csomag a TUN-eszközön keresztül kézbesítésre kerülne. Ez valódi értékű címtulajdon-ellenőrzés, és még mindig nem NFS-felhasználó-hitelesítés, mert semmit nem mond arról, melyik fiók végzi a műveletet.
A forrásfordítás még ezt is erodálja. Egy NAT-átjáró minden ügyfelet egyetlen címként jeleníthet meg, és akkor az exportszabály nem tud különbséget tenni a mögötte lévő emberek között. A szabály látszólagos pontossága ekkor a diagram által fenntartott fikcióvá válik. Ha az export számít, tartsa a címzést explicitnek, ahelyett hogy egy fordító döntené el, ki kit képvisel.
Olvassa el a biztonsági ízt, mielőtt megbízik az exportban
A Red Hat NFS-útmutatója elválasztja a sec=sys-t, amely helyi UNIX UID-okat és GID-okat használ az AUTH_SYS-en keresztül, a Kerberos módoktól. A krb5 felhasználóhitelesítést ad hozzá, a krb5i sértetlenségvédelmet ad hozzá, a krb5p pedig adatvédelmet ad a forgalomhoz.
Az AUTH_SYS hitelesítő adat olyan mezőket tartalmaz, mint a hívó UID-ja és a csoportazonosítók, és az RFC 5531 egyértelműen figyelmeztet, hogy ez az íz önmagában nem nyújt biztonságot, és külső védelemtől függ. VPN-en belüli futtatása védelmet ad a szállításnak, és semmit nem változtat a csomagban lévő állításon.
exportfs -v
showmount -e nfs.example.internalOlvassa el az ízt abban a kimenetben, mielőtt az ügyféllistát olvasná. Egy korlátozottnak tűnő export csak cím szerint lehet korlátozott, miközben minden hívó továbbra is azt az UID-t állítja, amelyiket akarja.
Válassza ki a modellt, majd tartsa meg az engedélyeket
Válassza ki a fájlszolgáltatás hitelesítési modelljét, amely a ténylegesen igazgatott ügyfelekhez illik. A Kerberos mögötte identitást és szolgáltatástelepítést igényel, így egy csatolási beállítás megváltoztatása nem migráció, és egyszerűen meghiúsul, amíg a Kerberos-tartomány, a principálisok és a keytabok nem léteznek.
Mindkét modell esetén tartsa meg az exportengedélyeket és a fájlrendszer-jogosultságot, amelyek korlátozzák, hogy a hitelesített principális mit tehet. A hitelesítés megmondja, ki kérdez; a jogosultság dönti el, hogy a válasznak igennel kell-e lennie. A kettő egyetlen beállításba olvasztása az az út, amelyen egy migráció végül többet ad, mint amennyit a régi konfiguráció adott.
Használja a címszabályt a valódi céljára
A szolgáltatás jóváhagyott útvonalra és forrásokra korlátozása továbbra is megéri, beleértve a gazdagép bemeneti szabályzatát, amikor a VPN-végpont és az NFS-kiszolgáló ugyanazt a gépet osztja. A forgalmat továbbító szabályok nem irányítják azokat a kéréseket, amelyek célja ugyanazon a gazdagépen helyben futó szolgáltatás. Ez a hézag meglepően sok exportot magyaráz, amelyeket privátnak szántak. Ellenőrizze kifejezetten a helyi bemeneti szabályzatot, ahelyett hogy feltételezné, hogy az alagútszabályok lefedik.
Ellenőrizze, hogy egy másik interfész vagy forrásfordítást végző átjáró nem tudja-e váratlanul teljesíteni a szabályt, és tekintse ezt az eredet megállapítása okának, nem pedig annak az állításnak, hogy egy cím hamisítása működő csatolást garantál.
Három elfogadási esetet futtasson egy helyett. Kezdje egy jóváhagyott ügyféllel, amely jóváhagyott felhasználóként jár el, majd ismételje meg egy soha nem jóváhagyott társtól, aztán próbáljon meg valamit, amit a jóváhagyott felhasználó még mindig nem tehet. Kérdezze meg utána, mi változik, ha egy engedélyezett ügyfél kompromittálódik, mert a szállítási hitelesítés nem tesz minden folyamatot megbízhatóvá azon a gépen. Egy ellopott tanúsítvány és egy kíváncsi helyi fiók különböző problémák különböző ellenőrzésekkel.