NFS-uitvoer wat aan 'n VPN-adres gekoppel is: wat dit nie bewys nie
Uitvoerreels kontroleer waar 'n pakkie vandaan kom; AUTH_SYS verklaar 'n plaaslike UID en Kerberos verifieer 'n gebruiker. Besluit watter een jou lêerdiens nodig het.
'n Gasheer voer 'n gids uit na 'n VPN-adres, die montering slaag, en die ontwerp word neergeskryf as geauthentiseer. Wat daardie reël werklik beperk, is waar die pakkies blyk vandaan te kom. Of die persoon wat die lêerbewerking dryf werklik is wie hy sê hy is, hang af van die NFS-sekuriteitsflavour, en by die meeste uitvoere van hierdie soort het niemand dit van die verstek verander nie.
Drie identiteite kan in een versoek opduik
Die VPN-eweknie dra 'n ingeskrewe identiteit soos 'n kliëntsertifikaat of 'n eweknie-sleutel. Die binneste IP-pakket dra 'n bronadres. Die lêerbewerking dra watter gebruikersgeloofsbrief sy NFS-meganisme ook voorsien. 'n Ontwerp wat die adres as plaasvervanger vir al drie behandel, het stilweg die deel aanvaar wat hy moes verifieer.
| 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 |
Om daardie drie rye neer te skryf, is die hele oefening. Die meeste van die argument oor of 'n uitvoer veilig is, val weg sodra dit duidelik is in watter ry elke beheer lê.
Adres-eienaarskap is 'n implementeringsbesonderheid
'n Poort kan 'n tonneladres aan 'n aanvaarde eweknie toeken, of 'n geroteerde subnet daarvoor magtig. Of die implementering dan 'n pakket weier waarvan die binneste bron aan 'n ander kliënt behoort, is 'n eienskap van daardie implementering, en dit is die moeite werd om na te gaan eerder as om dit te aanvaar.
Tradisionele Community OpenVPN gebruikerspasie-bedienerkode kan byvoorbeeld 'n bron verwerp wat met 'n ander kliënt geassosieer word voordat die pakket deur die TUN-toestel afgelewer word. Dit is 'n adres-eienaarskapkontrole met werklike waarde, en dit is steeds nie NFS-gebruikersverifikasie nie, want dit sê niks oor watter rekening die bewerking uitvoer nie.
Brontranslasie verweer selfs dit. 'n NAT-poort kan elke kliënt as een adres voorstel, en dan kan 'n uitvoerreël nie tussen die mense daar agter onderskei nie. Die reël se skynbare presisie word dan 'n fiksie wat deur die diagram in stand gehou word. As die uitvoer saak maak, hou die adressering eksplisiet eerder as om 'n vertaler te laat besluit wie as wie tel.
Lees die sekuriteitsflavour voordat jy die uitvoer vertrou
Red Hat se NFS-riglyne skei sec=sys, wat plaaslike UNIX UID's en GID's deur AUTH_SYS gebruik, van die Kerberos-modusse. krb5 voeg gebruikersverifikasie by, krb5i voeg integriteitsbeskerming by, en krb5p voeg privaatheidsbeskerming vir die verkeer by.
Die AUTH_SYS-geloofsbrief bevat velde soos die oproeper se UID en groep-ID's, en RFC 5531 waarsku duidelik dat hierdie flavour op sigself geen sekuriteit bied nie en van eksterne beskerming afhanklik is. Om dit binne 'n VPN te laat loop, voorsien beskerming vir die vervoer en verander niks aan die bewering binne die pakket nie.
exportfs -v
showmount -e nfs.example.internalLees die flavour in daardie uitset voordat jy die kliëntlys lees. 'n Uitvoer wat beperk lyk, kan slegs deur adres beperk wees terwyl elke oproeper steeds enige UID verklaar wat hy wil.
Kies die model en behou dan die regte
Kies die lêerdiens-verifikasiemodel wat pas by die kliënte wat jy werklik bestuur. Kerberos vereis 'n identiteit en diensontplooiing daar agter, so om een monteringsopsie te verander is nie 'n migrasie nie en sal eenvoudig misluk totdat die Kerberos-domein, principalen en keytabs bestaan.
Onder enige van die twee modelle, behou die uitvoerregte en die lêerstelselmagtiging wat beperk wat die geauthentiseerde principal mag doen. Verifikasie sê vir jou wie vra; magtiging besluit of die antwoord ja moet wees. Om daardie twee in een instelling saam te voeg, is hoe 'n migrasie meer toestaan as wat die ou konfigurasie gedoen het.
Gebruik die adresreël vir sy werklike doel
Om die diens tot die goedgekeurde pad en bronne te beperk, bly die moeite werd, insluitend die gasheer-invoerbeleid wanneer die VPN-eindpunt en die NFS-bediener 'n masjien deel. Reëls wat verkeer aanstuur, beheer nie versoeke wat gerig is op 'n diens wat plaaslik op dieselfde gasheer loop nie. Daardie gaping verklaar 'n verrassende aantal uitvoere wat bedoel was om privaat te wees. Kontroleer die plaaslike invoerbeleid eksplisiet eerder as om te aanvaar dat die tonnelreëls dit dek.
Kontroleer dat 'n ander koppelvlak of 'n brontranslasie-poort die reël nie onverwags kan bevredig nie, en beskou dit as 'n rede om herkoms vas te stel eerder as 'n bewering dat die vervalsing van 'n adres 'n werkende montering waarborg.
Hardloop drie aanvaardingstoetse eerder as een. Begin met 'n goedgekeurde kliënt wat as 'n goedgekeurde gebruiker optree, herhaal dan vanaf 'n eweknie wat nooit goedgekeur is nie, en probeer dan iets wat die goedgekeurde gebruiker steeds nie mag doen nie. Vra daarna wat verander as 'n gemagtigde kliënt gekompromitteer word, want vervoerverifikasie maak nie elke proses op daardie masjien betroubaar nie. 'n Gesteelde sertifikaat en 'n nuuskierige plaaslike rekening is verskillende probleme met verskillende beheermaatreëls.