La storia dell'autenticazione sicura dell'utente in calamari

c'era una volta una bella giungla virtuale calda in sud america e un server di calamari viveva lì. ecco un'immagine percettiva della rete:

                 <the Internet>
                        | 
                        | 
           A            |          B
Users <---------> [squid-Server] <---> [LDAP-Server] 

Quando la Usersrichiesta di accesso a Internet, squidchiedi il loro nome e passaporto, li autentica LDAPe se ldap li ha approvati, li ha concessi.

Tutti erano felici fino a quando alcuni sniffer non hanno rubato il passaporto nel percorso tra utenti e calamari [percorso A]. Questo disastro è avvenuto perché il calamaro ha usato il Basic-Authenticationmetodo.

Le persone della giungla si sono radunate per risolvere il problema. Alcuni coniglietti hanno offerto l'uso NTLMdel metodo. I serpenti preferito Digest-Authenticationmentre Kerberosconsigliato da alberi.

Dopotutto, molte soluzioni offerte dalle persone della giungla e tutto era confuso! Il leone ha deciso di porre fine alla situazione. Ha gridato le regole per le soluzioni:

• La soluzione sarà sicura!
• La soluzione funzionerà per la maggior parte dei browser e dei software (ad es. Download di software)
• La soluzione sarà semplice e non avrà bisogno di altri enormi sottosistemi (come il server Samba)
• Il metodo non dipenderà dal dominio speciale. (ad es. Active Directory)

Quindi, una soluzione molto comprensibile, completa e intelligente offerta da una scimmia, che lo rende il nuovo re della giungla!

puoi indovinare qual era la soluzione?

Suggerimento: il percorso tra squide LDAPè protetto dal leone, quindi la soluzione non deve fissarlo.

Nota: scusate se la storia è noiosa e disordinata, ma la maggior parte è reale! =)

               /~\/~\/~\
            /\~/~\/~\/~\/~\
          ((/~\/~\/~\/~\/~\))
        (/~\/~\/~\/~\/~\/~\/~\)
       (////     ~   ~     \\\\)
       (\\\\(   (0) (0)   )////)
       (\\\\(   __\-/__   )////)
        (\\\(     /-\     )///)
         (\\\(  (""""")  )///)
          (\\\(  \^^^/  )///)
           (\\\(       )///)
             (\/~\/~\/~\/)         **
               (\/~\/~\/)        *####*
                |     |           ****
               /| | | |\            \\
            _/  | | | | \_ _________//   Thanks!
           (,,)(,,)_(,,)(,,)--------'

Aggiornare:

Massimo ha spiegato che il metodo di autenticazione tra Users- squide squid- LDAPnon deve essere lo stesso. possiamo usare il metodo arbitrario per ottenere informazioni di autenticazione dagli utenti e il metodo arbitrario per i dati raccolti autenticati.

Ma c'è un problema: l'input / output di tutti i tipi di autenticatori non è lo stesso. Per esempio:

• un Basicautenticatore dovrebbe leggere una coppia di "nome utente password" in una riga e rispondere a OKse il pass utente è corretto oERR
• un Digestautenticatore dovrebbe leggere a username:realme rispondere a un codice esadecimale di HA(A1)o a ERR.

Sebbene non vi sia alcuna relazione diretta tra il metodo client-squid e il metodo squid-ldap, i dati raccolti dal client devono essere compatibili con il metodo utilizzato nella parte squid-ldap. Pertanto, se cambiamo il metodo di autenticazione dal lato degli utenti, dovremmo forse cambiare anche il nostro autenticatore.

Quindi il problema si semplifica per:

1. Nel primo livello, io (la scimmia!) Sto cercando un buon metodo di autenticazione sul lato utente. Quale metodo consigliate quale è sicuro e supportato dalla maggior parte dei browser ? sono confuso tra NTLM, Kerberose Digest.

2. Dove posso trovare un autenticatore che supporta le informazioni sulle credenziali del metodo selezionato e esegue l'autenticazione tramite LDAP.

Kerberos non è un'opzione per l'autenticazione HTTP. NTLM non è ben supportato in nessun browser diverso da IE. Basic non è sicuro a meno che non lo metti dietro HTTPS che il calamaro AFAIK non può fare. Quindi rimani con Digest.

Una caratteristica interessante che potrebbe aiutarti qui è che il metodo utilizzato da Squid per richiedere l'autenticazione al browser client (percorso A) non deve assolutamente essere correlato al metodo utilizzato per validare effettivamente le credenziali fornite dall'utente (percorso B ). Ciò significa, ad esempio, che è possibile far squillare NTLM di Squid con i browser client, ma in questo modo è possibile validare gli utenti con il database utenti interno di Linux (/ etc / passwd). Non v'è alcuna necessità di credenziali acquisite tramite NTLM (sul percorso A) ad essere in realtà convalidato contro un dominio Windows (sul percorso B). Lo stesso vale per qualsiasi possibile combinazione di metodi di autenticazione lato client e metodi di autenticazione lato server.

Ciò che significa nel tuo caso è che puoi configurare in modo sicuro Squid per richiedere l'autenticazione NTLM dai browser client anziché l'autenticazione di base, e ciò non richiederà in alcun modo di utilizzare effettivamente Samba / WinBind / AD / qualunque cosa.

Quindi puoi scegliere qualsiasi metodo desideri per l'autenticazione lato client, continuando comunque a convalidare gli utenti su un server LDAP dopo aver fornito le loro credenziali utilizzando il metodo selezionato.

La magia accade, ovviamente, in squid.conf:

#auth_param negotiate program <uncomment and complete this line to activate>
#auth_param negotiate children 5
#auth_param negotiate keep_alive on
#auth_param ntlm program <uncomment and complete this line to activate>
#auth_param ntlm children 5
#auth_param ntlm keep_alive on
#auth_param digest program <uncomment and complete this line>
#auth_param digest children 5
#auth_param digest realm Squid proxy-caching web server
#auth_param digest nonce_garbage_interval 5 minutes
#auth_param digest nonce_max_duration 30 minutes
#auth_param digest nonce_max_count 50
#auth_param basic program <uncomment and complete this line>
#auth_param basic children 5
#auth_param basic realm Squid proxy-caching web server
#auth_param basic credentialsttl 2 hours
#auth_param basic casesensitive off

Ogni auth_paramdirettiva abilita un'autenticazione specifica per i browser client (percorso A), mentre la parte "programma" imposta ciò che Squid utilizzerà effettivamente per convalidare le credenziali fornite dagli utenti. È possibile utilizzare qualsiasi programma di autenticazione desiderato qui (anche uno personalizzato), purché possa ricevere un ID utente e una password e rispondere "sì" o "no".

Devi solo prendere qualsiasi autenticatore che stai utilizzando per eseguire la tua query LDAP e incollarla nelle istruzioni "auth_param ntlm" o "digest digest_ autham", anziché in "auth_param basic" dove si trova ora.

Aggiornare:

Dovresti assolutamente usare squid_ldap_auth come autenticatore, ma non posso dirti esattamente come senza alcun dettaglio sul server LDAP specifico che stai utilizzando.

Per quanto riguarda l'autenticazione lato client, ognuno dovrebbe essere buono; Sono abbastanza contento di NTLM e la maggior parte dei browser lo supporta al giorno d'oggi.

Una simile configurazione sarebbe simile a questa in squid.conf:

auth_param ntlm program /usr/lib/squid/squid_ldap_auth <parameters>

Ciò richiederà le credenziali dell'utente (percorso A) utilizzando NTLM, quindi le convaliderà su un server LDAP (percorso B); ma questi "parametri" dipendono strettamente dalla tua implementazione e configurazione LDAP.

Anche questo potrebbe aiutare: http://www.cyberciti.biz/tips/howto-configure-squid-ldap-authentication.html .