เรื่องราวของการรับรองความถูกต้องของผู้ใช้ที่ปลอดภัยในปลาหมึก


17

กาลครั้งหนึ่งนานมาแล้วมีป่าเสมือนอันอบอุ่นในอเมริกาใต้และเซิร์ฟเวอร์ปลาหมึกอาศัยอยู่ที่นั่น นี่คือภาพการรับรู้ของเครือข่าย:

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

เมื่อUsersคำขอเข้าถึงอินเทอร์เน็ตsquidให้ถามชื่อและหนังสือเดินทางของพวกเขารับรองความถูกต้องโดยLDAPและหาก ldap อนุมัติพวกเขาแล้วเขาก็อนุญาต

ทุกคนมีความสุขจนกระทั่งนักดมกลิ่นบางคนขโมยหนังสือเดินทางในเส้นทางระหว่างผู้ใช้กับปลาหมึก [เส้นทาง A] ภัยพิบัติครั้งนี้เกิดขึ้นเพราะปลาหมึกใช้Basic-Authenticationวิธีการ

คนในป่ารวมตัวกันเพื่อแก้ปัญหา กระต่ายบางตัวเสนอโดยใช้NTLMวิธีการ งูที่ต้องการDigest-Authenticationในขณะที่Kerberosแนะนำโดยต้นไม้

ท้ายที่สุดแล้วคำตอบมากมายที่นำเสนอโดยผู้คนในป่าและทั้งหมดก็สับสน! The Lion ตัดสินใจที่จะยุติสถานการณ์ เขาตะโกนกฎสำหรับการแก้ปัญหา:

  • โซลูชันจะปลอดภัยหรือไม่!
  • โซลูชันจะใช้งานได้กับเบราว์เซอร์และซอฟต์แวร์ส่วนใหญ่ (เช่นซอฟต์แวร์ดาวน์โหลด)
  • จะแก้ปัญหาได้ง่ายและไม่ต้องการระบบย่อยขนาดใหญ่อื่น ๆ (เช่นเซิร์ฟเวอร์ Samba)
  • วิธีนี้จะไม่ขึ้นอยู่กับโดเมนพิเศษ (เช่น Active Directory)

จากนั้นวิธีแก้ปัญหาที่ชาญฉลาดและครอบคลุมเป็นอย่างมากที่นำเสนอโดยลิงทำให้เขากลายเป็นราชาองค์ใหม่แห่งป่า!

คุณเดาได้ไหมว่าทางออกคืออะไร

เคล็ดลับ: เส้นทางระหว่างsquidและLDAPได้รับการคุ้มครองโดยสิงโตดังนั้นวิธีการแก้ปัญหาจึงไม่ปลอดภัย

หมายเหตุ:ขออภัยถ้าเรื่องราวน่าเบื่อและยุ่ง แต่ส่วนใหญ่เป็นเรื่องจริง! =)

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

ปรับปรุง:

Massimoอธิบายว่าวิธีการรับรองความถูกต้องระหว่างUsers- squidและsquid- LDAPไม่จำเป็นต้องเหมือนกัน เราสามารถใช้วิธีการทาง Arbitary เพื่อรับข้อมูลการตรวจสอบความถูกต้องจากผู้ใช้และวิธี Arbitary ไปยังข้อมูลที่ได้รับการตรวจสอบความถูกต้อง

แต่มีปัญหา: อินพุต / เอาต์พุตของตัวตรวจสอบสิทธิ์ทุกประเภทไม่เหมือนกัน ตัวอย่างเช่น:

  • ตัวBasicตรวจสอบความถูกต้องควรอ่าน "รหัสผ่านชื่อผู้ใช้" จับคู่ในบรรทัดและตอบกลับOKว่าERR
  • DigestAuthenticator ควรอ่านusername:realmและตอบกลับฐานสิบหกของการเข้ารหัสหรือHA(A1)ERR

แม้ว่าจะไม่มีความสัมพันธ์โดยตรงระหว่างวิธี client-squid และวิธี squid-ldap แต่ข้อมูลที่รวบรวมจากไคลเอนต์จะต้องเข้ากันได้กับวิธีที่ใช้ในส่วน squid-ldap ดังนั้นหากเราเปลี่ยนวิธีการตรวจสอบสิทธิ์ในด้านผู้ใช้เราก็ควรเปลี่ยนผู้ตรวจสอบสิทธิ์ด้วย

ดังนั้นปัญหาทำให้ง่ายขึ้นใน:

  1. ในระดับแรกฉัน (ลิง!) กำลังมองหาวิธีการรับรองความถูกต้องที่ดีในด้านผู้ใช้ คุณแนะนำวิธีการใดที่เบราว์เซอร์ส่วนใหญ่ปลอดภัยและสนับสนุน ? ผมอยู่ในความสับสนระหว่างNTLM, และKerberosDigest

  2. ที่ฉันสามารถหาตัวตรวจสอบความถูกต้องซึ่งรองรับข้อมูลหนังสือรับรองของวิธีการที่เลือกและรับรองความถูกต้องผ่าน LDAP


2
+1 การเล่าเรื่องที่ยอดเยี่ยมโดยสิ้นเชิง
Massimo

ควรถามคำถามทั้งหมดในแบบฟอร์มนี้หรือไม่
Bart Silverstrim

@Bart อาจจะไม่ แต่มันก็น่ากลัวอยู่ดี :-)
Massimo

+1 สำหรับสไตล์ !!!
geoffc

4
ฉันผิดหวังเล็กน้อยที่สิงโตไม่ได้เน้นไวยากรณ์อย่างถูกต้อง: 7
Oskar Duveborn

คำตอบ:


1

Kerberos ไม่ใช่ตัวเลือกสำหรับการตรวจสอบสิทธิ์ HTTP NTLM ไม่รองรับเบราว์เซอร์อื่น ๆ นอกจาก IE พื้นฐานไม่ปลอดภัยเว้นแต่คุณจะวางไว้ด้านหลัง HTTPS ซึ่งปลาหมึก AFAIK ไม่สามารถทำได้ ดังนั้นคุณจะเหลือ Digest


ตอนนี้ฉันกำลังตรวจสอบผู้ใช้โดย HTTP Digest Authentication ดำเนินการโดยdigest_ldap_auth(มาพร้อมกับ squid) กับเซิร์ฟเวอร์ LDAP
ไอแซค

HTTP ไม่สนับสนุน Kerberos ผ่านNegotiateกลไก; ฉันใช้มันกับ Apache และ Squid สำเร็จแล้ว SSL เป็นตัวเลือกสำหรับ Squid, Debian เท่านั้นที่ไม่สามารถเปิดใช้งานได้เนื่องจากปัญหาด้านลิขสิทธิ์
user1686

4

หนึ่งในคุณสมบัติที่น่าสนใจที่สามารถช่วยคุณได้ที่นี่คือวิธีการที่ Squid ใช้เพื่อขอให้เบราว์เซอร์ไคลเอนต์สำหรับการรับรองความถูกต้อง (เส้นทาง A) ไม่จำเป็นต้องเกี่ยวข้องกับวิธีที่ใช้ในการตรวจสอบความถูกต้องของข้อมูล ) ซึ่งหมายความว่าคุณสามารถสร้าง Squid "พูดคุย" NTLM กับเบราว์เซอร์ไคลเอนต์ได้ แต่ก็สามารถตรวจสอบผู้ใช้กับฐานข้อมูลผู้ใช้ภายในของ Linux (/ etc / passwd) ได้เป็นอย่างดี นอกจากนี้ยังไม่มีความจำเป็นในการใช้ข้อมูลประจำตัวที่ได้มา NTLM (บนเส้นทาง A) จะจริงจะตรวจสอบกับโดเมนที่ใช้ Windows (บนเส้นทาง B) เช่นเดียวกับการรวมกันที่เป็นไปได้ของวิธีการรับรองความถูกต้องฝั่งไคลเอ็นต์และวิธีการพิสูจน์ตัวตนฝั่งเซิร์ฟเวอร์

สิ่งนี้หมายความว่าในกรณีของคุณคือคุณสามารถกำหนดค่า Squid เพื่อขอการรับรองความถูกต้อง NTLM จากเบราว์เซอร์ไคลเอนต์แทนการรับรองความถูกต้องขั้นพื้นฐานและสิ่งนี้จะไม่ทำให้คุณต้องใช้ Samba / WinBind / AD / อะไรก็ตาม

ดังนั้นคุณสามารถเลือกวิธีใดก็ได้ที่คุณต้องการสำหรับการรับรองความถูกต้องฝั่งไคลเอ็นต์ แต่ยังคงทำการตรวจสอบผู้ใช้กับเซิร์ฟเวอร์ LDAP หลังจากที่พวกเขาให้ข้อมูลประจำตัวของพวกเขาโดยใช้วิธีที่คุณเลือก

ความมหัศจรรย์เกิดขึ้นแน่นอนใน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คำสั่งเปิดใช้งานการรับรองความถูกต้องเฉพาะสำหรับเบราว์เซอร์ไคลเอนต์ (เส้นทาง A) ในขณะที่ส่วน "โปรแกรม" ตั้งค่าว่า Squid จะใช้จริงในการตรวจสอบข้อมูลประจำตัวที่ให้ไว้โดยผู้ใช้ คุณสามารถใช้โปรแกรมรับรองความถูกต้องแบบใดก็ได้ที่คุณต้องการที่นี่ (แม้เป็นแบบกำหนดเองที่เขียน) ตราบใดที่สามารถรับรหัสผู้ใช้และรหัสผ่านและตอบคำถาม "ใช่" หรือ "ไม่"

คุณเพียงแค่ต้องใช้เครื่องรับรองความถูกต้องใด ๆ ที่คุณใช้ในการทำแบบสอบถาม LDAP ของคุณและติดไว้ในคำสั่ง "auth_param ntlm" หรือ "auth_param แยกย่อย" แทนคำว่า "auth_param พื้นฐาน" ซึ่งตอนนี้อยู่ในขณะนี้


ปรับปรุง:

คุณควรใช้squid_ldap_authเป็นผู้ตรวจสอบสิทธิ์ของคุณแน่นอน แต่ฉันไม่สามารถบอกคุณได้อย่างชัดเจนว่าไม่มีรายละเอียดใดเกี่ยวกับเซิร์ฟเวอร์ LDAP ที่คุณใช้งานอยู่

เกี่ยวกับการรับรองความถูกต้องฝั่งไคลเอ็นต์บุคคลใดคนหนึ่งควรจะดี ฉันมีความสุขมากกับ NTLM และเบราว์เซอร์ส่วนใหญ่รองรับในปัจจุบัน

การกำหนดค่าดังกล่าวจะมีลักษณะเช่นนี้ใน squid.conf:

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

สิ่งนี้จะขอข้อมูลรับรองผู้ใช้ (เส้นทาง A) โดยใช้ NTLM จากนั้นตรวจสอบความถูกต้องกับเซิร์ฟเวอร์ LDAP (เส้นทาง B) แต่ "พารามิเตอร์" เหล่านั้นขึ้นอยู่กับการใช้และการกำหนดค่า LDAP ของคุณอย่างเคร่งครัด

นี้จะช่วยให้เกินไป: http://www.cyberciti.biz/tips/howto-configure-squid-ldap-authentication.html


ดูเหมือนจริง! แล้วคุณเสนอวิธีการแบบใด NTLM? Kerberos? เบราว์เซอร์ใดที่รองรับเบราเซอร์ส่วนใหญ่และมี 'authenticator' ที่รองรับ ldap อยู่แล้ว?
Isaac

@Isaac โปรดอ่านให้ดีขึ้น :-) ไม่มีความสัมพันธ์ระหว่างวิธีการและโปรแกรมการรับรองความถูกต้องดังนั้นตราบใดที่คุณมีโปรแกรมการรับรองความถูกต้องที่สนับสนุน LDAP คุณสามารถใช้วิธีนี้กับวิธีการตรวจสอบสิทธิ์ลูกค้าที่คุณต้องการ และฉันอยู่ภายใต้ความประทับใจที่คุณได้ใช้กับการรับรองความถูกต้องพื้นฐานแล้ว ... คุณสามารถโพสต์ส่วนที่เกี่ยวข้องของ squid.conf ของคุณได้หรือไม่?
Massimo

ขอบคุณ ฉันอธิบายสิ่งนี้ในหัวข้ออัพเดตในคำถาม ฉันหวังว่าฉันไม่ผิด! : - /
Isaac

ฉันรู้ว่านี่เป็นโพสต์เก่า แต่การใช้auth_param ntlm program /usr/lib/squid/squid_ldap_auth <parameters>ไม่ได้ผลสำหรับฉันปลาหมึกตกและเริ่มต้นใหม่ทุกครั้งที่ผู้ใช้พยายามพิสูจน์ตัวตน อาจเป็นเพราะการใช้ผิดparametersแต่ฉันใช้พารามิเตอร์เดียวกันกับbasicและทำงาน ok ความคิดใด ๆ
Castro Roy
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.