☰

Squid 中的安全用户身份验证的故事

tag-icon • tag-icon security authentication ldap squid kerberos
Squid 中的安全用户身份验证的故事

从前，南美洲有一片美丽温暖的虚拟丛林，一个鱿鱼服务器住在那里。这是该网络的感知图像：

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

当Users请求访问互联网时，squid询问他们的姓名和护照，通过 ldap 进行身份验证LDAP，如果 ldap 批准了他们，那么他就授予他们访问权限。

每个人都很开心，直到一些嗅探器在用户和 squid 之间的路径上窃取了护照[路径 A]。这场灾难的发生是因为 squid 使用了Basic-Authentication一种方法。

丛林中的人们聚集在一起解决这个问题。一些兔子提出了NTLM一种方法。蛇喜欢，Digest-Authentication而Kerberos树木则推荐。

毕竟，丛林人提出了很多解决方案，但大家都很困惑！狮子决定结束这种情况。他大声喊出了解决方案的规则：

  • 解决方案是否安全？
  • 该解决方案是否适用于大多数浏览器和软件（例如下载软件）
  • 解决方案是否简单并且不需要其他庞大的子系统（如 Samba 服务器）
  • 该方法不应依赖于特殊域。（例如 Active Directory）

这时，一只猴子给出了一个非常合理、全面、聪明的解决方案，让他成为了新的丛林之王！

你能猜出解决方案是什么吗？

提示：squid和 之间的路径LDAP受狮子保护，因此解决方案不必保护它。

笔记：抱歉故事有点无聊和混乱，但大部分都是真实的！=)

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

更新：

马西莫Users解释说-squid和squid-之间的认证方法LDAP不必相同。我们可以使用任意方法从用户那里获取认证信息，并使用任意方法对收集的数据进行认证。

但有一个问题：所有类型的authenticator的输入/输出并不相同。例如：

  • 验证Basic器应该读取一行中的“用户名密码”对，并回复 a，OK如果用户密码正确或ERR
  • 验证器Digest应该读取username:realm并回复十六进制编码的HA(A1)或ERR。

尽管客户端的 squid 方法和 squid-ldap 方法之间没有直接关系，但从客户端收集的数据必须与 squid-ldap 部分使用的方法兼容。因此，如果我们更改了用户端的身份验证方法，我们可能也应该更改我们的身份验证器。

因此问题简化为：

  1. 在第一级中，我（猴子！）正在寻找一种良好的用户端身份验证方法。您推荐哪种方法？安全且受大多数浏览器支持NTLM？我对、Kerberos和感到困惑Digest。

  2. 在哪里我可以找到支持所选方法的凭证信息并通过 LDAP 进行身份验证的身份验证器。

答案1

Kerberos 不是 HTTP 身份验证的选项。除了 IE 之外，其他浏览器都不太支持 NTLM。除非您将其置于 HTTPS 之后，否则 Basic 并不安全，而据我所知，Squid 无法做到这一点。因此，您只能使用 Digest。

答案2

这里有一个有趣的特性可以帮助您，那就是 Squid 用于要求客户端浏览器进行身份验证的方法（路径 A）根本不需要与它用于实际验证用户提供的凭据的方法（路径 B）相关。这意味着，您可以让 Squid 与客户端浏览器“对话” NTLM，但它可以很好地根据 Linux 的内部用户数据库 (/etc/passwd) 验证用户。不需要使用 NTLM（在路径 A 上）获取的凭据才能真正针对 Windows 域（在路径 B 上）进行验证。这同样适用于客户端身份验证方法和服务器端身份验证方法的任何可能组合。

在您的情况下，这意味着您可以安全地配置 Squid 以从客户端浏览器请求 NTLM 身份验证而不是基本身份验证，并且这不会以任何方式要求您实际使用 Samba/WinBind/AD/whatever。

因此，您可以选择任何您想要的方法进行客户端身份验证，但是在用户使用您选择的方法提供其凭据后，仍然会继续根据 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 digest”语句中，而不是现在的“auth_param basic”语句中。

更新：

你绝对应该使用squid_ldap_auth作为你的验证者，但我不能确切地告诉你如何没有关于您正在使用的特定 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。

相关内容