NFS-export vastgezet op een VPN-adres: wat het niet bewijst
Een exportregel controleert waar een pakket vandaan kwam; AUTH_SYS beweert een lokale UID en Kerberos authenticeert een gebruiker. Bepaal welke uw bestandsservice nodig heeft.
Een host exporteert een map naar een VPN-adres, de mount slaagt en het ontwerp wordt vastgelegd als geauthenticeerd. Wat die regel feitelijk beperkt, is waar de pakketten lijken vandaan te komen. Of de persoon die de bestandsbewerking uitvoert is wie hij zegt te zijn, hangt af van de NFS-beveiligingsvariant, en bij de meeste exporten van dit soort heeft niemand die van de standaard veranderd.
Drie identiteiten kunnen in één verzoek voorkomen
De VPN-peer draagt een ingeschreven identiteit, zoals een clientcertificaat of een peersleutel. Het binnenste IP-pakket draagt een bronadres. De bestandsbewerking draagt welke gebruikersreferentie het NFS-mechanisme ook levert. Een ontwerp dat het adres als plaatsvervanger voor alle drie behandelt, heeft stilzwijgend juist dat deel aangenomen dat moest worden geverifieerd.
| 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 |
Die drie regels opschrijven is de hele oefening. Het grootste deel van de discussie of een export veilig is, stort in zodra duidelijk is in welke regel elke controle woont.
Adreseigendom is een implementatiedetail
Een gateway kan een tunneladres toewijzen aan een geaccepteerde peer, of een gerouteerd subnet ervoor autoriseren. Of de implementatie vervolgens een pakket weigert waarvan de binnenste bron bij een andere client hoort, is een eigenschap van die implementatie, en dat is het controleren waard in plaats van aan te nemen.
De traditionele Community OpenVPN gebruikersruimte-servercode kan bijvoorbeeld een bron weigeren die bij een andere client hoort voordat het pakket via het TUN-apparaat wordt afgeleverd. Dat is een adreseigendomscontrole met echte waarde, en het is nog steeds geen NFS-gebruikersauthenticatie, omdat het niets zegt over welk account de bewerking uitvoert.
Brontranslatie erodeert zelfs dat. Een NAT-gateway kan elke client als één adres presenteren, en dan kan een exportregel de mensen erachter niet onderscheiden. De schijnbare precisie van de regel wordt dan een fictie die door het diagram in stand wordt gehouden. Als de export ertoe doet, houd de adressering expliciet in plaats van een vertaler te laten beslissen wie voor wie telt.
Lees de beveiligingsvariant voordat u de export vertrouwt
De NFS-richtlijn van Red Hat scheidt sec=sys, dat lokale UNIX UID's en GID's via AUTH_SYS gebruikt, van de Kerberos-modi. krb5 voegt gebruikersauthenticatie toe, krb5i voegt integriteitsbescherming toe en krb5p voegt privacybescherming voor het verkeer toe.
De AUTH_SYS-referentie bevat velden zoals de UID van de aanroeper en groeps-ID's, en RFC 5531 waarschuwt duidelijk dat deze variant op zichzelf geen beveiliging biedt en van externe bescherming afhangt. Hem binnen een VPN draaien levert bescherming voor het transport en verandert niets aan de bewering in het pakket.
exportfs -v
showmount -e nfs.example.internalLees de variant in die uitvoer voordat u de cliëntlijst leest. Een export die beperkt lijkt, kan alleen door het adres beperkt zijn terwijl elke aanroeper nog steeds elke UID beweert die hem uitkomt.
Kies het model en behoud dan de rechten
Kies het authenticatiemodel van de bestandsservice dat past bij de clients die u feitelijk beheert. Kerberos vereist een identiteit en een service-implementatie erachter, dus één mountoptie wijzigen is geen migratie en zal eenvoudigweg mislukken totdat het Kerberos-domein, de principals en de keytabs bestaan.
Behoud onder beide modellen de exportrechten en de bestandssysteemautorisatie die beperken wat de geauthenticeerde principal mag doen. Authenticatie vertelt u wie er vraagt; autorisatie beslist of het antwoord ja moet zijn. Die twee samenvoegen tot één instelling is hoe een migratie meer gaat verlenen dan de oude configuratie.
Gebruik de adresregel voor het echte doel
De service beperken tot het goedgekeurde pad en de goedgekeurde bronnen blijft de moeite waard, inclusief het host-invoerbeleid wanneer het VPN-eindpunt en de NFS-server dezelfde machine delen. Regels die verkeer doorsturen beheersen geen verzoeken die gericht zijn aan een service die lokaal op dezelfde host draait. Die leemte verklaart een verrassend aantal exporten die privé hadden moeten zijn. Controleer het lokale invoerbeleid expliciet in plaats van aan te nemen dat de tunnelregels het dekken.
Controleer dat een andere interface of een gateway met brontranslatie de regel niet onverwacht kan vervullen, en beschouw dat als een reden om herkomst vast te stellen, niet als de bewering dat het vervalsen van een adres een werkende mount garandeert.
Voer drie acceptatiegevallen uit in plaats van één. Begin met een goedgekeurde client die als goedgekeurde gebruiker optreedt, herhaal daarna vanaf een peer die nooit is goedgekeurd, en probeer vervolgens iets wat de goedgekeurde gebruiker nog steeds niet mag. Vraag daarna wat er verandert als een geautoriseerde client wordt gecompromitteerd, want transportauthenticatie maakt niet elk proces op die machine betrouwbaar. Een gestolen certificaat en een nieuwsgierig lokaal account zijn verschillende problemen met verschillende controles.