Kalamarda güvenli kullanıcı kimlik doğrulamasının hikayesi

bir zamanlar, güney amerika'da güzel bir sıcak sanal orman vardı ve orada bir kalamar sunucusu yaşadı. İşte ağın algısal bir görüntüsü:

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

Ne zaman Usersinternete erişim iste, squidkendi adını ve pasaportun sormak, onları doğrulamak LDAPve ldap onları onaylandığı takdirde, o zaman onları vermiştir.

Bazı koklayıcılar kullanıcılar ve kalamar [A yolu] arasındaki pasaportu çalıncaya kadar herkes mutluydu. Bu felaket, kalamar Basic-Authenticationyöntemi kullandığı için oldu .

Orman halkı sorunu çözmek için bir araya geldi. Bazı tavşanlar NTLMyöntemi kullanarak sundu . Yılanlar ağaçlar tarafından tavsiye Digest-Authenticationedilirken tercih Kerberosedilir.

Sonuçta, orman insanlar tarafından sunulan birçok çözüm ve hepsi karışıktı! Aslan durumu sonlandırmaya karar verdi. Çözüm kurallarını bağırdı:

• Çözüm güvenli olacak mı?
• Çoğu tarayıcı ve yazılım için çözüm çalışmasını sağlar (ör. Yazılımları indir)
• Çözüm basit olmalı ve başka büyük alt sistemlere (Samba sunucusu gibi) gerek yok
• Yöntem özel alan adına bağlı olmayacak. (ör. Active Directory)

Sonra, bir maymun tarafından sunulan çok resonable-kapsamlı-akıllı bir çözüm, onu ormanın yeni kralı yapıyor!

çözümün ne olduğunu tahmin edebilir misin?

İpucu: Aslan arasındaki squidve LDAPaslan tarafından korunan yol , böylece çözüm onu ​​korumak zorunda değildir.

Not: Hikaye sıkıcı ve dağınıksa üzgünüm, ancak çoğu gerçek! =)

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

Güncelleme:

Massimo , Users- squidve squid- arasındaki kimlik doğrulama yönteminin LDAPaynı olması gerekmediğini açıkladı. kullanıcılardan kimlik doğrulama bilgilerini almak için arbitary yöntemini ve doğrulanmış toplanan verilere arbitary yöntemini kullanabiliriz.

Ancak bir sorun var: her tür doğrulayıcı giriş / çıkışı aynı değildir. Örneğin:

• bir Basicdoğrulayıcı bir satırda "kullanıcı adı şifresi" çiftini okumalı ve kullanıcı şifresi OKdoğru ise veyaERR
• bir Digestkimlik doğrulayıcı bir 'i okumalı username:realmve onaltılı kodlu HA(A1)veya bir' yi yanıtlamalıdır ERR.

İstemci-kalamar yöntemi ile kalamar-ldap yöntemi arasında doğrudan bir ilişki olmadığından, istemciden toplanan veriler kalamar-ldap bölümünde kullanılan yöntemle uyumlu olmalıdır. Bu nedenle, kullanıcı tarafında kimlik doğrulama yöntemini değiştirirsek, belki de kimlik doğrulayıcımızı da değiştirmeliyiz.

Böylece sorun basitleşir:

1. İlk düzeyde, ben (maymun!) Kullanıcı tarafında iyi bir kimlik doğrulama yöntemi arıyorum. Hangi yöntemlerin hangilerinin güvenli ve çoğu tarayıcı tarafından desteklendiğini önerirsiniz ? i arasına karıştı içindeyim NTLM, Kerberosve Digest.

2. Burada, seçilen yöntemin kimlik bilgilerini destekleyen ve LDAP üzerinden kimlik doğrulaması yapan bir kimlik doğrulayıcı bulabilirim.

Kerberos HTTP kimlik doğrulaması için bir seçenek değildir. NTLM, IE dışındaki tarayıcılarda iyi desteklenmez. AFAIK kalamarının yapamayacağı HTTPS'nin arkasına koymadığınız sürece Basic güvenli değildir. Yani Digest ile kaldın.

Burada size yardımcı olabilecek ilginç bir özellik, Squid'in istemci tarayıcıdan kimlik doğrulamasını istemek için kullandığı yöntemin (A yolu), kullanıcının sağladığı kimlik bilgilerini gerçekten doğrulamak için kullandığı yöntemle hiçbir şekilde ilgili olması gerekmemesidir (B yolu) ). Bu, fe, Squid'in istemci tarayıcıları ile "konuşma" NTLM yapabileceğiniz anlamına gelir, ancak daha sonra kullanıcıları Linux'un iç kullanıcı veritabanına (/ etc / passwd) göre çok iyi doğrulayabilir. Orada hiçbir aslında (yol B) bir Windows etki karşı doğrulanması (yol A) NTLM kullanılarak edinilen kimlik bilgileri gerekir. Aynı durum, istemci tarafı kimlik doğrulama yöntemleri ile sunucu tarafı kimlik doğrulama yöntemlerinin olası tüm kombinasyonları için de geçerlidir.

Sizin durumunuzda bunun anlamı, Squid'i temel kimlik doğrulaması yerine istemci tarayıcılarından NTLM kimlik doğrulaması isteyecek şekilde güvenli bir şekilde yapılandırabilmenizdir ve bu hiçbir şekilde Samba / WinBind / AD / herhangi bir şekilde kullanmanızı gerektirmez.

Böylece, istemci tarafı kimlik doğrulaması için istediğiniz yöntemi seçebilirsiniz, ancak seçtiğiniz yöntemi kullanarak kullanıcıları kimlik bilgilerini girdikten sonra bir LDAP sunucusuna göre doğrulamaya devam edin.

Sihir elbette şu şekilde gerçekleşir 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

Her auth_paramyönerge, istemci tarayıcıları (A yolu) için özel bir kimlik doğrulaması sağlarken, "program" bölümü Squid'in kullanıcılar tarafından sağlanan kimlik bilgilerini doğrulamak için gerçekte ne kullanacağını belirler. Kullanıcı kimliği ve parola alıp "evet" veya "hayır" yanıtını alabildiği sürece, burada istediğiniz herhangi bir kimlik doğrulama programını (özel olarak yazılmış bir program bile) kullanabilirsiniz.

LDAP sorgunuzu yapmak için kullandığınız kimlik doğrulayıcıyı almanız ve şu anda "auth_param basic" yerine "auth_param ntlm" veya "auth_param digest" ifadelerine yapıştırmanız yeterlidir.

Güncelleme:

Kimlik doğrulayıcınız olarak kesinlikle squid_ldap_auth kullanmalısınız , ancak kullandığınız LDAP sunucusu hakkında herhangi bir ayrıntı olmadan tam olarak nasıl olduğunu söyleyemem .

İstemci tarafı kimlik doğrulaması ile ilgili olarak, herhangi biri iyi olmalıdır; NTLM'den oldukça memnunum ve çoğu tarayıcı bugünlerde destekliyor.

Böyle bir yapılandırma squid.conf dosyasında şöyle görünür:

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

Bu, NTLM kullanarak kullanıcı kimlik bilgilerini (A yolu) isteyecek, daha sonra bunları bir LDAP sunucusuna (B yolu) doğrulayacaktır; ancak bu "parametreler" kesinlikle LDAP uygulamanıza ve yapılandırmanıza bağlıdır.

Bu da yardımcı olabilir: http://www.cyberciti.biz/tips/howto-configure-squid-ldap-authentication.html .