Restrângeți o partajare Samba la un utilizator și o adresă VPN

În acest proiect se confundă două permisiuni diferite: cine poate folosi un director și ce adrese se pot conecta deloc. Să scrii o listă de conturi lângă o listă de surse pare o asociere, dar Samba evaluează cele două liste ca predicate independente. Este admis oricine îndeplinește ambele, iar aceasta este o regulă mai largă decât intenționează majoritatea administratorilor. Remedierea este fie o altă configurație a partajării, fie un strat de politică ce poate exprima perechea.

Mitul: două liste fac o singură regulă

Referința smb.conf definește valid users și hosts allow ca doi parametri fără legătură, iar tocmai setarea ambilor pe o singură partajare este locul unde începe confuzia. Setează valid users = mira, tomas și hosts allow = 10.77.0.21, 10.77.0.22 și sunt admise patru combinații: Mira de la oricare dintre adrese, Tomas de la oricare dintre adrese. Nimic din configurație nu leagă primul nume de prima adresă, iar ordinea în care apar numele nu are nicio semnificație. Rearanjarea lor, adăugarea unei a doua linii hosts allow sau punerea unui singur nume pe linie nu schimbă nimic. Rezultatul este produsul a două liste, nu o corespondență între ele.

Ce vrea de fapt majoritatea este mai îngust: Mira doar de la o adresă, Tomas doar de la alta. O singură definiție de partajare nu are sintaxă pentru această legare, iar nicio ordonare isteață nu o creează. Este o formă de politică pe care Samba nu o exprimă într-o singură partajare, și acolo mitul supraviețuiește.

Ce evaluează Samba și în ce ordine

Etapele se desfășoară într-o ordine fixă, iar ordinea greșită produce diagnosticul greșit. Un client deschide o conexiune; o verificare globală a gazdei rulează dacă este configurată; configurarea sesiunii autentifică contul; apoi clientul se conectează la o partajare, unde se aplică lista proprie de gazde a acelei partajări, valid users și setarea doar-citire; și abia când se deschide un fișier decid permisiunile sistemului de fișiere ale identității autentificate. Fiecare etapă poate respinge cererea singură, iar trecerea uneia nu spune nimic despre următoarea. Consecința importantă este că contul este cunoscut atunci când lista de gazde a partajării este evaluată, iar lista de gazde încă nu are cum să numească acel cont.

De aceea o partajare nu poate lega un utilizator de o adresă: hosts allow și valid users sunt predicate separate aplicate în aceeași etapă de conectare a arborelui, iar fiecare răspunde la propria întrebare. Predicatul de gazdă nu ia niciodată numele contului ca intrare, deci nu poate fi scris per utilizator. Doar o a doua partajare sau un strat de politică din afara Samba poate exprima perechea.

Valorile globale contează din cauza modului în care sunt moștenite. O partajare care omite hosts allow moștenește valoarea globală, iar o partajare care o setează pe a sa folosește acea valoare în locul celei globale, nu în plus. Așadar o listă globală largă lărgește partajările care nu setează niciodată parametrul și nu face nimic unei partajări care o definește pe a sa. Executați testparm -s și citiți valorile pe partajare pe care le afișează, pentru că acea ieșire este politica efectivă, iar fișierul de pe disc nu este.

Restrângerea unei partajări nu face nimic nici pentru restul serverului. Celelalte partajări, cozile de imprimare și conexiunea IPC își păstrează propriile reguli, așa că un proiect care se bazează pe lista de adrese a unei singure partajări protejează o cale, nu gazda.

Două nume de partajare pe un director

Când același director trebuie să fie accesibil pentru două persoane din două adrese, expuneți-l de două ori sub nume diferite. Fiecare bloc poartă un cont și o sursă, ceea ce transformă perechea în ceva ce configurația poate impune. Costul este că fiecare persoană folosește un nume de partajare diferit pentru a ajunge la aceleași fișiere, iar aceasta trebuie să fie o schimbare deliberată pe partea clientului.

[shared-mira]
    path = /srv/shared
    guest ok = no
    read only = yes
    valid users = mira
    hosts allow = 10.77.0.21
    hosts deny = ALL

[shared-tomas]
    path = /srv/shared
    guest ok = no
    read only = yes
    valid users = tomas
    hosts allow = 10.77.0.22
    hosts deny = ALL

O poartă de partajare nu este o permisiune a sistemului de fișiere. Ambele identități au în continuare nevoie de acces la director prin ACL-ul de bază, iar setarea doar-citire este un al doilea strat, nu singurul. Acordați acces de scriere doar dacă fluxul de lucru o cere, apoi verificați că fișierele create de o identitate rămân utilizabile pentru cealaltă.

Ambele blocuri indică o singură cale, așa că o schimbare în director afectează ambele partajări. De obicei acesta este scopul, dar înseamnă și că o eroare de permisiuni este vizibilă pentru ambii utilizatori simultan.

Ce poate dovedi adresa sursă

Adresa pe care o vede Samba este adresa care a ajuns la server, nu adresa pe care clientul crede că o are. O poartă VPN care traduce fiecare client într-o singură adresă sursă elimină distincția: toți clienții ajung ca aceeași gazdă, iar lista de surse nu îi mai poate distinge. Alocarea stabilă per client și o poartă care păstrează sursa sunt condiții prealabile pentru a folosi adresele ca politică. Fără ambele, restricția măsoară poarta, nu utilizatorul.

Chiar și atunci, o adresă nu este un dispozitiv. Două laptopuri în spatele unei adrese de tunel, un lease realocat și o stație de lucru partajată contrazic toate presupunerea că o sursă identifică o persoană. Tratați restricția ca aria rețelei și păstrați conturile SMB autentificate ca strat de identitate, cu o acreditare de dispozitiv precum un certificat dacă aveți nevoie de autorizarea dispozitivului.

De aceea proiectul închide partajări și nu serverul. O pereche respinsă poate totuși deschide o sesiune, ajunge la o altă partajare sau lista serverul, ceea ce este un rezultat diferit de un eșec de autentificare la conectare. Dacă cerința este respingerea înainte de autentificare, parametrii de partajare ai Samba sunt instrumentul greșit.

Dovediți-o cu perechi încrucișate

Validați configurația, apoi testați cele patru combinații cu conexiuni noi, nu cu o sesiune reutilizată. Perechea dorită ar trebui să ajungă la director, iar ambele perechi încrucișate ar trebui să eșueze. O sesiune din cache de la un test anterior va răspunde bucuros pentru combinația greșită și va face o regulă ruptă să pară corectă.

testparm -s
smbclient //fileserver/shared-mira -U mira -c 'ls'
smbclient //fileserver/shared-tomas -U tomas -c 'ls'
smbstatus --shares

O verificare de sintaxă dovedește doar că fișierul este analizat. Datele de autentificare, ACL-urile și decizia de gazdă sunt exercitate de o conexiune reală, așa că rulați comanda clientului de la adresa pe care vreți să o testați și urmăriți care etapă o respinge. Dacă o pereche încrucișată reușește, lista efectivă de gazde este mai largă decât sugerează blocul, iar testparm -s este primul lucru de citit. Dacă o pereche încrucișată eșuează din motivul greșit, contul sau ACL-ul sunt suspecte.

Monitorizarea sesiunilor cu smbstatus și terminarea lor este o acțiune de răspuns după începerea accesului, nu un control de admitere. Blocarea unei adrese întregi observate poate deconecta și utilizatori nelegați din spatele aceluiași NAT, de aceea decizia aparține definiției partajării, iar monitorizarea procesului de răspuns. Țineți cele două separate și proiectul rămâne onest cu privire la ce impune.