Does disabling anonymous access in IIS create a security risk?

Question

If I uncheck the "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?

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?

Answer 1

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 practices and 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.

Answer 2

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.

• 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.

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.

Answer 3

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

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.