Kisah otentikasi pengguna yang aman dalam squid

suatu ketika, ada hutan virtual yang indah dan hangat di Amerika Selatan, dan server cumi-cumi tinggal di sana. berikut ini adalah gambar persepsi jaringan:

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

Ketika Userspermintaan akses ke Internet, squidtanyakan nama dan paspor mereka, otentikasi mereka dengan LDAPdan jika ldap menyetujuinya, maka dia memberikan mereka.

Semua orang senang sampai beberapa sniffer mencuri paspor di jalur antara pengguna dan squid [jalur A]. Bencana ini terjadi karena cumi menggunakan Basic-Authenticationmetode.

Orang-orang hutan berkumpul untuk memecahkan masalah. Beberapa kelinci menawarkan penggunaan NTLMmetode ini. Ular lebih disukai Digest-Authenticationsaat Kerberosdirekomendasikan oleh pohon.

Lagi pula, banyak solusi yang ditawarkan oleh orang-orang hutan dan semuanya bingung! Sang Singa memutuskan untuk mengakhiri situasi. Dia meneriakkan aturan untuk solusi:

• Haruskah solusinya aman!
• Solusi akan berfungsi untuk sebagian besar browser dan perangkat lunak (mis. Perangkat lunak unduhan)
• Haruskah solusinya sederhana dan tidak perlu subsistem besar lainnya (seperti server Samba)
• Tidak akan metode tergantung pada domain khusus. (mis. Direktori Aktif)

Kemudian, solusi yang sangat resonable-komprehensif-pintar yang ditawarkan oleh monyet, menjadikannya raja hutan yang baru!

dapatkah Anda menebak apa solusinya?

Tip: Jalur antara squiddan LDAPdilindungi oleh singa, sehingga solusinya tidak harus mengamankannya.

Catatan: maaf jika ceritanya membosankan dan berantakan, tetapi sebagian besar itu nyata! =)

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

Memperbarui:

Massimo menjelaskan bahwa metode otentikasi antara Users- squiddan squid- LDAPtidak harus sama. kita dapat menggunakan metode arbiter untuk mendapatkan informasi otentikasi dari pengguna dan metode arbiter untuk mengautentikasi data yang dikumpulkan.

Tetapi ada masalah: input / output dari semua jenis autentikator tidak sama. Sebagai contoh:

• sebuah Basicauthenticator harus membaca "username password" pasangan dalam garis dan membalas sebuah OKjika pengguna-pass benar atauERR
• sebuah Digestauthenticator harus membaca username:realmdan membalas hex-encoded dari HA(A1)atau ERR.

Meskipun tidak ada hubungan langsung antara metode client-squid dan metode squid-ldap, data yang dikumpulkan dari klien harus kompatibel dengan metode yang digunakan di bagian squid-ldap. Karena itu, jika kita mengubah metode otentikasi di sisi pengguna, kita mungkin juga harus mengubah autentikator.

Jadi masalahnya disederhanakan menjadi:

1. Di tingkat pertama, saya (monyet!) Sedang mencari metode otentikasi yang baik di sisi pengguna. Metode mana yang Anda rekomendasikan yang aman dan didukung oleh sebagian besar browser ? Saya bingung antara NTLM, Kerberosdan Digest.

2. Di mana saya dapat menemukan autentikator yang mendukung informasi kredensial dari metode yang dipilih dan mengautentikasi melalui LDAP.

Kerberos bukan opsi untuk otentikasi HTTP. NTLM tidak didukung dengan baik di peramban apa pun selain IE. Basic tidak aman kecuali Anda meletakkannya di belakang HTTPS yang tidak dapat dilakukan oleh squid AFAIK. Jadi Anda pergi dengan Digest.

Salah satu fitur menarik yang dapat membantu Anda di sini adalah bahwa metode yang digunakan Squid untuk meminta otentikasi klien (jalur A) sama sekali tidak perlu dikaitkan dengan metode yang digunakannya untuk benar-benar memvalidasi kredensial yang diberikan oleh pengguna (jalur B ). Ini berarti, fe, bahwa Anda dapat membuat Squid "berbicara" NTLM dengan browser klien, tetapi kemudian itu bisa sangat memvalidasi pengguna terhadap basis data pengguna internal Linux (/ etc / passwd). Tidak ada kebutuhan untuk kredensial yang diperoleh menggunakan NTLM (di jalan A) untuk benar-benar divalidasi terhadap domain Windows (pada jalur B). Hal yang sama berlaku untuk setiap kemungkinan kombinasi metode otentikasi sisi klien dan yang otentikasi sisi server.

Apa artinya ini dalam kasus Anda, adalah bahwa Anda dapat dengan aman mengkonfigurasi Squid untuk meminta otentikasi NTLM dari browser klien, dan bukannya otentikasi dasar, dan ini tidak akan mengharuskan Anda untuk benar-benar menggunakan Samba / WinBind / AD / apa pun.

Jadi Anda dapat memilih metode apa pun yang Anda inginkan untuk otentikasi sisi klien, namun tetap tetap memvalidasi pengguna terhadap server LDAP setelah mereka memberikan kredensial mereka menggunakan metode yang Anda pilih.

Keajaiban terjadi, tentu saja, di 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

Setiap auth_paramarahan memungkinkan otentikasi spesifik untuk browser klien (jalur A), sedangkan bagian "program" menentukan apa yang sebenarnya akan digunakan Squid untuk memvalidasi kredensial yang diberikan oleh pengguna. Anda dapat menggunakan program autentikator apa pun yang Anda inginkan di sini (bahkan yang ditulis khusus), asalkan dapat menerima id pengguna dan kata sandi dan menjawab "ya" atau "tidak".

Anda hanya perlu mengambil autentikator apa pun yang Anda gunakan untuk melakukan permintaan LDAP Anda dan memasukkannya ke dalam pernyataan "auth_param ntlm" atau "auth_param digest", alih-alih dengan "auth_param basic" yang ada sekarang.

Memperbarui:

Anda pasti harus menggunakan squid_ldap_auth sebagai autentikator Anda, tetapi saya tidak bisa memberi tahu Anda secara persis bagaimana tanpa detail tentang server LDAP tertentu yang Anda gunakan.

Mengenai otentikasi sisi klien, siapa pun harus baik; Saya cukup senang dengan NTLM, dan sebagian besar browser mendukungnya saat ini.

Konfigurasi seperti itu akan terlihat seperti ini di squid.conf:

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

Ini akan meminta kredensial pengguna (jalur A) menggunakan NTLM, kemudian memvalidasinya terhadap server LDAP (jalur B); tetapi "parameter" tersebut sangat tergantung pada implementasi dan konfigurasi LDAP Anda.

Ini juga bisa membantu: http://www.cyberciti.biz/tips/howto-configure-squid-ldap-authentication.html .