Chi centralizza l’autenticazione su un directory LDAP non elimina il problema delle credenziali, lo sposta: dalla /etc/shadow di ogni host a un singolo servizio di rete e alla sua configurazione. Qui guardo a OpenLDAP 2.2 (la linea corrente, prima release a dicembre 2003) come a una superficie d’attacco, non come a un prodotto da adottare.

Contesto

OpenLDAP è l’implementazione open source di riferimento di LDAPv3, il protocollo definito da RFC 2251 (dicembre 1997) e dall’insieme di documenti che RFC 3377 (settembre 2002) indica come specifica completa. Il codice discende dal server LDAP sviluppato all’Università del Michigan, la cui ultima release risale al 1996; il progetto OpenLDAP nasce nel 1998 a partire da quel sorgente.

Il demone è slapd (Standalone LDAP Daemon). La sua struttura viene dal codice del Michigan: un frontend che gestisce accesso di rete e protocollo, separato da un backend che si occupa solo dell’archiviazione. La separazione ha un peso sulla sicurezza, perché frontend e backend hanno modelli di fiducia diversi: il frontend parla con client non fidati, il backend con il filesystem locale.

Il caso d’uso che giustifica il directory è la lettura. Un login produce una bind seguita da una search; le modifiche alle credenziali sono rare. Su un’infrastruttura mista Linux/FreeBSD/Solaris, dove Active Directory non c’è, slapd diventa il punto unico contro cui ogni servizio — PAM, posta, web, VPN — verifica le identità. Punto unico vuol dire anche bersaglio unico.

Architettura

Il modello dei dati è un albero, il DIT (Directory Information Tree). Ogni entry ha un DN (Distinguished Name) univoco, per esempio uid=mrossi,ou=people,dc=example,dc=com. Lo schema vincola classi e attributi: una entry inetOrgPerson ammette cn, mail, userPassword. Lo schema è estensibile, ed è qui che si prende la prima decisione di sicurezza: gli attributi che si sceglie di esporre, e le ACL che li proteggono, definiscono cosa un client anonimo o autenticato può leggere.

In OpenLDAP 2.2 il backend transazionale di riferimento è BDB, costruito su Berkeley DB, con transazioni e recovery dopo un crash; c’era già dalla 2.1 (giugno 2002). Esistono LDBM e altri backend, ma per un servizio di autenticazione quel che serve è la consistenza dopo un’interruzione, non la velocità grezza.

La novità strutturale della 2.2 sono gli overlay: moduli che si innestano nella pipeline delle richieste e cambiano il comportamento di slapd senza toccare il backend. Due overlay hanno conseguenze dirette sulla sicurezza. ppolicy porta le politiche sulle password dentro al directory — scadenza, lunghezza minima, blocco dopo N tentativi falliti — invece di lasciarle a ogni client. syncrepl gestisce la replica del contenuto.

syncrepl prende il posto del vecchio slurpd, il demone di replica ereditato dal Michigan, che lavorava in push: il provider spingeva i cambiamenti verso le repliche. syncrepl ribalta lo schema: è il consumer a chiedere, e definisce la propria replica come risultato di una search (searchbase, scope, filter, attrs). Le modalità sono due, refreshOnly con polling periodico e refreshAndPersist con connessione persistente che riceve gli aggiornamenti man mano. Il meccanismo è descritto dal documento draft-zeilenga-ldup-sync dell’IETF, a questa data ancora Internet-Draft e non RFC.

Il punto critico

La sicurezza si decide nel trasporto della bind. Una simple bind manda il DN e la password in chiaro dentro al protocollo. Se il canale non è cifrato, ogni login espone la credenziale sul filo: chi intercetta il segmento di rete tra client e slapd raccoglie password in chiaro senza dover violare nulla.

OpenLDAP offre due strade, e vanno tenute distinte. TLS cifra il canale: parte sulla porta 636 (ldaps) oppure sulla 389 con l’estensione StartTLS di RFC 2830. SASL (RFC 2222) è invece il livello di autenticazione: apre a meccanismi come DIGEST-MD5, che evita di trasmettere la password in chiaro anche su un canale non cifrato, o GSSAPI per integrare Kerberos. Le due cose non si escludono: SASL EXTERNAL su un canale TLS con certificato client lega l’identità al certificato verificato durante l’handshake.

La conseguenza pratica è secca. Una simple bind senza TLS non si usa fuori da localhost. Lato server lo si impone con la direttiva security nella configurazione di slapd, che fissa una forza minima — per esempio rifiuta le bind che non raggiungono un certo ssf (security strength factor). Senza questo vincolo la decisione resta a ogni client, e basta un client configurato male per buttare a terra la cifratura imposta agli altri.

Restano le ACL. In slapd il controllo d’accesso è dichiarativo e ordinato: le regole access to ... by ... si valutano nell’ordine, decide la prima che corrisponde. L’attributo userPassword vuole una regola esplicita che lo renda leggibile solo all’entry stessa (e a chi amministra) e scrivibile in auth per la bind — mai leggibile da un client anonimo. Una search anonima che riesce a leggere gli hash trasforma il directory in un dump di credenziali offline.

Implicazioni

Centralizzare l’autenticazione concentra anche la conseguenza di un errore. Un’ACL troppo larga su userPassword, una simple bind senza TLS, una replica syncrepl che viaggia in chiaro verso un consumer in un’altra sede: ognuna di queste, da sola, espone l’intero insieme di credenziali, non quelle di un singolo host. Il directory eredita il modello di minaccia di tutti i servizi che vi si appoggiano.

In cambio, la concentrazione rende verificabili poche cose ben definite. Lo stato di sicurezza di un’infrastruttura OpenLDAP si legge in un numero limitato di punti: le direttive TLS* e security nella configurazione, il blocco access to per gli attributi sensibili, i meccanismi SASL abilitati, il canale usato da syncrepl. Sono testabili dall’esterno: una bind anonima e una search su userPassword dicono in pochi secondi se le ACL reggono.

Limiti

Qui guardo alla configurazione del server, non alla catena dei client. PAM e nss_ldap sull’host hanno la loro configurazione TLS e il loro modo di gestire un directory che non risponde; un host che ricade su credenziali locali quando slapd è irraggiungibile apre un percorso che il server non controlla. La parte syncrepl la descrivo come meccanismo di replica del contenuto, senza valutarla sotto attacco attivo al provider, che è un tema a sé. E conta la versione: quanto sopra vale per la linea 2.2, e direttive e default cambiano tra una serie e l’altra.

https://www.openldap.org/doc/admin22/guide.html https://www.rfc-editor.org/rfc/rfc2251 https://www.rfc-editor.org/rfc/rfc3377 https://www.rfc-editor.org/rfc/rfc2830 https://tools.ietf.org/html/draft-zeilenga-ldup-sync-05 https://www.openldap.org/pub/umich/guide.pdf https://www.noze.it/insights/openldap-open-source/

Immagine di copertina: Diagramma ad albero di una directory LDAP con il nodo radice dc=meudomini,dc=org che si dirama in cn=admin, ou=People e ou=Groups,… — diagramma di Rferrero, CC BY-SA 4.0 — https://commons.wikimedia.org/wiki/File:EsquemaDominiLDAP.jpg