如果我取消选中 IIS 中的“启用匿名访问”复选框，以便对站点进行密码保护，即通过限制对指定 Windows 帐户的读取访问权限，则会出现随后显示的密码对话框对于所有匿名 http 请求，是否存在安全风险，因为它（似乎）提供了无限次数的尝试来猜测任何 Windows 帐户密码？
编辑： 好的，到目前为止，对此并没有太大的乐趣，所以我附上了赏金。才50分对不起，我是个谦虚的人。为了澄清我所追求的：在 IIS 中禁用匿名访问是否会为公众提供以前不存在的密码猜测机会，或者浏览器的用户凭据对话是否可以通过在http 直接请求，并且响应会指示组合是否正确，即使该页面仍然对匿名用户开放？此外，通过 http 提交的错误密码尝试是否受到对内部登录强制执行的相同锁定策略的约束，如果是这样，这是否代表一个非常容易故意锁定已知用户名的机会，或者，如果不是，有什么可以做的吗？减少这种无限的密码猜测机会？
【问题讨论】：
您的问题的简短回答是肯定的。每当您对网络上的任何资源进行任何远程访问时，都会带来安全风险。您最好的选择是关注IIS best practices，然后自己采取一些预防措施。 Rename your built in administrator account。执行强密码策略。 Change the server header。如果与适当的分层安全模型一起使用，则删除匿名访问虽然存在密码猜测风险，但它是一种非常易于管理的访问。
【讨论】：
当您选择匿名以外的身份验证时，您肯定会受到密码黑客的攻击。但是，使用的帐户受本地安全策略和您域的安全策略中设置的标准帐户锁定策略的约束。
例如，如果您有一个本地帐户“FRED”，并且帐户锁定策略设置为 30 分钟内 5 次无效尝试，那么这可以有效地防止帐户密码被猜测，从而面临拒绝服务攻击的风险。但是，将重置窗口设置为一个值（15 分钟？）有效地限制了 DOS。
不建议对非 SSL 连接使用基本身份验证，因为密码将以纯文本形式传输。
Digest 身份验证要求使用可逆加密将密码存储在服务器上，因此虽然比 Basic 更好，但 Digest 也有其缺陷。
Windows 集成身份验证 包括 NTLM 和 Kerberos。
应通过组策略或本地安全设置配置 IIS 服务器以禁用 LM 身份验证（网络安全：LAN 管理器身份验证级别设置为“仅发送 NTLMv2 响应”或更高，首选是“仅发送 NTLMv2 响应\拒绝 LM & NTLM") 以防止微不足道的 LM 哈希破解并防止 NTLM 中间人代理攻击。
可以使用 Kerberos，但它仅在两台计算机都是同一域的成员并且可以访问 DC 时才有效。由于这通常不会在 Internet 上发生，因此您可以忽略 Kerberos。
所以最终结果是，是的，禁用匿名确实会让您面临密码破解尝试和 DOS 攻击，但这些都是可以预防和缓解的。
【讨论】：
您应该了解可用的不同身份验证机制：基本、摘要、NTLM、证书等。IETF compiled a document 讨论了其中一些的优缺点（NTLM 是专有的 MS 协议）。
底线是：仅禁用匿名访问并没有完成。你一定要仔细考虑攻击场景是什么，潜在的损害是什么，用户可能愿意接受什么等等。
如果您引入授权，则需要解决凭据被泄露的风险。您还应该考虑您真正想要实现的是内容的机密传输：在这种情况下，您将不得不引入 SSL 等传输层安全性。
【讨论】：
据我所知，我是一名托管专家，我想有办法做到这一点，但我个人认为，你所说的做法无疑是一种不必要的安全风险。如果此站点要在 Internet 上可用，即它具有公共访问权限，那么您可能不想在 IIS 中禁用匿名访问。
请记住，能够在 IIS 中为站点配置匿名访问的想法是，您可以创建一个具有特定权限的用户来读取特定站点的相关文件。我们在这里谈论的是物理磁盘上的文件访问。一方面，公共网络服务器应该位于 DMZ 中，而不是您公司域的一部分，因此用户无论如何都不能使用他们的域凭据登录。
我可以想象您想要关闭匿名访问并强制用户输入他们的 Windows 凭据的唯一原因是一个仅在内部使用的站点，即使那样我也可能不会选择在此限制访问方式。
如果您想限制对公共网站内容的访问，那么您最好编写一些东西来处理身份验证作为网站本身的一部分或网站可以使用的服务。然后，如果有人要获取用户凭据，那么至少他们所能做的就是访问该站点，并且不会以任何方式破坏您的内部网络。
开发人员花费大量时间编写用户管理解决方案是有原因的。你会发现很多关于如何编写这样的东西的建议，以及很多可以为你完成大部分工作的库。
【讨论】：