NFS-eksport låst til en VPN-adresse: hvad det ikke beviser
En eksportregel kontrollerer, hvor en pakke kom fra; AUTH_SYS erklærer et lokalt UID, og Kerberos autentificerer en bruger. Afgør, hvilken din filservice har brug for.
En vært eksporterer en mappe til en VPN-adresse, monteringen lykkes, og designet bliver skrevet ned som autentificeret. Det, reglen faktisk begrænser, er, hvor pakkerne ser ud til at komme fra. Om personen bag filoperationen er den, vedkommende udgiver sig for at være, afhænger af NFS-sikkerhedsprofilen, og ved de fleste eksporter af denne slags har ingen ændret den fra standarden.
Tre identiteter kan optræde i én anmodning
VPN-peeren bærer en registreret identitet som et klientcertifikat eller en peer-nøgle. Den indre IP-pakke bærer en kildeadresse. Filoperationen bærer de brugeroplysninger, som dens NFS-mekanisme leverer. Et design, der behandler adressen som stedfortræder for alle tre, har stiltiende antaget netop den del, der skulle verificeres.
| 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 |
At skrive de tre rækker ned er hele øvelsen. Det meste af diskussionen om, hvorvidt en eksport er sikker, falder sammen, når det er klart, hvilken række hver kontrol hører til i.
Adresseejerskab er en implementeringsdetalje
En gateway kan tildele en tunneladresse til en accepteret peer eller godkende et routet subnet til den. Om implementeringen derefter afviser en pakke, hvis indre kilde tilhører en anden klient, er en egenskab ved den implementering, og det er værd at kontrollere i stedet for at antage.
Den traditionelle Community OpenVPN serverkode i brugsrummet kan for eksempel afvise en kilde, der er knyttet til en anden klient, før pakken leveres gennem TUN-enheden. Det er en adresseejerskabskontrol med reel værdi, og det er stadig ikke NFS-brugerautentificering, fordi den intet siger om, hvilken konto der udfører operationen.
Kildetranslation slider endda på det. En NAT-gateway kan fremstille hver klient som én adresse, og så kan en eksportregel ikke skelne mellem personerne bag. Reglens tilsyneladende præcision bliver så en fiktion, som diagrammet opretholder. Hvis eksporten betyder noget, så hold adresseringen eksplicit i stedet for at lade en translator afgøre, hvem der tæller som hvem.
Læs sikkerhedsprofilen, før du stoler på eksporten
Red Hats NFS-vejledning skelner sec=sys, som bruger lokale UNIX UID'er og GID'er gennem AUTH_SYS, fra Kerberos-tilstandene. krb5 tilføjer brugerautentificering, krb5i tilføjer integritetsbeskyttelse, og krb5p tilføjer privatlivsbeskyttelse for trafikken.
AUTH_SYS-oplysningerne indeholder felter som kalderens UID og gruppe-ID'er, og RFC 5531 advarer klart om, at denne profil ikke i sig selv giver sikkerhed og afhænger af ekstern beskyttelse. At køre den inde i en VPN giver beskyttelse af transporten og ændrer intet ved påstanden inde i pakken.
exportfs -v
showmount -e nfs.example.internalLæs profilen i det output, før du læser klientlisten. En eksport, der ser begrænset ud, kan være begrænset alene ved adresse, mens hver kalder stadig erklærer lige det UID, den vil.
Vælg modellen, og behold så rettighederne
Vælg den autentificeringsmodel for filservice, der passer til de klienter, du faktisk administrerer. Kerberos kræver en identitet og en serviceudrulning bag sig, så at ændre én monteringsindstilling er ikke en migrering og vil ganske enkelt mislykkes, indtil Kerberos-domænet, principalerne og keytab-filerne findes.
Under begge modeller skal du beholde eksportrettighederne og filsystemets autorisation, som begrænser, hvad den autentificerede principal må gøre. Autentificering fortæller dig, hvem der spørger; autorisation afgør, om svaret skal være ja. At smelte de to sammen i én indstilling er måden, hvorpå en migrering ender med at give mere, end den gamle konfiguration gjorde.
Brug adresseregelen til dens egentlige formål
At begrænse tjenesten til den godkendte vej og de godkendte kilder er stadig værd at gøre, inklusive værtsinputpolitikken når VPN-endepunktet og NFS-serveren deler maskine. Regler, der videresender trafik, styrer ikke anmodninger rettet mod en tjeneste, der kører lokalt på samme vært. Det hul forklarer et overraskende antal eksporter, som var ment private. Kontroller den lokale inputpolitik eksplicit i stedet for at antage, at tunnelreglerne dækker den.
Kontroller, at en anden grænseflade eller en gateway med kildetranslation ikke uventet kan opfylde reglen, og betragt det som en grund til at fastslå oprindelse i stedet for en påstand om, at forfalskning af en adresse garanterer en fungerende montering.
Kør tre accepttilfælde i stedet for ét. Start med en godkendt klient, der optræder som godkendt bruger, gentag derefter fra en peer, der aldrig blev godkendt, og forsøg så noget, som den godkendte bruger stadig ikke må. Spørg bagefter, hvad der ændrer sig, hvis en autoriseret klient kompromitteres, fordi transportautentificering ikke gør hver proces på den maskine troværdig. Et stjålent certifikat og en nysgerrig lokal konto er forskellige problemer med forskellige kontroller.