LDAP Bezpečnosť informačných systémov

1. LDAPBezpečnosť informačných systémov Pavol Gurbaľ 4. ročník Šk. rok: 2003/2004

2. Úvod • História • Adresárové služby • LDAP • Bezpečnosť LDAP

3. V posledných pár rokoch nastal spolu s rozmachom distribuova-ných systémov masívny nárast sieťového programovania • Výsledkom tohto nárastu je prudký nárast klientov aj serverov pripojených do siete • So zvyšovaním počtu ľudí a prostriedkov prístupných zo siete sa objavilo niekoľko nových problémov: • Pre konečných používateľov je často obtiažne lokalizovať služby a prostriedky a takisto získať informácie o nových službách a zdrojoch nainštalovaných na sieti • Aplikácie majú problémy so zdieľaním informácií o službách, prostriedkoch a používateľoch, pretože tieto zdroje sú často uložené v aplikačne špecifických adresároch, lokáciách • Toto prostredie je ťažké udržiavať, pretože používatelia pristupujú k prostriedkom z viacerých platforiem. Takisto bezpečnosť musí byť spravovaná na viacerých miestach používaním rozdielnych nástrojov a aplikácií

4. Z týchto dôvodov sa stávajú adresárové služby dôležitým aspektom programového prostredia • Adresárové služby sústreďujú informácie popisujúce používateľov, aplikácie, súborové prostriedky a prostriedky pre tlač, riadenie prístupu, a ďalšie zdroje do spoločného adresára, ktorý je prístupný pre všetkých používateľov a aplikácie na sieti • Analógia zlatých stránok – umožňuje pridávať, odoberať informácie, vyhľadávať na základe vzorov, takisto definovať prístupové módy k informáciám • Adresárové služby zlepšujú funkčnosť, pretože adresár nie je závislý na žiadnej konkrétnej aplikácii. Môžu ho využívať všetky directory-enabled aplikácie. Toto eliminuje izolovanie informácií spôsobené aplikáciami, ktoré implementujú svoje vlastné miesta pre uloženie spravovaných informácií

5. Adresárové služby takisto veľmi uľahčujú administráciu, pretože informácie sú spravované centrálne. Akékoľvek pridanie alebo zmeny informácií vykonané v adresari sú okamžite prístupné všetkým používateľom a aplikáciám. • Napr. miesto toho, aby sme menili access control list pre daný zdroj v každom systéme, ktorý k nemu pristupuje, táto informácia sa zmení iba raz a každá aplikácia použije túto informáciu na riadenie prístupu k tomuto zdroju

6. História • V roku 1987 bolo uznané odporúčanie pre adresárové služby X.500 vypracované Medzinárodnou Telekomunikačnou Úniou (ITU). • Toto odporúčanie obsahovalo špecifikáciu pre Directory Access Protocol (DAP), ktorý definoval protokol na komunikáciu medzi adresárom a používateľom. DAP bol založený na OSI sieťovom modeli. • DAP sa ukázal ako príliš zložitý, aj kvôli použitiu OSI modelu. • University of Michigan spolu s Internet Engineering Task Force (IETF) vyvinuli Leightweight DAP

7. Tento je založený na TCP/IP modeli a je preto aplikovateľný v LAN i WAN sieťach, rovnako i cez Internet • Originál LDAP je definovaný v RFC 1777 z roku 1995 • RFC 2251 z roku 1997 definuje LDAPv3 • LDAP získal podporu rôznych platforiem, rovnako ako viacerých jazykov. • C/C++ má podporu LDAP, rovnako aj PERL, podpora v Jave je zabezpečená cez sunovské Java Naming and Directory Interface (JNDI). • Windows má podporu LDAP cez Active Directory Services Interface a ďalšie third-party ActiveX komponenty

8. Adresárová štruktúra • Adresár je špecializovaná databáza navrhnutá na rýchly a bezpečný prístup k informáciám • Je optimalizovaná pre rýchle čítanie • Informácie sú organizované ako súbor jednotlivých záznamov, ktoré obsahujú informácie o danom zdroji • Na zabezpečenie maximálne efektívneho prístupu k týmto záznamom, sú tieto usporiadané v hierarchii označovanej ako Directory Information Tree (DIT)

9. Na obrázku je príklad na DIT: c = US o = Alpine Airways ou = Maintenance ou = Reservations ou = Finance ou = Planes ou = Terminals ou = Central Repair • Koreň stromu je krajina (C), nasleduje organizácia (O). Pod koreňom nasledujú zvyčajne organization units (OU) Tieto objekty sú označované ako container objects • Adresárové záznamy, ktoré obsahujú samotné informácie sa nazývajú listy • Cesta do každého záznamu v strome je označovaná ako distinguished name (DN). Každé DN musí byť v strome unikátne

10. Položky adresára • Položky adresára obsahujú dvojice meno/hodnota, nazývané atribúty. • Každá položka musí mať objectclass atribút – určuje, ktoré atribúty sú dovolené pre danú položku a ktoré atribúty mať môže cn=John Smith,o=Alpine Airlines,c=US cn=John Smith cn=John_Smith sn=Smith objectclass=top objectclass=person objectclass=salesPerson l=Chicago title=Senior Sales Manager ou=Finance ou=Marketing mail=Smith.John@alpineairlines.com telephonenumber=312-258-8655 roomnumber=117 uid=jsmith

11. Bezpečnosť LDAP • Keďže adresár je určený na zdieľanie informácií pre viacero aplikácií, musí byť zabezpečený pred neautorizovaným prístupom k citlivým dátam • Bezpečnosť je v LDAP zabezpečovaná pomocou autentifikácie a riadenia prístupu – autorizácie

12. Autorizácia • Autorizácia sa deje na základe Access Control List-u (ACL) • V ACL sú nastavené prístupové práva používateľov k adresáru alebo jeho častiam a jednotlivým záznamom na základe používateľovej DN alebo príslušnosti ku skupine • ACL kontrolujú prístup až po úroveň atribútov • Je možné povoliť prístup užívateľovi do jeho vlastného DN a meniť jeho atribúty – aj také, ku ktorým ostatní používatelia nemajú prístup (usserpassword) • Zvyčajne je umožnený defaultný prístup do adresára, a ACL sú používané na anulovanie tohto prístupu. • Napr. servery Netscape nemajú defaultný prístup, teda ak nie je definovaný žiaden ACL, do adresára má prístup len správca

13. Autentifikácia • Používateľ nadviaže spojenie s adresárovým serverom pomocou operácie bind • Časť informácie potrebnej na vykonanie tejto operácie je používateľova identita a heslo • Pri LDAPv2 je bind povinný, pri LDAP v3 je voliteľný – ak sa nevykoná bind, zaobchádza sa s klientom ako s anonymous • Sú tri základné mechanizmy pre spojenie: • anonymous • simple • secure

14. Anonymous bind – najjednoduchší. Používateľovi je dovolený prístup do adresára bez zadania identity. Ak je povolený anonymný prístup k niektorým záznamom, ostatné musia byť chránené pred prístupom neznámeho používateľa. • Simple bind – používateľ zadá DN pre záznam v adresári a takisto heslo pre tento záznam. Daný záznam musí obsahovať atribút usserpassword, ktorý sa porovnáva pri zadaní hesla. Ak je spojenie úspešné, užívateľ dostane identitu na danom DN platnú po dobu trvania spojenia a prístup k záznamom na základe tejto identity. Heslo sa pri tomto spojení posiela cez sieť ako plain text. Pokiaľ nie je autentifikácia a šifrovanie zabezpečované na nižších vrstvách, použitie tohto typu spojenia sa neodporúča. • Simple bind sa používa aj pri anonymnom spojení – je to simple bind so zero-length heslom a DN

15. Secure bind – niektoré adresárové servery implementujú autentifikačné metódy (Kerberos), alebo autentifikáciu na základe certifikátov (SSL). • LDAPS (HTTP => HTTPS) • neoficiálny protokol, na autentifikáciu používa SSL

16. IETF vychytaním chýb z SSL vytvorila Transport Layer Security (TLS) => RFC 2246 • TLS podporuje kryptovanie a autentifikáciu na základe certifikátov • V najjednoduchšej forme, TLS umožňuje overenie identity servera a ochranu dát počas prenosu => umožňuje prenos aj plaintext hesiel cez sieť • Ten istý mechanizmus môže byť použitý na overenie identity klienta voči serveru

17. Simple Authentification and Security Layer (SASL) a jeho autentifikačné mechanizmy (DIGEST-MD5, CRAM-MD5, a pod.) • Pomocou SASL je možné nadviazať spojenie na bezpečnostnej vrstve (security layer) • Po nadviazaní spojenia na bezpečnostnej vrstve, je použité na všetky prenášané dáta cez toto spojenie

18. Príklady • Príklady na spojenie s LDAP serverom pomocou JNDI: • Nastavujú sa tri premenné, ktoré určujú, o aký typ spojenia pôjde: Context.SECURITY_AUTHENTICATION ("java.naming.security.authentication") Určuje autentifikačný mechanizmus. Pre Sun LDAP je to “none“, “simple“ a sasl_mech, kde sasl_mech je medzerami oddelený zoznam SASL mechanizmov Context.SECURITY_PRINCIPAL("java.naming.security.principal") Špecifikuje meno užívateľa/programu, ktorý sa snaží o autentifikáciu. Jeho hodnota závisí na Context.SECURITY_AUTHENTICATION Context.SECURITY_CREDENTIALS("java.naming.security.credentials") Špecifikuje poverenia (credentials) daného užívateľa/programu závisiace od hodnoty parametra Context.SECURITY_AUTHENTICATION

19. Anonymous bind //Set up the environment for creating the initial context Hashtable env = new Hashtable(); env.put(Context.INITIAL_CONTEXT_FACTORY,"com.sun.jndi.ldap.LdapCtxFactory"); env.put(Context.PROVIDER_URL, "ldap://localhost:389/o=JNDITutorial"); // Use anonymous authentication env.put(Context.SECURITY_AUTHENTICATION, "none"); // Create the initial context DirContext ctx = new InitialDirContext(env); // ... do something useful with ctx

20. Simple bind // Set up the environment for creating the initial context Hashtable env = new Hashtable(); env.put(Context.INITIAL_CONTEXT_FACTORY, "com.sun.jndi.ldap.LdapCtxFactory"); env.put(Context.PROVIDER_URL, "ldap://localhost:389/o=JNDITutorial"); // Authenticate as S. User and password"mysecret„ env.put(Context.SECURITY_AUTHENTICATION, "simple"); env.put(Context.SECURITY_PRINCIPAL, "cn=S. User, ou=NewHires, o=JNDITutorial"); env.put(Context.SECURITY_CREDENTIALS, "mysecret"); // Create the initial context DirContext ctx = new InitialDirContext(env); // ... do something useful with ctx

21. Secure bind • LDAP v3 používa SASL na podporu pluggable autentifikácie • Klient a server môžu vyjednávať o spôsobe autentifikácie • Ako zistiť, ktoré mechanizmy sú podporované? // Create initial context DirContext ctx = new InitialDirContext(); // Read supportedSASLMechanisms from root DSE Attributes attrs = ctx.getAttributes( "ldap://localhost:389", new String[]{"supportedSASLMechanisms"}); System.out.println(attrs); // Close the context when we're done ctx.close();

22. Secure bind II Hashtable env = new Hashtable(); env.put(Context.INITIAL_CONTEXT_FACTORY, "com.sun.jndi.ldap.LdapCtxFactory"); env.put(Context.PROVIDER_URL, "ldap://localhost:389/o=JNDITutorial"); // Authenticate as C. User and password "mysecret" env.put(Context.SECURITY_AUTHENTICATION, "DIGEST-MD5"); env.put(Context.SECURITY_PRINCIPAL, "dn:cn=C. User, ou=NewHires, o=JNDITutorial"); env.put(Context.SECURITY_CREDENTIALS, "mysecret"); // Create the initial context DirContext ctx = new InitialDirContext(env); // ... do something useful with ctx

23. Bezpečnostné hrozby pre LDAP • Neautorizovaný prístup k dátam cez operácie na spracovanie dát • Neautorizovaný prístup k znovu použiteľnej autentifikačnej informácii klienta monitorovaním prístupu • Neautorizovaný prístup k dátam monitorovaním prístupu • Neautorizované modifikovanie dát • Neautorizované modifikovanie konfigurácie • Neautorizované alebo nadmerné používanie zdrojov (DoS attack) • Spoofing adresára: oklamanie klienta, aby veril, že informácie prichádzajú z adresára – modifikovanie dát počas prenosu, prípadne presmerovanie spojenia klienta 1,4,5,6 – “záškodnícky“ klient 2,3,7 – záškodník na ceste medzi klientom a serverom, alebo vystupujúci ako server

24. Ochrana LDAP LDAP protokol sa chráni nasledujúcimi technikami: • Autentifikácia klienta pomocou SASL mechanizmov, podporená TLS výmenou certifikátov • Autorizácia klienta pomocou riadenia prístupu na základe jeho autentifikovanej identity • Ochrana integrity dát pomocou TLS protokolu alebo SASL data-integrity mechanizmov • Ochrana pred monitorovaním pomocou TLS protokolu alebo SASL data-encrypting mechanizmov • Obmedzenie prostriedkov pomocou obmedzení administrátora • Autentifikácia servera pomocou TLS protokolu alebo SASL mechanizmov

25. Literatúra [1] Directory Sevices Overview http://support.sas.com/rnd/itech/ldap/index.html [2] LDAP security http://www.skills­1st.co.uk/papers/afindlay.html [3] JNDI tutorial http://java.sun.com/products/jndi/tutorial/ldap/index.html [4] Security issues with LDAP connections http://search.cpan.org/~gbarr/perl-ldap [5] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access Protocol (v3)", RFC 2251, December 1997. http://www.ietf.org/rfc/rfc2251.txt [6] Yeong, W., Howes, T., and S. Kille, "Lightweight Directory Access Protocol", RFC 1777, March 1995. http://www.ietf.org/rfc/rfc1777.txt [7] Myers, J., "Simple Authentication and Security Layer (SASL)", RFC2222, October 1997. http://www.ietf.org/rfc/rfc1777.txt [8] Wahl, M., Alvestrand, H., Hodges, J. and R. Morgan, “Authentifications Methods for LDAP", RFC 2829, May 2000. http://www.ietf.org/rfc/rfc2829.txt