Software-ul OpenLDAP este proiectat să funcționeze într-o gamă largă de medii de calcul, de la rețele închise total controlate până la Internet global. Prin urmare, software-ul OpenLDAP suportă multe mecanisme de securitate diferite. Această secțiune descrie aceste mecanisme și discută despre securitatea utilizării OpenLDAP.
Pentru mai multe informații, consultați opțiunile din linia de comandă și slapd (8).
De obicei, slapd (8) ascultă pentru 389 / tcp pentru ldap: // sessions și port 636 / tcp pentru ldaps: // sessions. Acesta poate fi, de asemenea, configurat pentru a asculta alte porturi.
Deoarece setările IP-favel sunt dependente de tipul specific de firewall bazat pe IP, nu sunt date aici exemple. Consultați documentația pentru paravanul de protecție IP.
slapd (8) suportă TCP Wrappers. TCP Wrappers este un sistem de control al accesului bazat pe reguli pentru controlul accesului la server prin TCP / IP. De exemplu, regula host_options (5):
permite numai conexiunile de intrare de la rețeaua privată 10.0.0.0 și de la localhost (127.0.0.1) pentru a accesa serviciul de directoare.
Rețineți că pachetele TCP trebuie să specifice conexiunile care vor fi acceptate. Deoarece în majoritatea cazurilor, dimpotrivă, este necesară interzicerea conexiunilor, este preferabil să se utilizeze protecția IP firewall, mai degrabă decât pachetele TCP.
Pentru mai multe informații despre regulile de împachetare TCP din hosts_access (5).
Pentru a asigura integritatea datelor și a proteja confidențialitatea, puteți utiliza secțiunea Transport Layer Security (TLS). OpenLDAP acceptă negocierea TLS (SSL) atât prin StartTLS, cât și prin ldaps: //. Pentru mai multe informații, consultați Utilizarea TLS. Mecanismul standard StartTLS pentru stabilirea unei conexiuni.
De asemenea, în cadrul integrității datelor și protecției vieții private, sunt suportate mai multe mecanisme de autentificare simplă și securitate (SASL), cum ar fi DIGEST-MD5 și GSSAPI. Pentru mai multe informații, consultați Utilizarea SASL.
Serverul folosește factorii de factor de forță de securitate (SSF) pentru a indica rezistența relativă a protecției. SSF este 0, indică faptul că protecția nu este necesară. SSF este 1, indică faptul că este necesară protecția integrității. SSF mai mare decât unitatea (> 1), corelează aproximativ cu lungimea efectivă a cheii de criptare. De exemplu, DES este 56, 3DES este 112, iar AES este 128, 192 sau 256.
În cadrul sesiunii LDAP, volumul controlului administrativ impus de SSF este asociat cu gradul de protecție prin intermediul TLS și SASL.
Controalele de securitate nu permit executarea operațiunii dacă gradul de protecție specificat nu este respectat. De exemplu:
necesită protecția integrității pentru toate operațiile și pentru operațiile de actualizare (cum ar fi adăugarea, ștergerea, modificarea) necesită o criptare echivalentă cu 3DES. O descriere detaliată poate fi găsită în slapd.conf (5).
SSF poate fi folosit pentru a controla accesul pentru a stabili un control mai precis. Pentru mai multe informații, consultați Controlul accesului.
Metoda simplu de autentificare LDAP are trei moduri de funcționare:
- acordarea accesului unui utilizator anonim,
- - furnizarea de acces la utilizator fără autentificare și -
- oferind acces la un utilizator cu autentificare prin nume de utilizator și parolă.
O cerere de acces anonim are loc când nici un nume de utilizator sau o parolă nu este transmis prin metoda "simplu". O solicitare de acordare a accesului unui utilizator fără autentificare are loc când se transmite doar numele de utilizator și numai parola nu este transmisă. În cele din urmă, o cerere de acces la un utilizator autentificat are loc atunci când numele de utilizator și parola corect sunt transmise la conectare.
Notă: Dezactivarea mecanismului de conectare anonim nu împiedică accesul anonim la director. Pentru a accesa întotdeauna baza de date, a fost necesară autentificarea, în locul directivei de mai sus, trebuie să specificați "necesită authc".
Mecanismul de conectare cu autentificare după numele de utilizator și parola poate fi dezactivat complet utilizând directiva "disallow bind_simple".
Metoda de autentificare LDAP SASL permite utilizarea oricăror mecanisme de autentificare SASL. Utilizarea acestei metode este discutată în secțiunea Utilizarea SASL.
Parolele LDAP sunt de obicei stocate în atributul userPassword. RFC4519 specifică faptul că parolele nu ar trebui să fie stocate într-un formular criptat (sau hashed). Aceasta permite utilizarea unei game largi de mecanisme de autentificare bazate pe parole, precum DIGEST-MD5. Această schemă de stocare este, de asemenea, cea mai compatibilă cu implementarea sistemului de autentificare în diferite programe client.
Cu toate acestea, în practică, este mai des de dorit să stocați în continuare o parolă de tip hash. slapd (8) acceptă mai multe scheme de stocare diferite pentru a alege un administrator de sistem.
Notă: Valorile atributelor parolei, indiferent de schema de stocare utilizată, ar trebui protejate, precum și dacă acestea ar fi stocate într-o formă deschisă. Parolele dezamăgite sunt supuse atacului de către dicționar și atac prin metoda căutării complete.
Atributul UserPassword poate avea mai mult de o valoare și toate pot fi stocate într-o altă formă. În procesul de autentificare, slapd va trece consecvent prin valori până când va găsi unul care se potrivește cu parola propusă sau până când valorile se vor încheia. Schema de stocare este indicată ca prefix pentru valoare, adică parola, încorporată în funcție de schema Salata SHA1 (SSHA) arată astfel:
Avantajul parolelor hashed este că un atacator care accesează hash-ul nu are acces direct la parola reală. Din păcate, ele sunt pur și simplu selectate cu dicționarul sau cu atacuri brute, astfel încât acest avantaj este mai degrabă fantomatic (de aceea toate sistemele moderne Unix utilizează un fișier de parolă umbroasă).
Dezavantajul stocării cu parolă hashed este că acestea nu sunt standard și pot provoca probleme de compatibilitate. Acest lucru poate duce la faptul că utilizarea oricăror mecanisme de autentificare a parolelor, mai puternică decât Simple (sau SASL / PLAIN), este eliminată cu totul.
Aceasta este o versiune a schemei SHA cu "sare". Este considerată cea mai sigură schemă de stocare a parolelor, susținută de slapd.
Aceste valori reprezintă aceeași parolă:
Această schemă utilizează funcția de hash cript (3) a sistemului de operare. De obicei, au fost generate în acest sistem scheme hashes tradiționale de 13 caractere Unix, dar se pot genera mai multe secvențe de MD5 de 34 de octeți pe sistemele glibc2.
Avantajul schemei CRYPT este că parolele pot fi transferate dintr-un fișier de parolă Unix existent, fără a fi necesară parolele clare. Ambele forme de cript utilizează "sare", astfel încât au o anumită rezistență la atacurile dicționarului.
Notă: Deoarece această schemă utilizează funcția de hash cript (3) a sistemului de operare, este specifică fiecărui sistem de operare.
Această schemă ia pur și simplu hash-ul MD5 de la parolă și o stochează în formularul codat de base64:
Acesta nu este un circuit foarte sigur, deși este mai sigur de depozitat într-o stare deschisă. MD5 este un algoritm rapid și, deoarece nu folosește "sare", această schemă de stocare este vulnerabilă la atacurile dicționarului.
Această schemă amplifică schema principală MD5 adăugând "sare" (adică date aleatorii), ceea ce înseamnă că multe forme de reprezentare hash pot corespunde aceleiași parole într-o formă deschisă. De exemplu, ambele valori reprezintă aceeași parolă:
Ca și schema MD5, această schemă transmite parola doar prin procesul de hash SHA. SHA este considerată mai sigură decât MD5, dar lipsa de "sare" o face vulnerabilă la atacurile dicționarului.
De fapt, aceasta nu este o schemă de stocare a parolei. Utilizează valoarea atributului UserPassword. să delegați verificarea parolei la un alt proces. Vedeți mai jos pentru detalii.
Notă: Nu este același lucru cu utilizarea SASL pentru a autentifica o sesiune LDAP.
Începând cu OpenLDAP 2.0, slapd are opțiunea de a delega verificarea parolei într-un proces separat. Este folosită funcția sasl_checkpass (3). În acest fel, în timpul scanării, se poate folosi orice mecanism care suportă Cyrus SASL pentru a verifica parola. Alegerea mecanismelor este foarte largă, una dintre posibilitățile este folosirea saslauthd (8). care este configurat să utilizeze fișierele locale, Kerberos, serverul IMAP, un alt server LDAP sau orice altceva acceptat de motorul PAM.
Pentru a permite autentificarea de la un capăt la altul, serverul trebuie să fie compilat cu opțiunea de configurare --enable-spasswd.
Notă: Nu este același lucru cu utilizarea SASL pentru a autentifica o sesiune LDAP.
End-to-end autentificare funcționează numai cu parole deschise, cum ar fi cele utilizate în mecanismele de autentificare "simple bind" și "SASL PLAIN".
End-to-end autentificarea este selectivă: se aplică numai acelor utilizatori care au valoarea atributului userPassword prefixată cu schema "". Formatul acestui atribut este:
Utilizatorii care au activat autentificarea pass-pass, este recomandabil, prin controlul accesului, să împiedice schimbarea parolelor lor prin LDAP.
Pentru intrările care au o valoare de atribut de parolă cu o schemă, OpenLDAP delegă complet procesul de verificare a parolei de scriere Cyrus SASL. Astfel, toate setările sunt făcute în fișierele de configurare SASL.
Primul fișier examinat are numele slapd.conf și se găsește de obicei în directorul de biblioteci SASL, aflat adesea în /usr/lib/sasl2/slapd.conf. Acest fișier controlează funcționarea SASL atunci când sunt partajate cu slapd. și este, de asemenea, utilizat atunci când se utilizează mecanisme SASL pentru autentificarea de la capăt la capăt. Informații detaliate pot fi găsite pe pagina options.html din documentația Cyrus SASL. Iată un exemplu simplu pentru un server care va folosi saslauthd pentru a verifica parolele:
saslauthd este capabil să utilizeze multe servicii de autentificare diferite. Pentru detalii, consultați saslauthd (8). O practică obișnuită este delegarea autentificării, parțial sau total, către un alt server LDAP. Iată un exemplu al fișierului saslauthd.conf pentru autentificarea Microsoft Active Directory (AD):
În acest caz, saslauthd este pornit cu mecanismul de autentificare ldap și cu instrucțiuni pentru a combina domeniul SASL cu numele de utilizator:
Aceasta înseamnă că șirul "username @ realm", care termină valoarea utilizatoruluiPassword atribut. va fi folosit pentru a căuta AD pentru a se potrivi cu filtrul "userPrincipalName = username @ realm". După aceasta, parola este verificată prin încercarea de a vă conecta la AD utilizând intrarea găsită în timpul căutării și parola furnizată de clientul LDAP.
În mod normal, testarea se face cel mai bine din partea de sus în jos, începând de la furnizorul de autentificare final, și merge în jos prin saslauthd și slapd la clienții LDAP.
În exemplul de mai sus cu AD, verificați mai întâi capacitatea de a vă conecta la AD cu acele DN și parolele pe care saslauthd le va folosi la conectare:
Apoi, se verifică dacă poate fi găsit un utilizator de testare AD:
Apoi, se verifică dacă acest utilizator se poate conecta la AD:
Dacă toate acestea funcționează, atunci saslauthd poate face același lucru:
Acum puneți secvența magică în intrarea dorită în OpenLDAP:
Acum puteți crea o conexiune cu OpenLDAP utilizând DN-ul acestei intrări și parola de utilizator AD.
Articole similare
Trimiteți-le prietenilor: