Quasi tutte le valutazioni di sicurezza AD, i test di penetrazione o le discussioni sull'architettura finiscono per contenere la raccomandazione di "passare da LDAP non protetto a LDAPS" per Active Directory (AD). Lavorando per un fornitore di software i cui prodotti "interagiscono con AD", mi viene posta più volte alla settimana la domanda: "Il vostro prodotto XY supporta LDAPS? Se no, è in programma?". Nella maggior parte dei casi, la risposta corretta è "No, e non è un problema di sicurezza". Vediamo i motivi di questa risposta.
Qual è il problema con LDAPS?
Internet offre letteralmente migliaia di articoli, blog e video su come creare e importare certificati TLS nei controller di dominio (DC) per far sì che supportino LDAP su TLS sulla porta 636/TCP. Per ulteriori informazioni sul metodo utilizzato dai DC per selezionare il certificato LDAPS quando esistono più candidati, è possibile leggere questo post di Marc-André Moreau su AwakeCoding, ma per ricapitolare, Moreau spiega che:
"Abilitare e applicare LDAPS è oggi un'operazione comune per rafforzare la sicurezza negli ambienti Windows Active Directory... In teoria sembra tutto perfetto, finché non ci si rende conto che non solo [non è possibile] selezionare esplicitamente il certificato LDAPS da utilizzare, ma non ci sono log da abilitare e nessun modo per diagnosticare il problema".
Ciò che questi articoli su "implementare LDAPS" solitamente non dicono è cosa fare con LDAPS dopo averlo abilitato. Una cosa è certa, tuttavia: i vostri DC continueranno a fornire LDAP senza TLS sulla porta 389 e non potrete disabilitarlo o bloccarlo sul firewall senza causare gravi interruzioni ai membri AD.
Ripeto: un membro AD utilizzerà sempre la porta 389/3268 per qualsiasi query LDAP/GC che deve eseguire in virtù del suo essere membro AD. Non c'è modo di modificare tale comportamento o di indurre un computer membro a utilizzare LDAPS supportato da TLS sulla porta 636/3269, punto. Non esiste inoltre un modo standardizzato e universalmente affidabile per far sì che l'infrastruttura pubblicizzi LDAPS alle applicazioni.
Perché le soluzioni alternative LDAPS non funzionano
Poiché l'unico meccanismo noto per l'individuazione dei servizi LDAP è il DNS, sono state provate diverse tecniche:
- Aggiungi un record SRV per LDAPS, come _ldaps._tcp.domain.com insieme a _ldap e _gc.
- Modificare il numero di porta nei record del servizio LDAP da 389 a 636 (e impedire che vengano aggiornati dai DC).
- Sostituire i record SRV _ldap con _ldaps (ovvero, eliminare effettivamente i record _ldap e _gc ).
Ecco il problema di questi approcci: non funzionano.
L'aggiunta di un record SRV per LDAPS non cambia nulla
Poiché _ldaps non è un servizio standard, nessuna applicazione lo cercherà nel DNS. Se crei un'applicazione che potrebbe trarre vantaggio da LDAP su TLS, puoi implementare il rilevamento del servizio LDAPS nel tuo codice; funzionerà quindi come qualsiasi altro rilevamento di servizi personalizzati. Tuttavia, non è e non è mai stato uno standard industriale, quindi nessun'altra applicazione lo utilizzerà.
Cambiare il numero di porta non funzionerà
La modifica del numero di porta non interromperà le comunicazioni dei membri AD perché la porta 389 è hardcoded in Windows. Questa azione potrebbe interrompere altre applicazioni che utilizzano LDAP, perché il passaggio dalla porta 389 alla porta 636 non le porterà a tentare di stabilire un handshake TLS prima di provare un binding LDAP.
Eliminazione dei record _ldap e _gc = Semplicemente non farlo
Il terzo approccio è un ottimo modo per interrompere il rilevamento dei servizi per LDAP, compreso quello dei membri del dominio. Non provateci a casa (né al lavoro... né in nessun altro posto, in realtà).
Bind semplici vs bind SASL
Quindi, LDAP in Active Directory è semplicemente "insicuro per definizione"? Al contrario.
Il motivo per cui ti è stato consigliato di passare a LDAPS è quello di proteggere le credenziali in chiaro utilizzate da LDAP se esegui un binding semplice. Il fatto è che i membri AD, e la maggior parte delle applicazioni che accedono ad AD tramite LDAP, non utilizzano binding semplici. Utilizzano invece binding SASL in cui l'autenticazione viene eseguita da GSS-SPNEGO e il livello di crittografia LDAP viene negoziato con chiavi di sessione scambiate durante il processo di autenticazione.
Quindi, non solo non ci sono credenziali in chiaro da proteggere, ma la comunicazione che avviene è, di fatto, già crittografata, senza bisogno di ricorrere a certificati per il livello TLS. Questo meccanismo non è limitato ai membri del dominio. Qualsiasi applicazione può farlo, indipendentemente dal sistema operativo e dall'appartenenza al dominio.
Cosa dovresti fare per rafforzare AD LDAP, se non bloccare la porta 389?
Se sei certo che nessuna applicazione nel tuo ambiente necessiti effettivamente di collegamenti semplici con credenziali in chiaro, applica la firma LDAP sui tuoi DC impostando i criteri di gruppo come descritto qui. Oltre a... beh, avere le comunicazioni firmate, il che impedirà una serie di attacchi relay Kerberos e NTLM, i DC rifiuteranno anche un collegamento semplice su una connessione LDAP non crittografata.
Se vuoi essere assolutamente certo di non interferire con nulla, osserva i registri eventi dei tuoi DC, come descritto in questo articolo sempre attuale di Learn sulla firma LDAP, il Channel Binding e LDAPS.
Se disponi di applicazioni che richiedono un binding semplice, forza tali applicazioni a utilizzare la porta 636/3269 configurando questo comportamento (e l'attendibilità dei certificati LDAPS) all'interno delle applicazioni stesse.
[Nota dell'editore: questo blog è stato adattato dal post originale dell'autore.]
