NFS-eksport låst til en VPN-adresse: hva det ikke beviser
En eksportregel kontrollerer hvor en pakke kom fra; AUTH_SYS erklærer en lokal UID, og Kerberos autentiserer en bruker. Avgjør hvilken filtjenesten din trenger.
En vert eksporterer en katalog til en VPN-adresse, monteringen lykkes, og designet blir skrevet ned som autentisert. Det regelen faktisk begrenser, er hvor pakkene ser ut til å komme fra. Om personen som styrer filoperasjonen er den hen utgir seg for å være, avhenger av NFS-sikkerhetsprofilen, og ved de fleste eksporter av denne typen har ingen endret den fra standarden.
Tre identiteter kan dukke opp i én forespørsel
VPN-peeren bærer en registrert identitet som et klientsertifikat eller en peer-nøkkel. Den indre IP-pakken bærer en kildeadresse. Filoperasjonen bærer de brukerpåloggingsdetaljene som dens NFS-mekanisme leverer. Et design som behandler adressen som en stedfortreder for alle tre, har stille antatt akkurat den delen som skulle verifiseres.
| 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 de tre radene er hele øvelsen. Mesteparten av diskusjonen om hvorvidt en eksport er trygg, kollapser når det er klart hvilken rad hver kontroll lever i.
Adresseierskap er en implementasjonsdetalj
En gateway kan tildele en tunneladresse til en akseptert peer, eller autorisere et rutet subnett for den. Om implementasjonen deretter avviser en pakke hvis indre kilde tilhører en annen klient, er en egenskap ved den implementasjonen, og det er verdt å kontrollere i stedet for å anta.
Den tradisjonelle Community OpenVPN brukerroms-tjenerkoden kan for eksempel avvise en kilde knyttet til en annen klient før pakken leveres gjennom TUN-enheten. Det er en adresseierskapskontroll med reell verdi, og den er fortsatt ikke NFS-brukerautentisering, fordi den ikke sier noe om hvilken konto som utfører operasjonen.
Kildetranslasjon tærer på selv dette. En NAT-gateway kan presentere hver klient som én adresse, og da kan en eksportregel ikke skille mellom menneskene bak. Regelenes tilsynelatende presisjon blir da en fiksjon som diagrammet opprettholder. Hvis eksporten betyr noe, hold adresseringen eksplisitt i stedet for å la en oversetter avgjøre hvem som teller som hvem.
Les sikkerhetsprofilen før du stoler på eksporten
Red Hats NFS-veiledning skiller sec=sys, som bruker lokale UNIX UID-er og GID-er gjennom AUTH_SYS, fra Kerberos-modusene. krb5 legger til brukerautentisering, krb5i legger til integritetsbeskyttelse, og krb5p legger til personvernbeskyttelse for trafikken.
AUTH_SYS-påloggingsdetaljene inneholder felt som kallerens UID og gruppe-ID-er, og RFC 5531 advarer klart om at denne profilen ikke gir sikkerhet i seg selv og avhenger av ekstern beskyttelse. Å kjøre den inne i en VPN gir beskyttelse for transporten og endrer ingenting i påstanden inne i pakken.
exportfs -v
showmount -e nfs.example.internalLes profilen i den utskriften før du leser klientlisten. En eksport som ser begrenset ut, kan være begrenset bare av adresse mens hver kaller fortsatt erklærer hvilken som helst UID.
Velg modellen, og behold deretter rettighetene
Velg autentiseringsmodellen for filtjenesten som passer for klientene du faktisk administrerer. Kerberos krever en identitet og en tjenesteutrulling bak seg, så å endre ett monteringsalternativ er ikke en migrering og vil rett og slett mislykkes til Kerberos-domenet, prinsipalene og keytab-filene finnes.
Under begge modellene, behold eksportrettighetene og filsystemautorisasjonen som begrenser hva den autentiserte prinsipalen kan gjøre. Autentisering forteller deg hvem som spør; autorisasjon avgjør om svaret skal være ja. Å smelte de to sammen i én innstilling er hvordan en migrering ender med å gi mer enn den gamle konfigurasjonen gjorde.
Bruk adresseregelen til dens egentlige formål
Å begrense tjenesten til den godkjente banen og kildene er fortsatt verdt det, inkludert vertens inndatapolicy når VPN-endepunktet og NFS-tjeneren deler maskin. Regler som videresender trafikk styrer ikke forespørsler rettet mot en tjeneste som kjører lokalt på samme vert. Dette gapet forklarer et overraskende antall eksporter som var ment private. Kontroller den lokale inndatapolicyen eksplisitt i stedet for å anta at tunnelreglene dekker den.
Kontroller at et annet grensesnitt eller en gateway med kildetranslasjon ikke uventet kan oppfylle regelen, og behandle det som en grunn til å fastslå opprinnelse, ikke som en påstand om at forfalskning av en adresse garanterer en fungerende montering.
Kjør tre aksepttilfeller i stedet for ett. Start med en godkjent klient som opptrer som godkjent bruker, gjenta deretter fra en peer som aldri ble godkjent, og forsøk så noe den godkjente brukeren fortsatt ikke har lov til. Spør etterpå hva som endres hvis en autorisert klient kompromitteres, fordi transportautentisering ikke gjør hver prosess på den maskinen pålitelig. Et stjålet sertifikat og en nysgjerrig lokal konto er forskjellige problemer med forskjellige kontroller.