11 Ist das auch alles sicher?

Transkript

1 Ist das auch alles sicher? Ein Verzeichnisdienst hat ja die prinzipielle Funktion der selektiven Informationsübermittlung. In einem Netzwerk greifen also viele Anwendungen und Clients lesend auf diesen Dienst zurück. Hierbei können dann Überlegungen zur Datensicherheit dazu führen, dass einerseits nur ein autorisierter Kreis von Clients lesend oder auch schreibend auf ausgewählte Daten zugreifen kann, andererseits die Datenübermittlung verschlüsselt erfolgen soll. Die Zugriffssteuerung der Clients erfolgt üblicherweise durch Access Control Lists (ACL) bzw. durch den Parameter access in der Datei slapd.conf. Bei der Zugriffsprüfung durch slapd kann die Authentifizierung durch unterschiedliche Mechanismen und Methoden erfolgen. Diese sind schon im Kapitel 10 Methoden der Authentifizierung eingehend vorgestellt worden, daher werden sie hier nur noch einmal im Zusammenhang erwähnt. SASL Das Paket cyrus-sasl stellt die Tools sasldb, saslauth und auxprop bereit. Es muss an dieser Stelle noch einmal die Warnung erfolgen, dass Passwörter in sasldb in Plaintext gespeichert werden. Der Lesezugriff auf sasldb sollte also sehr restriktiv gehandhabt werden. Häufig nutzen aber auch andere Anwendungen, wie z.b. Sendmail oder Postfix, diese Quelle, so dass auch ihnen der Lesezugriff ermöglicht werden muss. Sofern nicht die Methode PLAIN zur Authentifizierung genutzt wird, werden aber Passwörter bzw. die Prüfsummen dieser Passwörter verschlüsselt übertragen. Dies geschieht dann in Abhängigkeit des gewählten Mechanismus, also z.b. DIGEST-MD5, CRAM-MD5 oder OTP. SASL und darauf basierende Tools können zu einem strong bind mit dem Verzeichnisdienst genutzt werden. Dies im Gegensatz zu einem simple bind, wie dies z.b. die Speicherung des Passwortes innerhalb des DIT wäre. Die unten stehende Aufzeichnung eines Verbindungsprotokolls zeigt noch eine undokumentierte SASL-Besonderheit, nämlich den Mechanismus EXTERNAL. Dieser Mechanismus wird erst aktiviert, wenn eine sichere SSL/TLS-Verbindung hergestellt worden ist. Die Besonderheit dieses Mechanismus besteht darin,

2 Ist das auch alles sicher? Viele Clients sind aber noch nicht fähig, ein strong bind mittels SASL zu realisieren, wie z.b. Samba 2.2.5, Ldapbrowser oder auch GQ-0.6 dass der Distinguished Name des Client-Zertifikats Das wird aber eingehender weiter unten erörtert. ausgelesen wird und somit eine Authentifizierung durch den DN im DIT erfolgen kann. PAM Die PAM-Module werden eigentlich nicht zur Authentifizierung gegenüber einem Verzeichnisdienst genutzt, sondern das Modul pam_ldap nutzt die Verzeichniseinträge uid: und password: der Posixgruppe bzw. des Posixaccounts zur Authentifizierung gegenüber anderen Diensten wie z.b. Login. Da aber PAM fähig ist, SSL/TLS zu nutzen, werden die Daten verschlüsselt übertragen, was dann doch die Datensicherheit erhöht. PAM nutzt dann anstelle der Dateien /etc/passwd und /etc/shadow den Verzeichnisdienst zur Prüfung der Anwenderidentität und des Passwortes. Kerberos Eine sichere Authentifizierung gegenüber dem Verzeichnisdienst kann mittels SASL/GSSAPI erfolgen. Darüber hinaus kann auch eine Authentifizierung gegenüber anderen Diensten durch das Tool saslauthd, aufgerufen mit dem Parameter -kerberos,erfolgen. OpenLDAP kann noch keine starke Authentifizierung mittels saslauthd -kerberos vornehmen, wohl aber eine anonyme Authentifizierung SSL/TLS Das Protokoll für TLS Version 1 (Transport Layer Secure) baut auf SSL (Secure Socket Layer) auf. SSL Version 3.0 wird beschrieben in «draftfreier-ssl-version3-02», veröffentlicht von der Transport Layer Security Work Group (einer Arbeitsgruppe der IETF), während TLS v1 in RFC 2246 definiert wird. TLS ist nicht der Nachfolger von SSL, sondern ist ein eigenständiges Protokoll. Das primäre Ziel von TLS besteht darin, die Integrität und eine geschützte Verbindung zwischen zwei miteinander kommunizierenden Anwendungen herzustellen. Hierzu wird eine Verschlüsselungsmethode eingesetzt, die auf Zertifikat und Schlüssel basiert. TLS prüft anhand des Zertifikats die Identität des Servers und stellt mit den ausgehandelten Verschlüsselungsmethoden eine sichere Datenübertragung her. Das nachfolgende Protokoll einer Verbindungsherstellung mag dies verdeutlichen. dieter@marin:/usr/local/bin>./ldapsearch -d 1 -ZZ -b "ou=users,o=avci,c=de" -s sub "(&(objectclass=posixaccount)(mail=*))" ldap_create ldap_extended_operation_s ldap_extended_operation

3 11.1 SSL/TLS 135 ldap_send_initial_request ldap_new_connection ldap_int_open_connection ldap_connect_to_host: TCP marin.l4b.de:389 ldap_new_socket: 3 ldap_prepare_socket: 3 ldap_connect_to_host: Trying :389 [...] ldap_int_sasl_open: host=marin.l4b.de ldap_open_defconn: successful ldap_send_server_request ber_flush: 31 bytes to sd 3 ldap_result msgid 1 [...] ** Connections: * host: marin.l4b.de port: 389 (default) refcnt: 2 status: Connected last used: Wed Nov 6 19:18: ** Outstanding Requests: * msgid 1, origid 1, status InProgress outstanding referrals 0, parent count 0 ** Response Queue: Empty [...] TLS trace: SSL_connect:before/connect initialization TLS trace: SSL_connect:SSLv2/v3 write client hello A TLS trace: SSL_connect:SSLv3 read server hello A [Plaintext-Kopfzeilen des Zertifikats] TLS trace: SSL_connect:SSLv3 read server certificate A TLS trace: SSL_connect:SSLv3 read server certificate request A TLS trace: SSL_connect:SSLv3 read server done A TLS trace: SSL_connect:SSLv3 write client certificate A TLS trace: SSL_connect:SSLv3 write client key exchange A TLS trace: SSL_connect:SSLv3 write certificate verify A TLS trace: SSL_connect:SSLv3 write change cipher spec A TLS trace: SSL_connect:SSLv3 write finished A TLS trace: SSL_connect:SSLv3 flush data TLS trace: SSL_connect:SSLv3 read finished A ldap_pvt_sasl_getmech ldap_interactive_sasl_bind_s: server supports: GSSAPI \ ANONYMOUS CRAM-MD5 DIGEST-MD5 PLAIN OTP EXTERNAL ldap_int_sasl_bind: GSSAPI ANONYMOUS CRAM-MD5 \ DIGEST-MD5 PLAIN OTP EXTERNAL

4 Ist das auch alles sicher? SASL/GSSAPI authentication started ldap_sasl_bind_s ldap_sasl_bind [...] Wenn man nun die Liste der Authentifizierungsmethoden ansieht, die SASL bietet, erkennt man eine neue Methode, nämlich EXTERNAL. Hierauf wird weiter unten näher eingegangen X.509-Zertifikate und -Schlüssel erstellen Um TLS nutzen zu können, müssen ein Zertifikat und ein Schlüssel (Key) erstellt werden. Das Zertifikat muss von einer Certificate Authority (CA) beglaubigt werden. Für unser Testsystem werden wir selbst Certificate Authority sein. Dies hat allerdings den Nachteil, dass unsere CA außerhalb des lokalen Netzes nicht akzeptiert wird. Mit unserem Beispielserver wollen wir aber auch nicht nach außen kommunizieren und auch keine Verbindung von außen zulassen. Auf unserem Testsystem wird openssl-0.9.6g eingesetzt.das Paket OpenSSL stellt im Verzeichnis misc/ die Tools CA.sh und CA.pl bereit. Je nach Präferenz (für perl oder bash) kann eines der Tools zur Erzeugung der notwendigen Zertifikate genutzt werden. Zuvor muss jedoch noch die Datei openssl.cnf den eigenen Systembedingungen angepasst werden. In unserem Falle: # For the CA policy [ policy_match ] countryname = match stateorprovincename = optional organizationname = match organizationalunitname = optional commonname = supplied address = optional # For anything policy [ policy_anything ] countryname = optional stateorprovincename = optional localityname = optional organizationname = optional organizationalunitname = optional commonname = supplied address = optional [ req_distinguished_name ] countryname = Country Name (2 letter code) countryname_default = DE countryname_min = 2

5 11.1 SSL/TLS 137 countryname_max = 2 # stateorprovincename = State or Province Name (full name) # localityname = Locality Name (eg, city) organizationname = avci 0.organizationalUnitName = users 1.organizationalUnitName = partner commonname = Common Name (eg, YOUR name) commonname_max = 64 # address = Address # address_max = 40 Falls Sie in Ihrem Distinguished Name eine Domain Component (dc) als Attribut verwenden, müssen sie countryname durch domaincomponent ersetzen. Sofern Domain Component mehrfach genutzt wird, kann dies, wie am Beispiel organizationalunitname demonstriert, mehrfach gesetzt werden, allerdings dann durch Nummerierung und Punkt erweitert. Zur Vereinfachung der Prozedur wird CA.pl oder CA.sh in das Konfigurationsverzeichnis von OpenLDAP kopiert, im vorliegenden Fall /etc/openldap. Gegebenenfalls sollte in openssl.cnf noch die Pfadangabe für»dir«von./democa auf z.b../certca geändert werden. Das ist aber nur Kosmetik und hat keine praktischen Auswirkungen. Zuerst muss ein Zertifikat der Certificate Authority erstellt werden../ca.pl -newca erzeugt die neue Certificate Authority. Hierbei werden folgende Fragen gestellt und beantwortet: CA certificate filename (or enter to create): RET Taste Enter PEM pass phrase: geheim-1 Verifying password - Enter PEM pass phrase: geheim-1 Country Name [AU]: DE State or Province Name: GERMANY Locality Name: HAMBURG Organization Name: avci Organizational Unit Name: CA Verwaltung Common Name: AVCI Address: dieter@avci.de Jetzt wird die CA erstellt und als cacert.pem im Verzeichnis./certCA abgelegt. Als Nächstes wird das Server-Zertifikat für den LDAP-Server erstellt. Hierbei ist darauf zu achten, dass als Common Name der Hostname des Servers einschließlich Domainanteil eingetragen wird, denn nur mit diesem Namen wird der Host authentifiziert../ca.pl -newcert

6 Ist das auch alles sicher? Die folgenden Fragen müssen Ihrem System entsprechend beantwortet werden. Dieses neue Zertifikat wird als newreq.pem im pwd (present working directory) abgelegt, in unserem Falle /etc/openldap. Nun muss newreq.pem noch von der Certificate Authority signiert werden:./ca.pl -signcert Als Passphrase muss hier das Passwort der CA angegeben werden. Das signierte Zertifikat wird als newcert.pem im pwd abgelegt. Zum Schluss sollte noch das Passwort aus newreq.pem entfernt werden, da die ständige Passwortabfrage nur hinderlich ist. openssl rsa -in newreq.pem -out ldapkey.pem Als Passwort muss hier das Passwort des Servers angegeben werden.um die Bezeichnungen etwas übersichtlicher zu halten, wird newcert.pem noch umbenannt in ldapcert.pem. Zur Nachprüfung, ob denn auch alles richtig ist, kann mit./ca.pl -verify ldapcert.pem die Richtigkeit geprüft werden. Als Nächstes müssen dem LDAP-Server die Zertifikate bekannt gemacht werden. Hierzu werden folgende Einträge in slapd.conf vorgenommen: TLSCertificateFile /etc/openldap/ldapcert.pem TLSCertificateKeyFile /etc/openldap/ldapkey.pem TLSCACertificateFile /etc/openldap/certca/cacert.pem Für zukünftige Erweiterungen können noch folgende, auskommentierte Einträge vorgenommen werden: # TLSCipherSuite HIGH:MEDIUM:+SSLv2 # TLSVerifyClient allow Die Kommentarzeichen sollen erst entfernt werden, wenn alle Clients zufriedenstellend funktionieren, sonst ist hier die Grundlage für eine verzweifelte Fehlersuche gelegt. Wir könnten hier aus eigener, leidvoller Erfahrung berichten. So kann z.b. OpenSSL die Server-Anforderung TLSCipherSuite nicht erfüllen, was dann zu einem handshake failure führt. Noch eine Bemerkung zu möglichen Fehlerquellen. Achten Sie darauf, dass in den Konfigurationsdateien slapd.conf und ldap.conf und /.ldaprc keine Doppelpunkte (:) oder Gleichheitszeichen (=) gesetzt sind. Diese Unachtsamkeit hat uns drei Tage verzweifeltes Suchen eingebracht.

7 11.1 SSL/TLS 139 Jetzt sollte noch eine letzte Prüfung durchgeführt werden, ob denn auch die Zertifikate erkannt und verifiziert werden. Hierzu wird folgender Befehl eingegeben: openssl s_client -connect localhost:389 -showcerts Als Ergebnis sollten jetzt cacert.pem und ldapcert.pem ausgelesen werden. Stören Sie sich nicht an der Warnung self signed certificate,diesist nur eine Warnung und hat keinen Einfluss auf die Funktionalität. Wenn aber die Fehlermeldung handshake failure auftritt, begeben Sie sich auf die Fehlersuche. Häufig liegt der Fehler in der Konfiguration und nicht in den Zertifikaten. Daher: Prüfen Sie, ob slapd läuft. Prüfen Sie die Schreibweise in den Konfigurationsdateien. Achten Sie auf (:) und (=). Setzen Sie Kommentarzeichen (#) vor TLSCipherSuite. Prüfen Sie noch einmal. Prüfen Sie die Zertifikate mit CA.pl -verify. Wenn diese Prüfungen nicht die Fehlerursache zutage gebracht haben, führen Sie ein strace durch und beachten Sie die letzen Zeilen des Outputs Zertifikate für Clients erstellen Clients, also Anwendungen, die den LDAP-Server befragen, können eigene Zertifikate besitzen, die durch dieselbe CA signiert sind wie das Server-Zertifikat. Zu diesem Zweck werden, wie oben beschrieben, mit./ca.pl -newreq weitere Zertifikate erstellt und mit./ca.pl -signreq signiert. Es ist ratsam, zu Testzwecken diese Client-Zertifikate noch nicht von ihrem Passwort zu befreien, so dass man erkennen kann, welche Anwendungen eine SSL/TLS-Verbindung zum Verzeichnisdienst zum Zwecke der Authentifizierung aufbauen wollen. Die Client-Zertifikate werden entweder in ein geeignetes Verzeichnis innerhalb des Homeverzeichnisses der Anwender kopiert oder in das systemweite Konfigurationsverzeichnis. In unserer Testumgebung z.b. hat jeder Anwender in seinem Home ein Verzeichnis /certs, weiterhin gibt es ein Verzeichnis/etc/certs, in dem Host-Zertifikate abgelegt werden. Für Clients besteht die Möglichkeit, die Konfiguration des Verzeichnisdienstes an mehreren Orten zu suchen. Diese sind:

8 Ist das auch alles sicher? die systemweite Konfigurationssdatei /etc/openldap/ldap.conf, das Arbeitsverzeichnis der Anwendung $PWD/ldaprc, das Homeverzeichnis des Anwenders /.ldaprc. In diesen Konfigurationsdateien werden serverspezifische Informationen bereitgestellt. So auch Informationen über mögliche TLS- Verbindungen zum Server und Pfade zu den erforderlichen Zertifikaten. Dabei ist allerdings ein Unterschied zu berücksichtigen: In der Datei ldap.conf werden die Daten des Hosts bekannt gegeben, in den Dateien ldaprc bzw. /.ldaprc werden die clientspezifischen Pfade der Anwender gesetzt. So enthält auf unserem Testsystem z.b. die Datei ldap.conf folgende Zeilen: TLS_CACERT /etc/cert/cacert.pem TLS_CERT /etc/cert/ldap_clientcert.pem TLS_KEY /etc/cert/ldap_clientkey.pem Die Datei /.ldaprc dagegen folgenden Eintrag: TLS_CACERT /etc/cert/cacert.pem TLS_CERT /home/dieter/cert/ldap_clientcert.pem TLS_KEY /home/dieter/cert/ldap_clientkey.pem Um das alles noch einmal zu verdeutlichen: Es wurden in obigem Beispiel drei Sätze Schlüssel und ein CA-Zertifikat erstellt. Ein Schlüsselpaar ldapcert.pem und ldapkey.pem für den Verzeichnisdienst, konfiguriert in slapd.conf; ein Schlüsselpaar ldap_clientcert.pem und ldap_clientkey.pem für jeden Host, konfiguriert in ldap.conf; ein Schlüsselpaar, hier ebenfalls ldap_clientcert.pem und ldap_clientkey.pem genannt, für jeden Anwender, konfiguriert in /.ldaprc. Signiert wurden alle drei Zertifikate mit dem CA-Zertifikat. Weiterhin wurde cacert.pem einmal auf jeden Host kopiert. Nachdem alles nun eingerichtet und konfiguriert wurde, kann nun geprüft werden, ob auch eine verschlüsselte Verbindung zum Verzeichnisdienst hergestellt wird. Hierzu sollte der Daemon slapd im Debugging-Modus laufen, also mit dem Flag -d und einem Debugging- Wert, beispielsweise dem Wert»7«, gestartet werden. Der Befehl könnte folgendermaßen lauten: slapd -d 7. Die in älteren Dokumenten enthaltenen Beispiele./slapd -h "ldap:// ldaps://" sollten nicht mehr genutzt werden, diese beziehen sich noch auf OpenLDAP-2.0.x. Durch das Flag ldaps:/// wird der Port 636 genutzt, was nur noch aus Gründen der Kompatibilität zu älteren Ver-

9 11.1 SSL/TLS 141 sionen ermöglicht wird und in zukünftigen OpenLDAP-Versionen entfallen soll. Es wird empfohlen, nur noch den Port 389 zu nutzen. Zur Kontrolle der Verbindung eignet sich die Clientanwendung ldapsearch, wobei die Befehlszeile diesen Inhalt haben könnte: ldapsearch -Y GSSAPI -ZZ -H "ldap://ldapserver.avci.de" -b "o=avci,c=de" -s sub "(&(objectclass=posixaccount)(uid=dieter))" Etwas weniger Informationen werden Sie bekommen, wenn Sie slapd nicht im Debugging-Modus laufen lassen, dafür aber ldapsearch mit dem zusätzlichen Flag -d 1 aufrufen. Sie sollten jetzt die oben dargestellten Logauszüge sehen und natürlich auch ein Suchergebnis erzielt haben. Die Erläuterungen des Suchbefehls wurden schon im Kapitel dargelegt Authentifizierung mittels X.509-Zertifikat Es ist ja schon an anderer Stelle erwähnt worden, dass SASL den Mechanismus EXTERNAL nutzt, um den Distinguished Name aus dem Zertifikat herauszulesen und eine Authentifizierung vorzunehmen. Folgender Log-Auszug mag dies verdeutlichen: dieter@marin:/usr/local/bin>./ldapsearch -Y EXTERNAL -ZZ \n -b "o=avci,c=de" -s sub "(&(objectclass=posixaccount) \n (uid=dieter))" SASL/EXTERNAL authentication started SASL username: CN=Dieter Kluenter,OU=partner, \ OU=users,O=avci,C=de SASL SSF: 0 # extended LDIF # # LDAPv3 # filter: (&(objectclass=posixaccount)(uid=dieter)) [...] Eine Authentifizierung unter Verwendung des Tools ldapwhoami zeigt das folgende Beispiel: dieter@marin:/usr/local/bin>./ldapwhoami -Y EXTERNAL -ZZ SASL/EXTERNAL authentication started SASL username: CN=Dieter Kluenter,OU=partner, \ OU=users,O=avci,C=de SASL SSF: 0 dn:cn=dieter kluenter,ou=partner,ou=users,o=avci,c=de

10 Ist das auch alles sicher? Der Security Strength Factor (SSF) mit dem Wert 0 zeigt an, dass der Distinguished Name des Zertifikates von SASL ohne Verschlüsselungsroutine ausgelesen wird. SASL erstellt für den Mechanismus EXTER- NAL keinen Security Layer, also keine Verschlüsselungsroutine, da diese schon von TLS bereitgestellt wird. Der Security Strength Factor für eine TLS-Verbindung ist abhängig von der Verschlüsselungsmethode des Keys. Als Standardverschlüsselung wird häufig DES gewählt, dies wäre dann ein TLS Strength Factor 56, kann aber in openssl.cnf definiert werden. Weitere Informationen hierzu liefert die Manual Page zu openssl. Wenn openssl.cnf nicht ausreichend den Gegebenheiten des Systems angepasst wurde, muss der wiedergegebene Distinguished Name nun noch durch reguläre Ausdrücke in slapd.conf (saslregexp) soweit gewandelt werden, dass ein Parsing durch slapd gegen den Inhalt des DIT erfolgen kann. Dies ist aber üblicherweise nicht erforderlich, wie auch das obige Beispiel zeigt. Wenn dann noch der Schlüssel (key) auf einer Diskette gespeichert wird und nicht in einem Verzeichnis des Anwenders, hat man schon fast eine Public Key Infrastructure TCP/IP-gesteuerte Zugriffe Ein in der UNIX-Welt verbreiteter Kontrollmechanismus ist die Zugriffssteuerung über die Datei /etc/hosts.allow respektive /etc/hosts.deny. Dieser recht simple Mechanismus kann auch für OpenLDAP genutzt werden, sofern das Paket mit dem Flag -enablewrappers kompiliert wurde. Es muss aber darauf hingewiesen werden, dass hierdurch der Zugriff von Hosts, aber nicht der Zugriff von Anwendern gesteuert wird. Das mag in vielen lokalen Netzen nicht unbedingt wünschenswert sein, aber trotzdem wollen wir auf diese Möglichkeit hinweisen. Ein Eintrag in /etc/hosts.allow, der den Zugriff aus dem lokalen Netz erlaubt, könnte folgendermaßen aussehen: slapd: / : ALLOW slapd: ALL : DENY Hierbei ist es wichtig, dass IP-Adressen genutzt werden, da slapd üblicherweise kein Reverse Lookup des Hostnamens durchführt, also die übermittelte Adresse nicht durch einen Nameservice in einen Hostnamen übersetzt. Die Konsequenz ist, dass die Option LOCAL nicht genutzt werden kann. Um dies zu verdeutlichen: Der folgende Eintrag wird nicht funktionieren:

11 11.2 TCP/IP-gesteuerte Zugriffe 143 slapd: LOCAL : ALLOW slapd: ALL : DENY Weiterführende Informationen zu den Optionen finden Sie in den Manual Pages zu (5) hosts_access und hosts_options.