squid中的安全用户认证的故事

Question

很久以前，南美洲有一个美丽的温暖的虚拟丛林，还有一个鱿鱼服务器住在那里。以下是网络的感知图像：

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

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

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

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

毕竟，丛林中的人们所提供的许多解决方案都令人困惑！狮子决定结束这种局面。他高呼解决办法的规则：

• 解决方案是否安全！
• 该解决方案是否适用于大多数浏览器和软件(例如下载软件)？
• 该解决方案是否简单且不需要其他大型子系统(如Samba服务器)？
• 方法不应依赖于特定的领域。(例如活动目录)

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

你能猜出解决办法是什么吗？

提示：squid和LDAP之间的路径是由狮子保护的，所以解决方案不需要保护它。

注:如果这个故事无聊而混乱，很抱歉，但大部分都是真实的！

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

更新：

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

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

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

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

，因此问题简化为：

1. 在第一级，我(猴子！)我正在寻找一个好的认证方法在用户端。您推荐哪种方法是安全的，并得到大多数浏览器的支持？我被NTLM，Kerberos和Digest搞糊涂了。
2. 其中，我可以找到一个身份验证器，它支持所选方法的凭据信息，并通过LDAP进行身份验证。

Answer 1

Kerberos不是HTTP身份验证的选项。除了IE之外，任何浏览器都不支持NTLM。Basic是不安全的，除非您把它放在HTTPS后面，这是AFAIK squid无法做到的。所以你只剩下文摘了。

Answer 2

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

对你来说，这意味着f.e。您可以安全地将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。