在IIS中禁用匿名访问会产生安全风险吗？

Question

如果我取消选中 IIS中的“启用匿名访问”复选框，以便密码保护站点，即通过限制对指定Windows帐户的读取访问权限，然后显示生成的密码对话框对于所有匿名的http请求，代表一种安全风险，因为它（貌似）提供所有和各种无限次尝试猜测任何Windows帐户密码？

编辑： 好吧，到目前为止，这并没有太多的快乐，所以我附上了赏金。只有50分对不起，我是一个谦虚的人。为了澄清我的目的：在IIS中禁用匿名访问是否为公众提供了以前不存在的密码猜测机会，或者是否可以通过在用户名和密码中包含用户凭据对话来模拟浏览器的用户凭据对话框。 http请求直接，并且即使页面对匿名用户开放，响应也会指示组合是否正确？此外，通过http主题提交的错误密码尝试是针对内部登录强制执行的相同锁定策略，如果是这样，这代表了一个非常容易故意锁定已知用户名的机会，或者，如果没有，是否有任何可以做的事情减轻这种无限密码猜测的机会？

Answer 1

对你的问题的简短回答是肯定的。只要您对网络上的任何资源进行任何远程访问，都会带来安全风险。您最好的选择是遵循IIS best practices，然后采取一些自己的预防措施。 Rename your built in administrator account。实施强密码策略。 Change the server header。如果与适当的分层安全模型一起使用，则在密码猜测风险的情况下删除匿名访问是非常易于管理的。

Answer 2

您应该阅读有关可用的不同身份验证机制：基本，摘要，NTLM，证书等.IETF compiled a document讨论其中一些的优缺点（NTLM是专有的MS协议）。

底线是：您没有完全禁用匿名访问。你必须仔细考虑攻击场景是什么，潜在的伤害可能是什么，用户可能愿意接受什么等等。

如果您引入授权，则需要解决凭据遭到入侵的风险。您还应该考虑您实际想要实现的内容是内容的保密传输：在这种情况下，您必须引入传输层安全性，如SSL。

Answer 3

当您选择匿名以外的身份验证时，您肯定会受到密码破解。但是，使用的帐户受本地安全策略和域安全策略中设置的标准帐户锁定策略的约束。

例如，如果您有一个本地帐户“FRED”并且帐户锁定策略在30分钟内设置为5次无效尝试，则这有效地防止了帐户密码猜测，存在拒绝服务攻击的风险。但是，将重置窗口设置为一个值（15分钟？）会有效地限制DOS。

• 不建议对非SSL连接进行基本身份验证，因为密码将以纯文本格式传输。

• 摘要式身份验证要求使用可逆加密将密码存储在服务器上，因此虽然优于Basic，但摘要有其缺陷。

• Windows集成身份验证 包括NTLM和Kerberos。

  • 应通过组策略或本地安全设置配置IIS服务器以禁用LM身份验证（网络安全：LAN Manager身份验证级别设置为“仅发送NTLMv2响应”或更高，首选是“仅发送NTLMv2响应”拒绝LM＆amp; NTLM“）以防止琐碎的LM哈希破解并防止NTLM人员在中间代理攻击。

  • 可以使用Kerberos，但只有当两台计算机都是同一域的成员并且可以访问DC时，它才有效。由于这通常不会通过互联网发生，因此您可以忽略Kerberos。

所以最终的结果是，是的，禁用匿名会打开你的密码破解尝试和DOS攻击，但这些可以被预防和减轻。

Answer 4

我知道这意味着一个托管大师，我想有办法做到这一点，但我个人的意见是，你所说的正在做的是不必要的安全风险。如果要在互联网上提供此站点，即它将具有公共访问权限，那么您可能不希望在IIS中禁用匿名访问。

请记住，能够在IIS中为站点配置匿名访问的想法是，您可以创建具有特定权限的用户来读取特定站点的相关文件。我们在这里谈论的是物理光盘上的文件访问。一方面，公共Web服务器应该位于DMZ中，而不是公司域的一部分，因此用户无论如何都无法使用其域凭据登录。

我可以想象你想要关闭匿名访问并强制用户输入他们的Windows凭据的唯一原因是一个只在内部使用的网站，即使那时我也可能不会选择限制访问方式。

如果您想限制对公共网站上内容的访问，那么您可能最好编写一些处理身份验证的内容，作为网站本身或网站可以使用的服务。然后，如果有人要获取用户凭据，那么至少他们能够做的就是获得访问该网站的权限，并且不会以任何方式破坏您的内部网络。

开发人员花费大量时间编写用户管理解决方案是有原因的。你会发现很多关于如何编写这样的东西的建议以及大量可以为你完成大部分工作的库。