NFS-eksporto ligita al VPN-adreso: kion ĝi ne pruvas
Eksporta regulo kontrolas, de kie venis la paketo; AUTH_SYS asertas lokan UID-on kaj Kerberos aŭtentikigas uzanton. Decidu, kiun via dosier-servo bezonas.
Gastiganto eksportas dosierujon al VPN-adreso, la muntado sukcesas, kaj la dezajno estas skribata kiel aŭtentikigita. Kion tiu regulo fakte limigas, estas de kie la paketoj ŝajnas veni. Ĉu la persono, kiu gvidas la dosier-operacion, estas tiu, kiun ĝi asertas esti, dependas de la NFS-sekureca gusto, kaj ĉe la plej multaj tiaj eksportoj neniu ŝanĝis ĝin de la defaŭlto.
Tri identoj povas aperi en unu peto
La VPN-paro portas enskribitan identon, kiel klientan atestilon aŭ paran ŝlosilon. La interna IP-paketo portas fontan adreson. La dosier-operacio portas tiujn uzantajn legitimilojn, kiujn ĝia NFS-mekanismo provizas. Dezajno, kiu traktas la adreson kiel anstataŭanton por ĉiuj tri, silente supozis ĝuste tiun parton, kiun ĝi devis kontroli.
| 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 |
Skribi tiujn tri vicojn estas la tuta ekzerco. La plej granda parto de la debato pri tio, ĉu eksporto estas sekura, kolapsas tuj kiam klaras, en kiu vico vivas ĉiu kontrolo.
Adresa posedo estas detaleto de efektivigo
Pordego povas asigni tunelan adreson al akceptita paro aŭ permesi enkursigitan subreton por ĝi. Ĉu la efektivigo poste rifuzas paketon, kies interna fonto apartenas al alia kliento, estas eco de tiu efektivigo, kaj indas kontroli ĝin anstataŭ supozi.
La tradicia Community OpenVPN uzantospaca servila kodo ekzemple povas rifuzi fonton asociitan kun alia kliento antaŭ ol la paketo estas liverita tra la TUN-aparato. Tio estas kontrolo de adresa posedo kun reala valoro, kaj ĝi ankoraŭ ne estas NFS-uzanta aŭtentikigo, ĉar ĝi diras nenion pri tio, kiu konto plenumas la operacion.
Fonta tradukado erozias eĉ tion. NAT-pordego povas prezenti ĉiun klienton kiel unu adreson, kaj tiam eksporta regulo ne povas distingi la homojn malantaŭ ĝi. La ŝajna precizeco de la regulo tiam fariĝas fikcio konservata de la diagramo. Se la eksporto gravas, tenu la adresadon eksplicita anstataŭ lasi tradukilon decidi, kiu validas kiel kiu.
Legu la sekurecan guston antaŭ ol fidi la eksporton
La NFS-gvidilo de Red Hat apartigas sec=sys, kiu uzas lokajn UNIX UID-ojn kaj GID-ojn per AUTH_SYS, de la Kerberos-reĝimoj. krb5 aldonas uzantan aŭtentikigon, krb5i aldonas protekton de integreco, kaj krb5p aldonas protekton de privateco por la trafiko.
La AUTH_SYS-legitimo enhavas kampojn kiel la UID de la alvokanto kaj grupajn identigilojn, kaj RFC 5531 avertas klare, ke tiu gusto mem ne provizas sekurecon kaj dependas de ekstera protekto. Ruligi ĝin ene de VPN provizas protekton por la transporto kaj ŝanĝas nenion en la aserto ene de la paketo.
exportfs -v
showmount -e nfs.example.internalLegu la guston en tiu eligo antaŭ ol legi la klientan liston. Eksporto, kiu ŝajnas limigita, eble limiĝas nur per adreso, dum ĉiu alvokanto ankoraŭ asertas kiun ajn UID ĝi volas.
Elektu la modelon, poste konservu la permesojn
Elektu la aŭtentikigan modelon de la dosier-servo taŭgan por la klientoj, kiujn vi efektive administras. Kerberos postulas identon kaj servan deplojon malantaŭ si, do ŝanĝi unu muntan opcion ne estas migrado kaj simple malsukcesos ĝis ekzistos la Kerberos-domajno, la principoj kaj la keytab-dosieroj.
Sub ambaŭ modeloj, konservu la eksportajn permesojn kaj la dosiersisteman rajtigon, kiuj limigas, kion la aŭtentikigita principo rajtas fari. Aŭtentikigo diras al vi, kiu demandas; rajtigo decidas, ĉu la respondo devus esti jes. Kunfandi tiujn du en unu agordon estas kiel migrado finiĝas per donado de pli ol la malnova agordo donis.
Uzu la adresan regulon por ĝia vera celo
Limigi la servon al la aprobita vojo kaj fontoj restas valore, inkluzive de la eniga politiko de la gastiganto kiam la VPN-finpunkto kaj la NFS-servilo dividas maŝinon. Reguloj, kiuj plusendas trafikon, ne regas petojn direktitajn al servo ruliĝanta loke sur la sama gastiganto. Tiu breĉo klarigas surprizan nombron da eksportoj, kiuj estis celitaj esti privataj. Kontrolu la lokan enigan politikon eksplicite anstataŭ supozi, ke la tunelaj reguloj kovras ĝin.
Kontrolu, ke alia interfaco aŭ pordego kun fonta tradukado ne povas neatendite plenumi la regulon, kaj traktu tion kiel kialon konstati devenon, ne kiel aserton ke falsado de adreso garantias funkciantan muntadon.
Rulu tri akceptajn kazojn anstataŭ unu. Komencu per aprobita kliento aganta kiel aprobita uzanto, poste ripetu de paro, kiu neniam estis aprobita, poste provu ion, kion la aprobita uzanto ankoraŭ ne rajtas fari. Poste demandu, kio ŝanĝiĝas se rajtigita kliento estas kompromitita, ĉar transporta aŭtentikigo ne faras ĉiun procezon sur tiu maŝino fidinda. Ŝtelita atestilo kaj scivola loka konto estas malsamaj problemoj kun malsamaj kontroloj.