When it comes to IIS security at the IIS server level, security often boils down to how well you know your users. In a perfect world, you’d know everyone who used your Web site, but in the real world, you’ll sometimes have to grant visitors anonymous access.

The problem is that the anonymous account can be a large gateway for potential hackers. To offset this threat, you’ll need to use permissions to secure what this account is allowed to do. In this Daily Drill Down, I’ll show the different types of shares you can configure and how anonymous permissions for these shares should be set for optimum security.

A tale of two users
From an IIS standpoint, there are two types of users: authenticated users and anonymous users. Anonymous users are users that aren’t required to enter a username and password. For example, if you were casually surfing the Web and went to my company’s Web site, you would be considered an anonymous user because you’d be browsing a freely accessible Web site that doesn’t require any sort of log-in information. If, on the other hand, you were to go to TechRepublic.com, you’d discover that the majority of the site is accessible only to subscribers. Therefore, to be considered an authenticated user, you’d be required to enter a user name and password.

Although it may seem strange, IIS security functions almost the exact same way for both authenticated users and for anonymous users. IIS rides on top of Windows 2000, and Windows 2000 requires users to enter authentication information before they are allowed to access any server-based resources. Because a Web site or an FTP site is a server-based resource, some form of authentication is required. To get around this requirement, IIS submits authentication for the Internet users. If your Web site requires authentication, then IIS will prompt the users for a user name and password and then pass that user name and password on to Windows for authentication.

When this happens, the authentication information that the Internet user enters will correspond directly to a Windows 2000 user account. If, on the other hand, a particular Web site doesn’t require authentication, then IIS will authenticate the user into Windows 2000 by using the Anonymous Logon account. In this case, the user is allowed to access the Web site because he or she is actually being authenticated, although he or she may never know it.

If you open the Active Directory Users and Computers console and browse the list of users, you won’t see an account called Anonymous. Instead, Windows uses an account called IUSR_server, where “server” is the name of your Windows 2000 server. However, even though an account named Anonymous isn’t accessible through Active Directory Users and Computers, it does exist. You’ll see the Anonymous Logon account when you try to grant permissions to a file, share, or directory. At the same time, you’ll also see the IUSR_server account. The fact that you can associate both accounts with various security properties means that you’ll have to exercise some caution.

You have to be especially careful with the anonymous accounts because it’s all too easy to accidentally grant unintended permissions to Internet users. For example, if you’ve been working with networks for a while in either a Windows NT or Windows 2000 environment, you’ve probably been taught to use the Everyone group to assign a particular permission to all of your users. In Windows 2000, though, using the Everyone group can be dangerous. The reason is that the Everyone group literally does include everyone, including authenticated and anonymous users alike. Therefore, if you were to grant a certain permission to the Everyone group, you could be inadvertently applying the permission to anonymous Internet users as well. If you’re in the habit of applying permissions to Everyone, then you’d be safer applying permissions to the Authenticated Users group instead.

Another way that anonymous Internet users can be accidentally assigned undesired permissions is through inheritance. Remember that the same inheritance rules apply to anonymous users as those that apply to authenticated users. Therefore, if you grant anonymous users access to a directory, then all of the subdirectories beneath it will also be made available to the anonymous users because of the inheritance of rights.

Controlling the anonymous account
At this point, you’ll want to double check to make sure that every partition on your server is formatted with NTFS. I routinely get a lot of security-related e-mail, and it seems that there’s a constant debate going on over whether it’s better to assign permissions at the NTFS level or at the share level. I’ve personally always felt that it’s more effective to assign permissions at the NTFS level. However, in the case of a Web server, I recommend assigning security in both places.

Let’s take a look at the share-level security. In Windows 2000, there are actually two types of shares. You’ve got the normal shares like you’d find in Windows NT. These are the ones you create when you’re sharing files for workstations that log in to your domain. You’ve also got Web shares, which allow you to control access to a Web site.

You create both normal shares and Web shares by right-clicking the folder you want to share and selecting Properties. When the Properties screen appears, you’ll see two tabs that control shares: Web Sharing and Sharing. As you can probably guess by the names, you select the Web Sharing tab to configure Web shares and the Sharing tab to set normal file shares.

When you’re configuring Windows 2000 as a Web server, I recommend setting up the Web server in such a way that nothing is shared except for the Web sites that you’re hosting. That way, if you set a share permission, it makes the shared folder a part of a specific Web site. Permissions you set apply to anyone who accesses the share through that Web site. Fortunately, you can modify the share permissions to grant different levels of access to different users.

If you do configure shares, assign anonymous users the most restrictive permissions possible. For example, if the users will only be browsing a Web site, they will only need Read access to the folder or folders containing the site. You can provide such access by assigning anonymous users the Read Permission at the share level or by setting the Web share access permissions to Read.

As you look at each share point, check the assigned permissions carefully. Remember that a specific denial always overrides a specific grant. Therefore, if you’ve got a folder that needs to be shared across the Web, but you don’t want anonymous users to access it, it isn’t enough just to not give anonymous users access to the share. Instead, you should explicitly deny anonymous users access to the share.

If you merely fail to grant anonymous users access to a specific Web share, then anonymous users usually won’t be able to access that share point. In such a situation, however, you always run the risk of an unintended permission inheritance taking effect and accidentally granting anonymous users access to the normal share. You also have to worry about hackers exploiting some weakness in the system and gaining access to the normal share.

Therefore, make absolutely sure to specifically deny access to anonymous users unless you want them to access a given share point. In fact, when I’m setting up a Web server, I always just assume that anonymous users can access anything that I don’t specifically lock down. You can see an example of such a lockdown in Figure A.

Figure A
Specifically deny anonymous users access to anything that you don’t want them to be able to access.

While we’re on the subject of shares, I should point out that, by default, Windows 2000 shares each partition automatically. The share name is the drive letter followed by a dollar sign. The dollar sign indicates that the share is hidden. Even though the share is hidden, that doesn’t mean that the share is inaccessible. I’ve seen quite a few hack attempts in which the hacker tried to exploit the C$ share to access a machine’s C: drive. Windows 2000 must have the drives shared to function correctly. Therefore, you can’t disable these shares. I do, however, like to make a habit of double checking each drive share to make sure that these share points aren’t configured to share anything across the Web. Call it paranoia if you want, but I sleep much better at night knowing that my Web servers are secure.

Web share properties
If you click the Web Sharing tab on a folder’s properties and look at a Web share, you’ll see that there are some other settings that you can apply beyond just the user or group and the level of access that you see when you configure normal sharing. One such mechanism is the Application Permissions section. This section allows you to set the folder’s Web share permissions to prohibit applications to be run from the folder; scripts to be run; or any executable, including scripts, to be run. Although often overlooked, this is an invaluable security mechanism.

Suppose for a moment that someone slipped a piece of code onto your Web site. As long as you had the application permissions set to prevent the code from running, any scripts or executables that had been uploaded wouldn’t be able to run. Therefore, unless a particular Web folder requires the ability to run scripts or executable files, I strongly recommend setting the Application Permissions to None, as shown in Figure B. Other security mechanisms visible in Figure B include the ability to permit or block script source access and directory browsing. Again, it’s in your best interest not to allow anything that isn’t absolutely required.

Figure B
You can use application permissions to prevent scripts or executable files from running.

NTFS permissions
So far, you’ve seen how you can apply permissions to both standard share points and Web share points. However, it’s just as important to assign security at the file level as a last line of defense against any hacker that somehow bypassed or altered the various share permissions. Whenever you apply permissions at both the share level and the file level, both sets of permissions are in effect and work independently of each other.

You can set NTFS permissions for a file by right-clicking it and selecting Properties. When the Properties window appears, click the Security tab. On the Security tab, you can set the permissions you want.

Just as with share permissions, a specific denial always overrides a specific grant. Therefore, if an anonymous user somehow broke through share-level security, but the file level specifically blocked anonymous access to a given directory, then the anonymous user wouldn’t be allowed access.

NTFS, share-level, and Web share permissions all play a role in the overall security of your Web server. Security is enforced in the way that you set permissions for authenticated and for anonymous users. Because anonymous users present the biggest threat for security break-ins on your network, you should take extra care to lock down the permissions for this account.