☰

魷魚中安全用戶身份驗證的故事

tag-icon • tag-icon security authentication ldap squid kerberos
魷魚中安全用戶身份驗證的故事

從前，南美洲有一個美麗溫暖的虛擬叢林，那裡住著一台魷魚伺服器。這是網路的感知圖像：

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

當Users請求訪問互聯網時，squid詢問他們的姓名和護照，通過 ldap 進行身份驗證LDAP，如果 ldap 批准了他們，則授予他們。

每個人都很高興，直到一些嗅探器在用戶和魷魚之間的路徑中竊取了護照[路徑A]。這次災難的發生是因為魷魚使用了Basic-Authentication方法。

叢林裡的人們聚集在一起解決這個問題。有些兔子提供了使用NTLM方法。蛇優先Digest-Authentication，Kerberos樹推薦。

畢竟，叢林中的人們提供了許多解決方案，但一切都令人困惑！獅子決定結束這種局面。他喊出解決辦法的規則：

  • 解決方案是否安全！
  • 該解決方案是否適用於大多數瀏覽器和軟體（例如下載軟體）
  • 解決方案是否簡單且不需要其他龐大的子系統（例如Samba伺服器）
  • 該方法不應依賴特殊域。 （例如活動目錄）

然後，猴子提供了一個非常合理、全面、聰明的解決方案，使他成為新的叢林之王！

你能猜出解決方案是什麼嗎？

提示：squid和 之間的路徑LDAP受到獅子的保護，因此解決方案不必保護它。

筆記：如果這個故事無聊又混亂，我很抱歉，但大部分都是真的！ =)

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

更新：

馬西莫Users解釋說-squid和squid-之間的驗證方法LDAP不必相同。我們可以使用任意方法從使用者那裡獲取身份驗證信息，並使用任意方法對收集到的數據進行身份驗證。

但有一個問題：所有類型的驗證器的輸入/輸出都不相同。例如：

  • 身份驗證器Basic應讀取一行中的「使用者名稱密碼」對，OK如果使用者密碼正確或則回覆 aERR
  • 身份驗證器Digest應讀取 ausername:realm並回復十六進位編碼的HA(A1)或ERR。

雖然client-squid方法和squid-ldap方法之間沒有直接關係，但從客戶端收集的資料必須與squid-ldap部分使用的方法相容。因此，如果我們改變用戶端的認證方法，我們也許也應該改變我們的認證器。

所以問題就簡化為：

  1. 在第一級，我（猴子！）正在用戶端尋找一種好的身份驗證方法。您推薦哪一種方法安全且受大多數瀏覽器支持？我在NTLM和Kerberos之間感到困惑Digest。

  2. 我可以在哪裡找到支援所選方法的憑證資訊並透過 LDAP 進行身份驗證的身份驗證器。

答案1

Kerberos 不是 HTTP 驗證的選項。除 IE 外，NTLM 在任何瀏覽器中都沒有得到很好的支援。 Basic 是不安全的，除非你把它放在 HTTPS 後面，據我所知魷魚無法做到這一點。所以你只剩下摘要了。

答案2

一個可以幫助您的有趣功能是，Squid 用於要求客戶端瀏覽器進行身份驗證的方法（路徑 A）根本不需要與它用於實際驗證使用者提供的憑證的方法（路徑 B ）。這意味著，您可以讓 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實際使用什麼來驗證使用者提供的憑證。您可以在這裡使用任何您想要的身份驗證程序（甚至是自訂編寫的程式），只要它可以接收用戶 ID 和密碼並回答“是”或“否”即可。

您只需採用用於執行 LDAP 查詢的任何驗證器，並將其貼上到「auth_param ntlm」或「auth_param 摘要」語句中，而不是現在所在的「auth_param basic」語句中。

更新：

你絕對應該使用魷魚LDAP認證作為你的驗證者，但我不能準確地告訴你如何沒有有關您正在使用的特定 LDAP 伺服器的任何詳細資訊。

關於客戶端認證，任何一種都應該是好的；我對 NTLM 非常滿意，現在大多數瀏覽器都支援它。

這樣的配置在squid.conf中看起來像這樣：

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

這將使用 NTLM 要求使用者憑證（路徑 A），然後根據 LDAP 伺服器（路徑 B）驗證它們；但這些「參數」嚴格取決於您的 LDAP 實作和配置。

這也可能有幫助：http://www.cyberciti.biz/tips/howto-configure-squid-ldap-authentication.html。

相關內容