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

曾几何时，南美洲有一个美丽温暖的虚拟丛林，一个乌贼服务器就住在那里。这是网络的感知图像：

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

当Users请求访问Internet时，squid询问他们的姓名和护照，并通过LDAPldap 对其进行身份验证，如果ldap批准了它们，则他授予了它们。

每个人都很高兴，直到一些嗅探者在用户和鱿鱼之间的路径中偷走了护照[路径A]。发生这场灾难是因为鱿鱼使用了Basic-Authentication方法。

丛林人民聚集起来解决问题。一些兔子提供使用NTLM方法。蛇者优先Digest-Authentication，同时Kerberos建议由树木。

毕竟，丛林人提供的许多解决方案令所有人感到困惑！狮子决定结束这种情况。他大喊解决方案的规则：

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

然后，猴子提供了一个非常合理，全面而明智的解决方案，使他成为了丛林中的新国王！

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

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

注意：如果故事很无聊且混乱，很抱歉，但是大多数故事都是真实的！=）

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

更新：

Massimo解释了Users- squid和squid- 之间的身份验证方法LDAP不必相同。我们可以使用任意方法从用户那里获取身份验证信息，并使用任意方法向经过身份验证的收集数据。

但是有一个问题：所有类型的身份验证器的输入/输出都不相同。例如：

• 一个Basic认证器应在一条线上读“用户名密码”对和回复一OK如果用户通是正确的或ERR
• 一个Digest认证器应该读取username:realm和回复一个十六进制编码的HA(A1)或ERR。

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

因此，问题简化为：

1. 在第一层，我（猴子！）正在用户端寻找一种好的身份验证方法。您推荐大多数浏览器安全和支持的哪种方法？我在迷糊之间NTLM，Kerberos和Digest。

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

Kerberos不是HTTP身份验证的选项。除IE外，其他浏览器均未很好地支持NTLM。除非您将Basic置于AFAIK squid无法做到的HTTPS后面，否则它是不安全的。因此，您只剩下Digest。

一个可以在这里帮助您解决问题的有趣功能是，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”语句。

更新：

你一定要使用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。