NFS export zamčený na adresu VPN: co to neprokazuje
Pravidlo exportu kontroluje, odkud paket přišel; AUTH_SYS tvrdí místní UID a Kerberos ověřuje uživatele. Rozhodněte, co vaše souborová služba potřebuje.
Hostitel exportuje adresář na adresu VPN, připojení uspěje a v návrhu se zapíše, že přístup je ověřený. To, co toto pravidlo skutečně omezuje, je odkud pakety vypadají, že přicházejí. Zda člověk, který souborovou operaci řídí, je skutečně ten, za koho se vydává, závisí na bezpečnostním režimu NFS, a u většiny takových exportů ho nikdo nezměnil z výchozí hodnoty.
V jednom požadavku se mohou objevit tři identity
Protějšek VPN nese zapsanou identitu, například klientský certifikát nebo klíč protějšku. Vnitřní IP paket nese zdrojovou adresu. Souborová operace nese ty uživatelské údaje, které dodá její mechanismus NFS. Návrh, který adresu považuje za zástupce všech tří, tiše předpokládá právě tu část, kterou bylo třeba ověřit.
| 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 |
Zapsat ty tři řádky je celé cvičení. Většina sporu o tom, zda je export bezpečný, se zhroutí, jakmile je jasné, ve kterém řádku která kontrola žije.
Vlastnictví adresy je detail implementace
Brána může přijatému protějšku přidělit tunelovou adresu nebo pro něj autorizovat směrovanou podsíť. Zda pak implementace odmítne paket, jehož vnitřní zdroj patří jinému klientovi, je vlastnost této implementace a stojí za to ji ověřit, místo aby se předpokládala.
Kód serveru v uživatelském prostoru tradičního Community OpenVPN může například odmítnout zdroj spojený s jiným klientem dřív, než je paket doručen přes zařízení TUN. To je kontrola vlastnictví adresy se skutečnou hodnotou a stále to není ověření uživatele NFS, protože nic neříká o tom, který účet operaci provádí.
Překlad zdroje narušuje i to. Brána NAT může každého klienta prezentovat jako jednu adresu, a pak pravidlo exportu nedokáže rozlišit lidi za ní. Zdánlivá přesnost pravidla se pak stane fikcí udržovanou diagramem. Pokud na exportu záleží, držte adresování explicitní, místo abyste nechali překladatele rozhodovat, kdo platí za koho.
Přečtěte si bezpečnostní režim, než exportu uvěříte
Návod Red Hat k NFS odděluje sec=sys, který používá místní UNIX UID a GID přes AUTH_SYS, od režimů Kerberos. krb5 přidává ověření uživatele, krb5i přidává ochranu integrity a krb5p přidává ochranu soukromí provozu.
Údaje AUTH_SYS obsahují pole jako UID volajícího a identifikátory skupin a RFC 5531 jasně varuje, že tento režim sám o sobě neposkytuje žádnou bezpečnost a závisí na vnější ochraně. Provozování uvnitř VPN poskytuje ochranu přenosu a nic nemění na tvrzení uvnitř paketu.
exportfs -v
showmount -e nfs.example.internalPřečtěte si režim v tomto výstupu dřív než seznam klientů. Export, který vypadá omezený, může být omezený jen adresou, zatímco každý volající stále tvrdí, jaký UID chce.
Vyberte model a pak si ponechte oprávnění
Vyberte model ověřování souborové služby odpovídající klientům, které skutečně spravujete. Kerberos vyžaduje identitu a nasazení služby za ní, takže změna jedné volby připojení není migrace a prostě selže, dokud neexistují doména Kerberos, principály a keytaby.
V obou modelech si ponechte oprávnění exportu a autorizaci souborového systému, které omezují, co ověřený principál smí dělat. Ověření vám řekne, kdo se ptá; autorizace rozhoduje, zda má být odpověď ano. Sloučení obojího do jednoho nastavení je způsob, jak migrace nakonec udělí víc, než dávala stará konfigurace.
Použijte adresní pravidlo k jeho skutečnému účelu
Omezit službu na schválenou cestu a zdroje má stále smysl, včetně vstupní politiky hostitele, když koncový bod VPN a server NFS sdílejí stroj. Pravidla, která přeposílají provoz, neřídí požadavky mířící na službu běžící lokálně na stejném hostiteli. Tato mezera vysvětluje překvapivý počet exportů, které měly být soukromé. Zkontrolujte místní vstupní politiku výslovně, místo abyste předpokládali, že ji pravidla tunelu pokrývají.
Ověřte, že jiné rozhraní nebo brána s překladem zdroje nemůže pravidlo nečekaně splnit, a berte to jako důvod zjistit původ, nikoli jako tvrzení, že padělání adresy zaručí funkční připojení.
Proveďte tři akceptační případy místo jednoho. Začněte schváleným klientem v roli schváleného uživatele, pak totéž zopakujte z protějšku, který nikdy schválen nebyl, a potom zkuste něco, co schválený uživatel stále nesmí. Poté se zeptejte, co se změní, pokud je autorizovaný klient kompromitován, protože ověření přenosu nedělá každý proces na tom stroji důvěryhodným. Ukradený certifikát a zvědavý místní účet jsou různé problémy s různými kontrolami.