Export NFS blocat pe o adresă VPN: ce nu demonstrează
O regulă de export verifică de unde a venit pachetul; AUTH_SYS declară un UID local, iar Kerberos autentifică un utilizator. Decideți de care are nevoie serviciul dumneavoastră de fișiere.
Un gazdă exportă un director către o adresă VPN, montarea reușește, iar proiectul este notat ca autentificat. Ce limitează de fapt acea regulă este de unde par să vină pachetele. Dacă persoana care conduce operația de fișier este cine pretinde că este depinde de profilul de securitate NFS, iar la majoritatea exporturilor de acest fel nimeni nu l-a schimbat față de valoarea implicită.
Trei identități pot apărea într-o singură cerere
Partenerul VPN poartă o identitate înregistrată, cum ar fi un certificat de client sau o cheie de partener. Pachetul IP interior poartă o adresă sursă. Operația de fișier poartă acele credențiale de utilizator pe care le furnizează mecanismul său NFS. Un proiect care tratează adresa drept substitut pentru toate trei a presupus în tăcere exact partea care trebuia verificată.
| 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 |
Scrierea acelor trei rânduri este întregul exercițiu. Cea mai mare parte a dezbaterii despre dacă un export este sigur se prăbușește odată ce devine clar în ce rând trăiește fiecare control.
Proprietatea adresei este un detaliu de implementare
O poartă poate atribui o adresă de tunel unui partener acceptat sau poate autoriza o subrețea rutată pentru el. Dacă implementarea refuză apoi un pachet a cărui sursă interioară aparține altui client este o proprietate a acelei implementări, și merită verificat în loc de presupus.
Codul de server în spațiul utilizator al Community tradițional OpenVPN poate, de exemplu, să respingă o sursă asociată cu alt client înainte ca pachetul să fie livrat prin dispozitivul TUN. Aceasta este o verificare a proprietății adresei cu valoare reală, și încă nu este autentificare de utilizator NFS, pentru că nu spune nimic despre ce cont efectuează operația.
Traducerea sursei erodează chiar și asta. O poartă NAT poate prezenta fiecare client ca o singură adresă, iar atunci o regulă de export nu poate distinge oamenii din spatele ei. Precizia aparentă a regulii devine atunci o ficțiune întreținută de diagramă. Dacă exportul contează, păstrați adresarea explicită în loc să lăsați un traducător să decidă cine contează drept cine.
Citiți profilul de securitate înainte de a avea încredere în export
Ghidul NFS al Red Hat separă sec=sys, care folosește UID și GID UNIX locale prin AUTH_SYS, de modurile Kerberos. krb5 adaugă autentificarea utilizatorului, krb5i adaugă protecția integrității, iar krb5p adaugă protecția confidențialității pentru trafic.
Credențialele AUTH_SYS conțin câmpuri precum UID-ul apelantului și identificatorii de grup, iar RFC 5531 avertizează clar că acest profil nu oferă securitate prin sine și depinde de protecție externă. Rularea lui în interiorul unui VPN oferă protecție pentru transport și nu schimbă nimic în afirmația din interiorul pachetului.
exportfs -v
showmount -e nfs.example.internalCitiți profilul din acea ieșire înainte de a citi lista de clienți. Un export care pare restricționat poate fi restricționat doar prin adresă, în timp ce fiecare apelant declară în continuare orice UID dorește.
Alegeți modelul, apoi păstrați permisiunile
Alegeți modelul de autentificare al serviciului de fișiere potrivit pentru clienții pe care îi administrați efectiv. Kerberos necesită o identitate și o implementare de serviciu în spate, așa că schimbarea unei opțiuni de montare nu este o migrare și pur și simplu va eșua până când există domeniul Kerberos, principalii și keytab-urile.
În ambele modele, păstrați permisiunile de export și autorizarea sistemului de fișiere care limitează ce poate face principalul autentificat. Autentificarea vă spune cine întreabă; autorizarea decide dacă răspunsul ar trebui să fie da. Comasarea celor două într-o singură setare este modul în care o migrare ajunge să acorde mai mult decât configurația veche.
Folosiți regula adresei pentru scopul ei real
Restrângerea serviciului la calea și sursele aprobate rămâne utilă, inclusiv politica de intrare a gazdei atunci când punctul final VPN și serverul NFS partajează mașina. Regulile care redirecționează traficul nu guvernează cererile adresate către un serviciu care rulează local pe aceeași gazdă. Această lacună explică un număr surprinzător de exporturi care trebuiau să fie private. Verificați explicit politica de intrare locală în loc să presupuneți că regulile tunelului o acoperă.
Verificați că o altă interfață sau o poartă cu traducere a sursei nu poate satisface regula în mod neașteptat, și tratați asta ca motiv pentru a stabili proveniența, nu ca afirmația că falsificarea unei adrese garantează o montare funcțională.
Rulați trei cazuri de acceptare în loc de unul. Începeți cu un client aprobat care acționează ca utilizator aprobat, apoi repetați de la un partener care nu a fost niciodată aprobat, apoi încercați ceva ce utilizatorul aprobat încă nu are voie să facă. Întrebați apoi ce se schimbă dacă un client autorizat este compromis, pentru că autentificarea transportului nu face fiecare proces de pe acea mașină de încredere. Un certificat furat și un cont local curios sunt probleme diferite cu controale diferite.