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

Does disabling anonymous access in IIS create a security risk?

提问by stovroz

If I uncheckthe "Enable anonymous access" checkbox in IIS, so as to password protect a site, i.e. by restricting read access to designated Windows accounts, does the resulting password dialogue which is then presented to all anonymous http requests, represent a security risk in that it (seemingly) offers all and sundry an unlimited number of attempts to guess at any Windows account password?

如果我取消选中IIS 中的“启用匿名访问”复选框，以便用密码保护站点，即通过限制对指定 Windows 帐户的读取访问，那么生成的密码对话是否会呈现给所有匿名 http 请求，是否代表安全风险因为它（似乎）提供了无限次数的猜测任何 Windows 帐户密码的尝试？

EDIT: Okay, not much joy with this so far, so I'm attaching a bounty. Just 50 points sorry, I am a man of modest means. To clarify what I'm after: does disabling anonymous access in IIS offer a password guessing opportunity to the public which did not exist previously, or is it the case that the browser's user credentials dialogue can be simulated by including a username and password in a http request directly, and that the response would indicate whether the combination was correct even though the page was open to anonymous users anyway? Furthermore, are incorrect password attempts submitted via http subject to the same lockout policy enforced for internal logins, and if so does this represent a very easy opportunity to deliberately lock out known usernames, or alternatively, if not, is there anything that can be done to mitigate this unlimited password guessing opportunity?

编辑：好的，到目前为止对此并不满意，所以我附加了赏金。仅50分抱歉，我是一个谦虚的人。为了澄清我的目标：在 IIS 中禁用匿名访问是否为公众提供了以前不存在的密码猜测机会，或者是否可以通过在直接 http 请求，并且即使页面对匿名用户开放，响应也会指示组合是否正确？此外，通过 http 提交的错误密码尝试是否受到针对内部登录强制执行的相同锁定策略的约束，如果是这样，这代表了一个非常容易故意锁定已知用户名的机会，或者，如果没有，

采纳答案by Christopher G. Lewis

When you choose an authentication other than Anonymous, you certainly can be subject to password hacking. However, the account that is uses is subject to the standard account lockout policies set in Local Security Policy and your Domain's security policy.

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

For example, if you have a local account "FRED" and the account lockout policy is set to 5 invalid attempts within 30 minutes, then this effectively prevents account password guessing, at the risk of a denial of service attack. However, setting the reset window to a value (15 minutes?) effectively limits the DOS.

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

• Basic Authentication is not recommeded for a non-SSL connection since the password will travel in plain text.

• Digest Authentication requires passwords to be stored on the server using a reversible encryption, so while better than Basic, Digest has its flaws.

• Windows Integrated Authentication includes NTLM and Kerberos.

  • The IIS Server should be configured via Group Policy or Local Security settings to disable LM authentication ( Network security: LAN Manager authentication level set to "Send NTLMv2 response only" or higher, preferred is "Send NTLMv2 response only\refuse LM & NTLM") to prevent trivial LM hash cracking and to prevent NTLM man in the middle proxy attacks.

  • Kerberos can be used, however it only works if both machines are members of the same domain and the DC's can be reached. Since this doesn't typically happen over the internet, you can ignore Kerberos.

• 不建议将基本身份验证用于非 SSL 连接，因为密码将以纯文本形式传输。

• Digest Authentication 要求使用可逆加密将密码存储在服务器上，因此虽然比 Basic 更好，但 Digest 也有其缺陷。

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

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

  • 可以使用 Kerberos，但是它只有在两台机器都是同一个域的成员并且可以访问 DC 时才有效。由于这通常不会发生在 Internet 上，因此您可以忽略 Kerberos。

So the end result is, yes, disabling anonymous does open you up for password cracking attempts and DOS attacks, but these can be prevented and mitigated.

所以最终结果是，是的，禁用匿名确实会让您面临密码破解尝试和 DOS 攻击，但这些都是可以预防和减轻的。

回答by user83352

The short answer to your question is yes. Any time you give any remote access to any resource on your network it presents a security risk. Your best bet would be to follow IIS best practicesand then take some precautions of your own. Rename your built in administrator account. Enforce strong password policies. Change the server header. Removing anonymous access, while a password guessing risk, is a very manageable one if used with the proper layered security model.

对你的问题的简短回答是肯定的。任何时候您对网络上的任何资源进行任何远程访问都会带来安全风险。最好的办法是遵循IIS 最佳实践，然后自己采取一些预防措施。重命名您的内置管理员帐户。强制执行强密码策略。更改服务器标头。删除匿名访问虽然存在密码猜测风险，但如果与适当的分层安全模型一起使用，则是非常易于管理的。

回答by mkoeller

You should read about differnet authentication mechanisms available: Basic, Digest, NTLM, Certificates, etc. The IETF compiled a documentthat dicusses the pros and cons of some of these (NTLM is propriatary MS protocol).

您应该阅读可用的不同网络身份验证机制：Basic、Digest、NTLM、Certificates 等。IETF编制了一份文档，讨论了其中一些的优缺点（NTLM 是专有的 MS 协议）。

Bottom line is: You are not done with just disabling anonymous access. You definitely have to consider carefully what the attack scenarios are, what the potential damage might be, what user may be willing to accept and so on.

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

If you introduce authorization you need to address the risk of credentials being compromised. You should also think if what you actually want to achieve is confidential transport of the content: In this case you will have to instroduce transport layer security like SSL.

如果您引入授权，则需要解决凭据被盗用的风险。您还应该考虑是否您真正想要实现的是内容的机密传输：在这种情况下，您将不得不引入传输层安全性，如 SSL。

回答by lexx

I am by know means a hosting guru and I imagine there are ways and means of doing this but my personal opinion is that what you are talking about doing is defiantly an unnecessary security risk. If this site is to be available on the internet i.e. it will have public access then you probably don't want to disable anonymous access in IIS.

我知道是一个托管大师，我想有很多方法可以做到这一点，但我个人的观点是，你所说的所做的无疑是一种不必要的安全风险。如果此站点要在 Internet 上可用，即它具有公共访问权限，那么您可能不想在 IIS 中禁用匿名访问。

Please remember that the idea of being able to configure the anonymous access for a site in IIS is so that you can create a user which has specific permission to read the relevant files for a particular site. What we are talking about here is file access on a physical disc. For one thing a public web server should be in a DMZ and not part of your companies domain so users should not be able to log in with their domain credentials anyway.

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

The only reason why I could imagine that you would want to switch off anonymous access and force users to input their Windows credentials is for a site which will only be used internally and even then I would probably not choose to restrict access in this manner.

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

If you want to restrict access to content on a public website then you would probably be better of writing something which handles authentication as part of the site itself or a service which the site can consume. Then if someone were to obtain user credentials then at least all they will be able to do is gain access to the site and there is no potential for a breach of your internal network by any means.

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

There is a reason why developers spend allot of time writing user management solutions. You will find plenty of advice on how to write something like this and plenty of libraries that will do most of the work for you.

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