Problemi di sicurezza LDAP?

3

Ho installato molte reti basate su Active Directory (AD) e ho applicato vari modelli di sicurezza standard basati su best practice, tuttavia non ho mai guardato il LDAP a un livello più profondo e dopo aver letto di recente i problemi LDAP Lion di OSX (< a href="http://www.theregister.co.uk/2011/08/26/mac_osx_lion_security_hole/"> Il registro e Slashdot ), sono piuttosto preoccupato e abbastanza preoccupato.

Ho passato un po 'di tempo a leggerlo, ma continuo a vedere report contrastanti. Esistono informazioni attendibili su quale sia effettivamente il problema?

Inoltre, ho sempre avuto l'impressione che con la sicurezza, si trattasse tutto come caso peggiore / infetto / qualunque ... colpevole fino a prova innocente! Se questo è anche possibile, sicuramente è il server LDAP che è responsabile piuttosto che solo il client?

    
posta wilhil 30.08.2011 - 20:22
fonte

2 risposte

8

Avendo fatto lo stesso errore io stesso un paio di anni fa:

La maggior parte dei protocolli / software restituirà un codice di errore se si tenta di accedere con un nome utente valido (diverso da "anonimo") e una password vuota. Questo è vero anche per la maggior parte dei sistemi che consentono un qualche tipo di uso anonimo senza essere loggati affatto.

Per LDAP, tuttavia, il caso comune è che il server consente accessi con qualsiasi nome utente e una password vuota . L'utente finirà per essere anonimo. Ma il login restituisce un codice di stato che indica il successo.

RFC2829 dice:

An LDAP client MAY also choose to explicitly bind anonymously. A client that wishes to do so MUST choose the simple authentication option in the Bind Request (see section 4.1) and set the password to be of zero length. (This is often done by LDAPv2 clients.) Typically the name is also of zero length.

Quindi, ora immagina che l'accesso non sia fatto direttamente dall'utente. Ma l'utente accede ad un altro software e questo software prende il nome utente e la password e fa un login LDAP dietro le quinte.

Se questo software si fida ciecamente del risultato "successo" del server LDAP senza una gestione caso speciale per password vuote, boom .

Questo software potrebbe persino provare a leggere alcune informazioni sull'utente corrente, come l'indirizzo email. Ma se LDAP è usato come una directory di persone, queste informazioni potrebbero essere accessibili agli utenti anonimi. I server LDAP sono spesso raggiungibili solo dalla rete aziendale e non da Internet.

Ho detto all'inizio, che ho fatto questo errore anch'io. Il nostro software supporta molti diversi tipi di front e backend di autenticazione. LDAP era l'unico sistema efficace di tutti quelli che supportiamo.

Per garantire che ciò non accada mai più, ora respingiamo globalmente le password vuote per tutti i sistemi di autenticazione , a meno che il sistema non sia privo di password come i servizi Single Sign-On e le smart card. Abbiamo aggiunto un caso di test aggiuntivo alla nostra documentazione (verifica casi validi, verifica password errata, verifica password vuota).

    
risposta data 30.08.2011 - 20:53
fonte
0

La richiesta di% BIND% co_de accetta uno dei quattro moduli in base ai dati trasmessi con la richiesta:

  • nome null, password nulla: simple , questo è anche lo stato di autorizzazione di tutte le sessioni LDAP iniziali, ovvero, dove il client LDAP deve ancora emettere una richiesta BIND o una richiesta BIND non è riuscita o è stata respinta. Gli amministratori dei server dovrebbero prendere in considerazione la configurazione per rifiutare i tentativi di autenticazione anonimi e impostare il codice risultato della risposta BIND su anonymous poiché non è stata eseguita alcuna autenticazione.
  • nome non null, password nulla: unwilling to perform . Gli amministratori dei server dovrebbero prendere in considerazione la configurazione per rifiutare i tentativi di autenticazione anonimi e impostare il codice risultato della risposta BIND su unauthenticated poiché non si è verificata l'autenticazione
  • nome non null, password non nulla: unwilling to perform . Gli amministratori del server dovrebbero prendere in considerazione la possibilità di configurare il server per rifiutare tali richieste se tali richieste vengono trasmesse su una connessione non protetta, ovvero una connessione senza riservatezza
  • nome null, password non null: authenticated . In questo caso, il comportamento del server non è definito dagli standard LDAP, pertanto gli amministratori del server dovrebbero considerare la configurazione per rifiutare i tentativi di autenticazione anonimi e impostare il codice risultato della risposta BIND su undefined poiché non è stata eseguita alcuna autenticazione.

vedi anche

LDAP: metodi di autenticazione e meccanismi di sicurezza

    
risposta data 09.07.2012 - 12:50
fonte

Leggi altre domande sui tag