NFS-export låst till en VPN-adress: vad det inte bevisar
En exportregel kontrollerar varifrån ett paket kom; AUTH_SYS hävdar ett lokalt UID och Kerberos autentiserar en användare. Avgör vilken din filtjänst behöver.
En värd exporterar en katalog till en VPN-adress, monteringen lyckas och designen skrivs ner som autentiserad. Det regeln faktiskt begränsar är varifrån paketen tycks komma. Om personen som driver filoperationen är den hen utger sig för att vara beror på NFS-säkerhetsprofilen, och vid de flesta exporter av det här slaget har ingen ändrat den från standardvärdet.
Tre identiteter kan dyka upp i en och samma begäran
VPN-peeren bär en registrerad identitet, som ett klientcertifikat eller en peer-nyckel. Det inre IP-paketet bär en källadress. Filoperationen bär de användaruppgifter som dess NFS-mekanism tillhandahåller. En design som behandlar adressen som ersättning för alla tre har tyst antagit just den del som skulle verifieras.
| 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 |
Att skriva ner de tre raderna är hela övningen. Större delen av debatten om huruvida en export är säker kollapsar när det står klart vilken rad varje kontroll lever i.
Adressägande är en implementeringsdetalj
En gateway kan tilldela en tunneladress till en accepterad peer eller auktorisera ett routat subnät för den. Om implementationen sedan avvisar ett paket vars inre källa tillhör en annan klient är en egenskap hos den implementationen, och det är värt att kontrollera i stället för att anta.
Den traditionella Community OpenVPN användarrymds-serverkoden kan till exempel avvisa en källa kopplad till en annan klient innan paketet levereras genom TUN-enheten. Det är en adressägandekontroll med verkligt värde, och den är fortfarande inte NFS-användarautentisering, eftersom den inte säger något om vilket konto som utför operationen.
Källtranslokation urholkar även det. En NAT-gateway kan presentera varje klient som en enda adress, och då kan en exportregel inte skilja mellan människorna bakom. Regelns skenbara precision blir då en fiktion som diagrammet upprätthåller. Om exporten spelar roll, håll adresseringen explicit i stället för att låta en översättare avgöra vem som räknas som vem.
Läs säkerhetsprofilen innan du litar på exporten
Red Hats NFS-vägledning skiljer på sec=sys, som använder lokala UNIX UID och GID via AUTH_SYS, och Kerberos-lägena. krb5 lägger till användarautentisering, krb5i lägger till integritetsskydd och krb5p lägger till sekretesskydd för trafiken.
AUTH_SYS-uppgifterna innehåller fält som anroparens UID och grupp-ID:n, och RFC 5531 varnar tydligt för att denna profil inte ger säkerhet i sig själv och är beroende av externt skydd. Att köra den inom en VPN ger skydd för transporten och ändrar ingenting i påståendet inne i paketet.
exportfs -v
showmount -e nfs.example.internalLäs profilen i den utskriften innan du läser klientlistan. En export som ser begränsad ut kan vara begränsad enbart av adressen medan varje anropare fortfarande hävdar vilket UID som helst.
Välj modellen och behåll sedan behörigheterna
Välj autentiseringsmodell för filtjänsten som passar de klienter du faktiskt administrerar. Kerberos kräver en identitet och en tjänsteutrullning bakom sig, så att ändra ett monteringsalternativ är inte en migrering och kommer helt enkelt att misslyckas tills Kerberos-domänen, principalerna och keytab-filerna finns.
Under båda modellerna, behåll exportbehörigheterna och filsystemets auktorisering som begränsar vad den autentiserade principalen får göra. Autentisering talar om för dig vem som frågar; auktorisering avgör om svaret ska vara ja. Att smälta samman de två till en inställning är hur en migrering till slut ger mer än den gamla konfigurationen gjorde.
Använd adressregeln för dess verkliga syfte
Att begränsa tjänsten till den godkända vägen och källorna är fortfarande värt det, inklusive värdens indatapolicy när VPN-slutpunkten och NFS-servern delar maskin. Regler som vidarebefordrar trafik styr inte förfrågningar riktade mot en tjänst som körs lokalt på samma värd. Den luckan förklarar ett förvånansvärt antal exporter som var avsedda att vara privata. Kontrollera den lokala indatapolicyn explicit i stället för att anta att tunnelreglerna täcker den.
Kontrollera att ett annat gränssnitt eller en gateway med källtranslokation inte oväntat kan uppfylla regeln, och behandla det som ett skäl att fastställa ursprung, inte som ett påstående att förfalskning av en adress garanterar en fungerande montering.
Kör tre acceptfall i stället för ett. Börja med en godkänd klient som agerar godkänd användare, upprepa sedan från en peer som aldrig godkändes och försök därefter något som den godkända användaren fortfarande inte får göra. Fråga efteråt vad som ändras om en auktoriserad klient komprometteras, eftersom transportautentisering inte gör varje process på den maskinen pålitlig. Ett stulet certifikat och ett nyfiket lokalt konto är olika problem med olika kontroller.