VPN-osoitteeseen lukittu NFS-vienti: mitä se ei todista
Vientisääntö tarkistaa, mistä paketti tuli; AUTH_SYS väittää paikallista UID:tä ja Kerberos todentaa käyttäjän. Päätä, kumpaa tiedostopalvelusi tarvitsee.
Isäntä vie hakemiston VPN-osoitteeseen, liitos onnistuu ja suunnitelma kirjataan todennetuksi. Se, mitä sääntö todella rajoittaa, on se, mistä paketit näyttävät tulevan. Se, onko tiedostotoimintoa ohjaava henkilö se, joksi hän väittää itseään, riippuu NFS:n suojaustavasta, eikä useimmissa tällaisissa vienneissä kukaan ole muuttanut sitä oletuksesta.
Kolme identiteettiä voi esiintyä yhdessä pyynnössä
VPN-vertaiskumppani kantaa rekisteröidyn identiteetin, kuten asiakasvarmenne tai vertaisavain. Sisempi IP-paketti kantaa lähdeosoitteen. Tiedostotoiminto kantaa ne käyttäjätunnistetiedot, jotka sen NFS-mekanismi tarjoaa. Suunnitelma, joka kohtelee osoitetta kaikkien kolmen sijaisena, on hiljaa olettanut juuri sen osan, joka olisi pitänyt todentaa.
| 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 |
Noiden kolmen rivin kirjoittaminen on koko harjoitus. Suurin osa väittelystä siitä, onko vienti turvallinen, romahtaa, kun selviää, millä rivillä mikäkin valvonta elää.
Osoitteen omistus on toteutuksen yksityiskohta
Yhdyskäytävä voi antaa hyväksytylle vertaiskumppanille tunneliosoitteen tai sallia sille reititetyn aliverkon. Se, hylkääkö toteutus sitten paketin, jonka sisempi lähde kuuluu toiselle asiakkaalle, on kyseisen toteutuksen ominaisuus, ja se kannattaa tarkistaa olettamisen sijaan.
Perinteisen Community OpenVPN käyttäjäavaruuden palvelinkoodi voi esimerkiksi hylätä toiseen asiakkaaseen liittyvän lähteen ennen kuin paketti toimitetaan TUN-laitteen kautta. Se on todellisen arvon omaava osoitteen omistuksen tarkistus, eikä se silti ole NFS-käyttäjän todentamista, koska se ei kerro mitään siitä, mikä tili toiminnon suorittaa.
Lähteen käännös nakertaa jopa tuota. NAT-yhdyskäytävä voi esittää jokaisen asiakkaan yhtenä osoitteena, jolloin vientisääntö ei voi erottaa sen takana olevia ihmisiä. Säännön näennäinen tarkkuus muuttuu silloin kaaviokuvaan nojaavaksi fiktioksi. Jos vienti on tärkeä, pidä osoitteistus selkeänä sen sijaan, että annat kääntäjän päättää, kuka lasketaan keneksi.
Lue suojaustapa ennen kuin luot vientiin
Red Hatin NFS-ohje erottaa sec=sys, joka käyttää paikallisia UNIX-UID:itä ja -GID:itä AUTH_SYS:n kautta, Kerberos-tiloista. krb5 lisää käyttäjän todentamisen, krb5i lisää eheyden suojauksen ja krb5p lisää liikenteen yksityisyyden suojauksen.
AUTH_SYS-tunnistetiedot sisältävät kenttiä, kuten kutsujan UID ja ryhmätunnukset, ja RFC 5531 varoittaa selvästi, että tämä suojaustapa ei itsessään tarjoa turvaa ja riippuu ulkoisesta suojauksesta. Sen ajaminen VPN:n sisällä tarjoaa suojauksen siirrolle eikä muuta mitään paketin sisällä olevasta väitteestä.
exportfs -v
showmount -e nfs.example.internalLue suojaustapa tuosta tulosteesta ennen asiakasluettelon lukemista. Rajoitetulta näyttävä vienti voi olla rajoitettu vain osoitteella, kun jokainen kutsuja väittää edelleen mitä tahansa UID:tä.
Valitse malli ja pidä sitten käyttöoikeudet
Valitse tiedostopalvelun todentamismalli, joka sopii asiakkaille, joita todella hallinnoit. Kerberos vaatii identiteetin ja palvelun käyttöönoton taakseen, joten yhden liitosasetuksen muuttaminen ei ole migraatio ja yksinkertaisesti epäonnistuu, kunnes Kerberos-toimialue, principalit ja keytab-tiedostot ovat olemassa.
Kummassakin mallissa pidä vientioikeudet ja tiedostojärjestelmän valtuutus, jotka rajoittavat sitä, mitä todennettu principal saa tehdä. Todentaminen kertoo, kuka kysyy; valtuutus päättää, pitäisikö vastauksen olla kyllä. Näiden kahden sulauttaminen yhdeksi asetukseksi on tapa, jolla migraatio lopulta myöntää enemmän kuin vanha kokoonpano.
Käytä osoitesääntöä sen todelliseen tarkoitukseen
Palvelun rajaaminen hyväksyttyyn polkuun ja lähteisiin on edelleen hyödyllistä, mukaan lukien isännän syöttökäytäntö, kun VPN-päätepiste ja NFS-palvelin jakavat koneen. Liikennettä välittävät säännöt eivät ohjaa pyyntöjä, jotka on suunnattu samalla isännällä paikallisesti toimivaan palveluun. Tämä aukko selittää hämmästyttävän monta vientiä, joiden piti olla yksityisiä. Tarkista paikallinen syöttökäytäntö nimenomaisesti sen sijaan, että oletat tunnelisääntöjen kattavan sen.
Tarkista, ettei toinen liitäntä tai lähteen kääntävä yhdyskäytävä voi odottamatta täyttää sääntöä, ja pidä sitä syynä selvittää alkuperä, ei väitteenä, että osoitteen väärentäminen takaa toimivan liitoksen.
Suorita kolme hyväksymistapausta yhden sijaan. Aloita hyväksytyllä asiakkaalla, joka toimii hyväksyttynä käyttäjänä, toista sitten vertaiskumppanilta, jota ei koskaan hyväksytty, ja kokeile sitten jotain, mitä hyväksytty käyttäjä ei vieläkään saa tehdä. Kysy sen jälkeen, mikä muuttuu, jos valtuutettu asiakas vaarantuu, koska siirron todentaminen ei tee jokaista prosessia sillä koneella luotettavaksi. Varastettu varmenne ja utelias paikallinen tili ovat eri ongelmia eri kontrollein.