NFS-eksport låst til ei VPN-adresse: kva det ikkje beviser
Ei eksportregel kontrollerer kvar ei pakke kom frå; AUTH_SYS hevdar ein lokal UID, og Kerberos autentiserer ein brukar. Avgjer kva filtensesta di treng.
Ein vert eksporterer ein mappe til ei VPN-adresse, monteringa lykkast, og designet vert skrive ned som autentisert. Det regelen faktisk avgrensar, er kvar pakkane ser ut til å kome frå. Om personen som styrer filoperasjonen er den han eller ho gir seg ut for å vere, kjem an på NFS-tryggleiksprofilen, og ved dei fleste eksportar av denne typen har ingen endra han frå standarden.
Tre identitetar kan dukka opp i éin førespurnad
VPN-peeren ber ein registrert identitet som eit klientsertifikat eller ein peer-nøkkel. Den indre IP-pakka ber ei kjeldeadresse. Filoperasjonen ber dei brukarpåloggingsdetaljane som NFS-mekanismen hans leverer. Eit design som handsamar adressa som ein stand-in for alle tre, har stille rekna med nettopp den delen som skulle stadfestast.
| 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 |
Å skrive ned dei tre radene er heile øvinga. Det meste av diskusjonen om ein eksport er trygg, fell saman når det er klart kva rad kvar kontroll bur i.
Adresseigar er ein implementasjonsdetalj
Ein gateway kan tildele ei tunneladresse til ein akseptert peer, eller autorisere eit ruta subnett for han. Om implementasjonen deretter avviser ei pakke der den indre kjelda høyrer til ein annan klient, er ein eigenskap ved den implementasjonen, og det er verdt å kontrollere i staden for å rekne med det.
Den tradisjonelle Community OpenVPN brukarroms-tenarkoden kan til dømes avvise ei kjelde knytt til ein annan klient før pakka vert levert gjennom TUN-eininga. Det er ein adresseigarkontroll med reell verdi, og han er framleis ikkje NFS-brukarautentisering, fordi han ikkje seier noko om kva konto som utfører operasjonen.
Kjeldetranslasjon tærer på sjølv dette. Ein NAT-gateway kan presentere kvar klient som éi adresse, og då kan ei eksportregel ikkje skilje mellom menneska bak. Den tilsynelatande presisjonen til regelen vert då ein fiksjon som diagrammet held oppe. Viss eksporten betyr noko, hald adresseringa eksplisitt i staden for å la ein omsetjar avgjere kven som tel som kven.
Les tryggleiksprofilen før du stolar på eksporten
NFS-rettleiinga frå Red Hat skil sec=sys, som brukar lokale UNIX UID-ar og GID-ar gjennom AUTH_SYS, frå Kerberos-modusane. krb5 legg til brukarautentisering, krb5i legg til integritetsvern, og krb5p legg til personvern for trafikken.
AUTH_SYS-påloggingsdetaljane inneheld felt som UID-en til den som kallar, og gruppe-ID-ar, og RFC 5531 åtvarar tydeleg om at denne profilen ikkje gir tryggleik i seg sjølv og er avhengig av eksternt vern. Å køyre han inne i ein VPN gir vern for transporten og endrar ingenting i påstanden inne i pakka.
exportfs -v
showmount -e nfs.example.internalLes profilen i den utskrifta før du les klientlista. Ein eksport som ser avgrensa ut, kan berre vere avgrensa av adresse medan kvar kallar framleis hevdar kva som helst UID.
Vel modellen, og hald så på rettane
Vel autentiseringsmodellen for filtensesta som passar for klientane du faktisk administrerer. Kerberos krev ein identitet og ein tenesteutrulling bak seg, så å endre eitt monteringsval er ikkje ein migrasjon og vil rett og slett mislykkast til Kerberos-domenet, prinsipalane og keytab-filene finst.
Under begge modellane, hald på eksportrettane og filsystemautorisasjonen som avgrensar kva den autentiserte prinsipalen kan gjere. Autentisering fortel deg kven som spør; autorisasjon avgjer om svaret skal vere ja. Å smelte dei to saman i éi innstilling er korleis ein migrasjon endar med å gi meir enn den gamle konfigurasjonen gjorde.
Bruk adresseregelen til det eigentlege føremålet sitt
Å avgrense tenesta til den godkjende vegen og kjeldene er framleis verdt det, inkludert inndatapolitikken til verten når VPN-endepunktet og NFS-tenaren deler maskin. Reglar som vidaresender trafikk styrer ikkje førespurnader retta mot ei teneste som køyrer lokalt på same vert. Dette gapet forklarer eit overraskande tal eksportar som var meinte å vere private. Kontroller den lokale inndatapolitikken eksplisitt i staden for å rekne med at tunnelreglane dekkjer han.
Kontroller at eit anna grensesnitt eller ein gateway med kjeldetranslasjon ikkje uventa kan oppfylle regelen, og handsam det som ein grunn til å fastslå opphav, ikkje som ein påstand om at forfalsking av ei adresse garanterer ei fungerande montering.
Køyr tre aksepttilfelle i staden for eitt. Start med ein godkjend klient som opptrer som godkjend brukar, gjenta deretter frå ein peer som aldri vart godkjend, og prøv så noko den godkjende brukaren framleis ikkje har lov til. Spør etterpå kva som endrar seg om ein autorisert klient vert kompromittert, fordi transportautentisering ikkje gjer kvar prosess på den maskina påliteleg. Eit stole sertifikat og ein nysgjerrig lokal konto er ulike problem med ulike kontrollar.