स्क्वीड में सुरक्षित उपयोगकर्ता-प्रमाणीकरण की कहानी

एक बार, दक्षिण अमेरिका में एक सुंदर गर्म आभासी-जंगल था, और एक विद्रूप सर्वर वहां रहता था। यहाँ नेटवर्क की एक अवधारणात्मक छवि है:

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

जब Usersइंटरनेट तक पहुंच का अनुरोध किया जाता है, squidतो उनका नाम और पासपोर्ट पूछें, उनके द्वारा प्रमाणित करें LDAPऔर यदि लैडैप ने उन्हें मंजूरी दी, तो उसने उन्हें अनुमति दी।

जब तक कुछ स्निफ़र्स ने उपयोगकर्ताओं और स्क्वीड [पथ A] के बीच का मार्ग चुरा लिया, तब तक हर कोई खुश था। यह आपदा इसलिए हुई क्योंकि स्क्वीड Basic-Authenticationविधि का इस्तेमाल किया गया था ।

जंगल के लोग समस्या को हल करने में जुट गए। कुछ bunnies NTLMविधि का उपयोग कर की पेशकश की। पसंद सांप Digest-Authenticationजबकि Kerberosपेड़ों से सिफारिश की।

आखिरकार, जंगल के लोगों द्वारा पेश किए गए कई समाधान और सभी भ्रमित थे! सिंह ने स्थिति को समाप्त करने का फैसला किया। उन्होंने समाधान के लिए नियमों को चिल्लाया:

समाधान सुरक्षित हो जाएगा!
अधिकांश ब्राउज़रों और सॉफ्टवेयर्स के लिए समाधान का काम करेंगे (जैसे डाउनलोड सॉफ्टवेयर्स)
समाधान सरल होगा और अन्य विशाल उपतंत्र (जैसे सांबा सर्वर) की आवश्यकता नहीं है
विधि विशेष डोमेन पर निर्भर नहीं होगी। (उदा सक्रिय निर्देशिका)

फिर, एक बंदर द्वारा पेश किया गया एक बहुत ही गूंज-व्यापक-चतुर समाधान, उसे जंगल का नया राजा बनाता है!

क्या आप अनुमान लगा सकते हैं कि समाधान क्या था?

सुझाव: के बीच पथ squidऔर LDAP, शेर के द्वारा संरक्षित है तो समाधान यह सुरक्षित करने के लिए नहीं है।

नोट: अगर कहानी उबाऊ और गन्दा है, तो क्षमा करें, लेकिन यह वास्तविक है! =)

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

अपडेट करें:

मस्सिमो ने समझाया कि Users- squidऔर squid- के बीच की प्रामाणिक विधि LDAPसमान नहीं है। हम उपयोगकर्ताओं से प्रमाणीकरण जानकारी प्राप्त करने के लिए मध्यस्थता विधि का उपयोग कर सकते हैं और प्रमाणित एकत्रित डेटा के लिए मध्यस्थ विधि।

लेकिन एक समस्या है: सभी प्रकार के प्रमाणीकरणकर्ताओं का इनपुट / आउटपुट समान नहीं है। उदाहरण के लिए:

एक Basicप्रमाणीकरणकर्ता को एक पंक्ति में "उपयोगकर्ता नाम पासवर्ड" पढ़ना चाहिए और उत्तर देना चाहिए कि OKक्या उपयोगकर्ता-पास सही है याERR
एक Digestप्रमाणक को पढ़ना चाहिए username:realmऔर एक HA(A1)या एक हेक्स-एनकोडेड का जवाब देना चाहिए ERR।

ग्राहक-स्क्वीड विधि और स्क्वीड-एलएडीपी विधि के बीच कोई सीधा संबंध नहीं है, क्लाइंट से एकत्रित डेटा स्क्वीड-लेडैप भाग में उपयोग की जाने वाली विधि के साथ संगत होना चाहिए। इसलिए, यदि हम उपयोगकर्ता-पक्ष में प्रमाणीकरण विधि बदलते हैं, तो हमें शायद अपने प्रमाणक को भी बदलना चाहिए।

तो समस्या सरल हो जाती है:

पहले स्तर में, मैं (बंदर!) उपयोगकर्ता-पक्ष में एक अच्छी प्रमाणीकरण पद्धति की तलाश कर रहा हूं। आप कौन सी विधि सुझाते हैं जो अधिकांश ब्राउज़रों द्वारा सुरक्षित और समर्थित है ? मैं के बीच उलझन में हूँ NTLM, Kerberosऔर Digest।
जहाँ मुझे एक प्रमाणक मिल सकता है जो चयनित विधि की प्रमाणिक जानकारी का समर्थन करता है और LDAP के माध्यम से प्रमाणित करता है।

— इसहाक
स्रोत

+1, पूरी तरह से भयानक कहानी।

— मासिमो

क्या इस रूप में सभी प्रश्न पूछे जाने चाहिए?

— बार्ट सिल्वरस्ट्रिम

@ बर्ट, शायद नहीं, लेकिन यह वैसे भी भयानक है :-)

— मासिमो

शैली के लिए +1 !!!

— ज्यॉफेक

मैं थोड़ा निराश हूँ कि शेर सही ढंग से वाक्य रचना पर प्रकाश डाला नहीं गया था: 7

— Oskar Duveborn

जवाबों:

Kerberos HTTP प्रमाणीकरण के लिए एक विकल्प नहीं है। NTLM IE के अलावा किसी भी ब्राउज़र में अच्छी तरह से समर्थित नहीं है। जब तक आप इसे HTTPS के पीछे नहीं रखते हैं, जो AFAIK स्क्वीड नहीं कर सकता, बेसिक सुरक्षित नहीं है। इसलिए आप डाइजेस्ट से बचे हैं।

— delimiter69
स्रोत

अब मैं digest_ldap_authLDAP सर्वर के विरुद्ध HTTP डाइजेस्ट प्रमाणीकरण द्वारा उपयोगकर्ताओं को प्रमाणित करता हूं (स्क्वीड के साथ आता है)।

— इसहाक

HTTP तंत्र के माध्यम से Kerberos का समर्थन करताNegotiate है; मैंने इसे Apache और Squid के साथ सफलतापूर्वक उपयोग किया है। SSL स्क्वीड के लिए भी एक विकल्प है, केवल डेबियन लाइसेंस मुद्दों के कारण इसे सक्षम नहीं करता है।

— user1686

एक दिलचस्प विशेषता जो आपको यहां मदद कर सकती है वह यह है कि क्लाइंट स्क्वीड प्रमाणीकरण (पथ ए) के लिए क्लाइंट ब्राउज़र से पूछने के लिए जिस विधि का उपयोग करता है, उसे उस विधि से संबंधित होने की आवश्यकता नहीं है जो वास्तव में उपयोगकर्ता द्वारा दिए गए क्रेडेंशियल्स (पथ बी) को मान्य करने के लिए उपयोग करता है। )। इसका मतलब है, फ़े, कि आप क्लाइंट ब्राउज़रों के साथ स्क्वीड "टॉक" एनटीएलएम बना सकते हैं, लेकिन तब यह लिनक्स के आंतरिक उपयोगकर्ता डेटाबेस (/ etc / passwd) के खिलाफ उपयोगकर्ताओं को बहुत अच्छी तरह से मान्य कर सकता है। नहीं है कोई (पथ एक पर) NTLM का उपयोग कर वास्तव में (पथ बी पर) एक Windows डोमेन के खिलाफ मान्य करने की हासिल कर ली क्रेडेंशियल के लिए की जरूरत है। क्लाइंट-साइड प्रमाणीकरण विधियों और सर्वर-साइड प्रमाणीकरण वाले किसी भी संभावित संयोजन पर भी यही लागू होता है।

आपके मामले में इसका क्या मतलब है, यह है कि आप मूल प्रमाणीकरण के बजाय क्लाइंट ब्राउज़र से NTLM प्रमाणीकरण का अनुरोध करने के लिए स्क्वीड को सुरक्षित रूप से कॉन्फ़िगर कर सकते हैं, और यह किसी भी तरह से आपको वास्तव में सांबा / WinBind / AD / जो भी उपयोग करने की आवश्यकता नहीं होगी।

इसलिए आप क्लाइंट-साइड ऑथेंटिकेशन के लिए जो भी विधि चाहें चुन सकते हैं, फिर भी एलडीएपी सर्वर के खिलाफ उपयोगकर्ताओं को मान्य करते रहें, क्योंकि वे आपके द्वारा चयनित विधि का उपयोग करके अपनी साख प्रदान करते हैं।

जादू होता है, निश्चित रूप से 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

प्रत्येक auth_paramनिर्देश क्लाइंट ब्राउज़र (पथ ए) के लिए एक विशिष्ट प्रमाणीकरण सक्षम करता है , जबकि "प्रोग्राम" भाग सेट करता है कि स्क्वीड वास्तव में उपयोगकर्ताओं द्वारा प्रदान की गई क्रेडेंशियल्स को मान्य करने के लिए क्या उपयोग करेगा। आप यहां जो भी प्रमाणिक कार्यक्रम चाहते हैं उसका उपयोग कर सकते हैं (यहां तक कि एक कस्टम-लिखित भी), जब तक कि वह उपयोगकर्ता आईडी और पासवर्ड प्राप्त कर सकता है और "हां" या "नहीं" का जवाब दे सकता है।

आपको बस अपने LDAP क्वेरी को करने के लिए जो भी प्रमाणिकता आप उपयोग कर रहे हैं, उसे लेने की आवश्यकता है और इसे "Cort_param basic" के बजाय "अब जहां" है, वहां पर मौजूद "schem_param ntlm" या "schem_param डाइजेस्ट" स्टेटमेंट्स में चिपका दें।

अपडेट करें:

आपको अपने प्रमाणक के रूप में squid_ldap_auth का उपयोग जरूर करना चाहिए , लेकिन मैं आपको बिल्कुल नहीं बता सकता कि आपके द्वारा उपयोग किए जा रहे विशिष्ट LDAP सर्वर के बारे में कोई विवरण कैसे दिया जाए ।

क्लाइंट-साइड प्रमाणीकरण के संबंध में, कोई भी अच्छा होना चाहिए; मैं NTLM से काफी खुश हूं, और आजकल ज्यादातर ब्राउज़र इसका समर्थन करते हैं।

इस तरह के एक विन्यास स्क्विड में इस तरह दिखेगा ।conf:

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

यह NTLM का उपयोग करके उपयोगकर्ता क्रेडेंशियल्स (पथ ए) के लिए पूछेगा, फिर उन्हें एक एलडीएपी सर्वर (पथ बी) के खिलाफ मान्य करें; लेकिन वे "पैरामीटर" आपके LDAP कार्यान्वयन और कॉन्फ़िगरेशन पर सख्ती से निर्भर करते हैं।

यह भी मदद कर सकता है: http://www.cyberciti.biz/tips/howto-configure-squid-ldap-authentication.html ।

— मास्सिमो
स्रोत

सच लगता है! तो आप किस विधि की पेशकश करते हैं? NTLM? Kerberos? उनमें से कौन सबसे ब्राउज़रों पर समर्थित है और पहले से ही एक 'प्रमाणक' है जो ldap का समर्थन करता है?

— इसहाक

@ इस्साक, कृपया बेहतर पढ़ें :-) विधि और प्रमाणक कार्यक्रम के बीच कोई संबंध नहीं है , इसलिए, जब तक आपके पास LDAP का समर्थन करने वाला एक प्रामाणिक कार्यक्रम है, तब तक आप अपनी पसंद के किसी भी ग्राहक प्रमाणीकरण विधि के साथ इसका उपयोग कर सकते हैं। और मैं इस धारणा के तहत था कि आप पहले से ही इसे बुनियादी प्रमाणीकरण के साथ उपयोग कर रहे हैं ... क्या ऐसा नहीं है? क्या आप अपने स्क्वीड.कॉनफ के रिलेटिव हिस्से को पोस्ट कर सकते हैं?

— मासिमो

धन्यवाद। मैंने इसे प्रश्न में अद्यतन अनुभाग में समझाया । मुझे आशा है कि मैं गलत नहीं हूँ! : - /

— इसहाक

मुझे पता है कि यह एक पुरानी पोस्ट है, लेकिन, auth_param ntlm program /usr/lib/squid/squid_ldap_auth <parameters>मेरे लिए काम नहीं करता है, स्क्वीड क्रैश होता है और हर बार जब कोई उपयोगकर्ता प्रमाणित करने की कोशिश करता है तो उसे पुनः आरंभ किया जाता है। हो सकता है कि गलत का उपयोग करने के कारण parameters, लेकिन मैं एक ही पैरामीटर का उपयोग कर रहा हूं basicऔर ठीक काम करता हूं । कोई विचार?

— कास्त्रो रॉय