Šifrovaný LDAP
Keď ste si nastavili centrálnu autentizáciu prostredníctvom servera OpenLDAP, určite nie je dobrý nápad komunikovať otvorene, ale lepším nápadom je zvýšiť úroveň bezpečnosti pomocou TLS/SSL. Nie je to problém, ale isté úskalia to skrýva.
Najprv som chcel tento popis zahrnúť do článku s popisom inštalácie OpenLDAP, ale potom som si povedal, že najmä začínajúci správcovia ocenia aj krátky popis ako sa dostať k certifikátom.
Certifikát slúži na overenie, či potvrdenie. Že čoho? V podstate čohokoľvek a iste ste sa s ním stretli aj mimo IT, ale v IT sa používa na overenie (alebo potvrdenie), že niekto (alebo niečo) je to, za čo sa vydáva. V tomto prípade bude využitý na overenie servera, že je to naozaj server, ktorý klient žiada, a že sa tam cestou po sieti nevotrel nejaký iný, falošný server.
Certifikát možno získať v podstate dvoma spôsobmi. Prvým je získanie (vytvorenie si) certifikátu podpísaného nejakou certifikačnou autoritou (CA). Za toto podpísanie sa platí, i preto je tento spôsob vhodný najmä v komerčnej sfére. Druhým spôsobom je vytvorenie si certifikátu, ktorý si podpíšete sami, teda nebude podpísaný známou CA. Vo svojej podstate sú tieto certifikáty rovnocenné, ale ten, ktorý si podpíšete sami, bude v klientoch považovaný za nedôveryhodný a bude vyžadovať potvrdenie dôveryhodnosti (spôsoby sú rôzne), pretože vás (ako CA) nikto nepozná.
Vytvorenie certifikátu
Na počiatočné overenie funkčnosti plne postačí certifikát, ktorý si podpíšete sami. Takýto certifikát môžete vygenerovať pomocou nástrojov openssl, ktoré máte pravdepodobne už nainštalované:
openssl req -new -x509 -days 1098 -out moj_cert.pem -keyout moj_key.pem
Čo zadané parametre znamenajú?
- -new – vytvoriť novú žiadosť;
- -x509 – vytvoriť certifikát podpísaný sám sebou (self-signed);
- -out meno_súboru – súbor, do ktorého bude uložený certifikát;
- -keyout meno_súboru – súbor, do ktorého bude zapísaný kľúč;
- -days počet_dní – doba platnosti certikátu.
Možno pridať ešte aj parameter:
- -nodes – vygenerovaný kľúč nebude zašifrovaný (a teda nebude potrebné heslo).
Pri generovaní certifikátu budete požiadaný o niekoľko informácií:
- heslo (2×) – ak má byť kľúč zašifrovaný;
- Common Name – meno servera (u mňa debserver.skk);
- ostatné veci nie sú dôležité a môžu byť ponechané prázdne, len dajte pozor názve spoločnosti, ktoré má predvolenú hodnotu.
Ako výsledok generovania sú v aktuálnom adresári dva súbory, konkrétne moj_cert.pem a moj_key.pem. Ako ich mená napovedajú, jeden obsahuje certifikát a druhý zase kľúč, ale nazvať ich môžete ľubovoľne. Ich nainštalovanie je jednoduché a spočíva v prekopírovaní do adresárov:
- súbor certifikátu do /etc/ssl/certs/
- súbor kľúča do /etc/ssl/private/
cp moj_cert.pem /etc/ssl/certs/
cp moj_key.pem /etc/ssl/private/
Úplne rovnaký efekt možno docieliť vygenerovaním certifikátu pomocou nástroja certtool z balíka gnutls-bin:
certtool --generate-privkey --outfile moj_key.pem
certtool --generate-self-signed --load-privkey moj_key.pem --outfile moj_cert.pem
Problém!!!
Debian Squeeze vytvára adresár /etc/ssl/private vlastnený root:root s právami 700, čo má za následok, že OpenLDAP nedokáže tam umiestnený certifikát čítať. Niektoré iné programy čítajú SSL certifikáty ešte pred tým, ako sa zbavia práv root a spustia sa pod svojim používateľom, čo OpenLDAP v Squeeze zjavne nerobí.
Wiki Debianu o tom taktne mlčí, spomína len riešenie v Lenny, ktoré v tomto prípade nepomôže. Aké sú teda možnosti? Možno urobiť tento adresár dostupný pre všetkých, to je ale veľmi nebezpečný nápad, pretože si bude môcť každý tento súkromný kľúč nie len prečítať, ale aj skopírovať a použiť!
Ako správne poznamenal v komentári GeorgeWH, problém možno v squeeze riešiť inštaláciou balíka ssl-cert a následným pridaním používateľa openldap do skupiny ssl-cert!
Oveľa bezpečnejšie sa mi zdá prispôsobiť si odporúčané riešenie z Lenny, a teda vytvoriť systémovú skupinu ssl-cert:
addgroup --system ssl-cert
Pridať používateľa openldap (východzie nastavenie slapd) do tejto skupiny:
addgroup openldap ssl-cert
No a teraz prispôsobiť práva spomínaného adresára tak, aby bol jeho obsah prístupný používateľom skupiny ssl-cert:
chown :ssl-cert /etc/ssl/private
chmod 710 /etc/ssl/private/
Nastavenie servera
Po vygenerovaní a nainštalovaní certifikátu a kľúča, treba serveru OpenLDAP oznámiť, kde má certifikáty hľadať. Import súboru LDIF mi nefungoval, preto treba zmeny zadať priamo:
ldapmodify -X EXTERNAL -H ldapi:///
dn: cn=config
add: olcTLSCertificateFile
olcTLSCertificateFile: /etc/ssl/certs/moj_cert.pem
-
add: olcTLSCertificateKeyFile
olcTLSCertificateKeyFile: /etc/ssl/private/moj_key.pem
-
add: olcTLSVerifyClient
olcTLSVerifyClient: never
Pokiaľ používate podpísaný certifikát (aj vlastnú CA), môžete pridať aj cestu k súboru s používanými CA:
add: TLSCACertificateFile
TLSCACertificateFile /etc/ssl/certs/meno_súboru
Po nastavení ciest k certifikátom už možno zapnúť podporu LDAPS v /etc/default/slapd pridaním ldaps:// do parametra SLAPD_SERVICES:
SLAPD_SERVICES="ldap:/// ldaps:/// ldapi:///"
Prípadne nastaviť server tak, aby nešifrovane bežal len na lokálnych spojeniach:
SLAPD_SERVICES="ldap://127.0.0.1/ ldaps:/// ldapi:/// "
A po tomto všetkom treba server reštartovať:
invoke-rc.d slapd restart
Nastavenie klienta
Pokus o pripojenie k LDAPS s východzím nastavením vedie k chybe:
ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
Táto chyba je spôsobená nedôveryhodným (self-signed) certifikátom, na testovacie účely postačí odstrániť nastavenie TLS_CACERT a zmeniť nastavenie kontroly certifikátu v /etc/ldap/ldap.conf na hodnotu never alebo allow:
#TLS_CACERT ...
TLS_REQCERT allow
Aby mohol byť použitý bezpečný protokol aj v nástrojoch NSS a PAM, je treba nastaviť v súboroch /etc/libnss-ldap.conf a /etc/pam_ldap.conf niektoré parametre. Najmä treba nastaviť správnu URI:
uri ldaps://127.0.0.1/
Zapnúť aj používanie SSL pomocou
ssl start_tls
ssl on
Odkazy
Všeobecné
Súvisiace
Podporujem
Komentáre
Spominany problem s pristupom do adresara "/etc/ssl/private" riesi instalacia balika "ssl-cert" presne takym sposobom, ako si uviedol. Takze staci len pridat usera openldap do skupiny ssl-cert.
Tento zmysel tohoto balíka mi ostal ukrytý
olcAccess: {2}to * by self write by dn="cn=admin,dc=mojadomen a,dc=sk" write by * read
do "/etc/ldap/slapd.d/cn\=co nfig/olcDatabase\=\{0\}co nfig.ldif". Potom uz fungovalo admin konto "cn=admin,dc=mojadomena,dc=sk".
Tu je ldif na pridanie TLS parametrov, ktory mi fungoval:
dn: cn=config
changetype: modify
add: olcTLSCertificateFile
olcTLSCertificateFile: /etc/ssl/certs/ldap_cert.pem
-
add: olcTLSCertificateKeyFile
olcTLSCertificateKeyFile: /etc/ssl/private/ldap_key.pem
-
add: olcTLSVerifyClient
olcTLSVerifyClient: never
K nastaveniu práv však poznamenám, že predvolene je prístup ku konfigurácii nastavený tak, že pristupovať môže len používateľ root (UID=0), a to cez ldapi:// a mechanizmus „-Y EXTERNAL”.
Je otázne, či je dobré takéto povolenie nastavenia adminovi a IMHO má zmysel len vtedy, ak admin nemá prístup k root, inak zavádza isté bezpečnostné riziko, pretože defacto povoľuje vzdialenú konfiguráciu...
Som však veľmi vďačný za tieto dva komentáre, pretože sú dvomi z mála, ktoré sú k veci!
dlouho jsem s tím bojoval,
server mi nechtěl nastartovat s chybou : TLS init def ctx failed: -69
Pomohlo mi vygenerovat certifikáty pomocí certtool.
Co je podporováno ověříte pomocí ldd $(which slapd).
Jinak, děkuji velmi za článek
aj ja ďakujem za doplnenie