Chapter 10: Securing IIS

Now that you’ve learned how to perform basic IIS administration tasks such as creating and configuring websites, FTP sites, and applications, it’s time to dig deeper into the platform and learn about more advanced administration topics including securing IIS, working from the command line, performance monitoring and tuning, working with the metabase, and so on. We’ll begin by looking at how to secure IIS, focusing especially on websites hosting both static and dynamic content. And where better to start than the topic of permissions!

Permissions

Permissions form the foundation of securing any application or operating system platform. When referring to IIS, however, you have to be careful because there are two sets of permissions you must deal with:

• NTFS permissions These are file system permissions that control who is able to access a file or folder and what level of access they have.

• Web permissions These are special permissions that determine whether a web or FTP client can read files on an IIS website’s home or virtual directory, write to the directory, browse the directory, and so on.

These permissions work differently, and we’ll begin by examining how they operate and then look at what happens when you combine them together. But first I should note that there may be one other type of permissions used with IIS: shared folder permissions. These come into play when a website’s home directory or a virtual directory has its content located in a shared folder on a network file server, and IIS maps the site name or directory alias to the share using its UNC path (see Chapter 7, “Creating and Configuring Websites,” for information on how to do this). I’ll discuss shared folder permissions briefly after I cover the other two types of permissions, NTFS and IIS.

NTFS Permissions

NTFS permissions are the bedrock of IIS security (and Windows Server 2003 security as well). Understanding NTFS permissions is therefore an essential prerequisite to being able to securely host static content and applications on your web server. I’ll briefly review how NTFS permissions work and give some tips on using them to secure IIS. To make things more interesting, let’s work with a concrete example and use C:\Inetpub\wwwroot, the home directory of the Default Web Site.

NTFS Permissions on \wwwroot

Open Windows Explorer, find the C:\Inetpub\wwwroot directory, right-click it to open its properties sheet, and select the Security tab (Figure 10-1). This displays the NTFS permissions configured on the \wwwroot directory. If you select each security principal (user or group account) in turn, you’ll see that each of them has a unique set of permissions assigned to them as defined in Table 10-1. The settings in this table represent the access control list (ACL) configured for the \wwwroot file system object.

Figure 10-1: Security tab showing NTFS permissions on \wwwroot

Table 10-1: Default Permissions for \wwwroot

Security Principal	Full Control	Modify	Read & Execute	List Folder Contents	Read	Write
Administrators	Allow	Allow	Allow	Allow	Allow	Allow
IIS_WPG			Allow	Allow	Allow
Internet Guest Account					Deny
SYSTEM	Allow	Allow	Allow	Allow	Allow	Allow
Users			Allow	Allow	Allow

Note 

The permissions for \wwwroot in Table 10-1 are the same whether the IIS machine is a standalone server (belongs to a workgroup) or a member server (part of a domain). The meaning of these permissions may differ however, for example, the Internet Guest Account is a local user account in a workgroup scenario and a domain user account when Active Directory is being used.

Tip 

You can also access the NTFS permissions for the \wwwroot folder directly from IIS Manager by right-clicking the Default Web Site and selecting Permissions. This also works for virtual directories but not with individual files.

NTFS Standard Permissions

There are about two dozen NTFS permissions you can configure, but to simplify things Windows Server 2003 groups these into overlapping subsets called NTFS standard permissions. As listed in Table 10-1, there are six standard permissions you can configure:

• Full Control Lets users add, modify, delete, and move files and their properties, and change permissions on files and subdirectories.

• Modify Lets users view and modify files and their properties, and add or delete files to/from a directory.

• Read & Execute Lets users run scripts and executable files.

• List Folder Contents Lets users view the contents of a directory.

• Read Lets users view files and their properties.

• Write Lets users write files and their properties.

Note that some of these standard permissions appear as if they are incompatible with one another, as you will quickly find out if you try to configure them for a file or folder. The reason for this is not that the various standard permissions are incompatible but that as cumulative rather than atomic permissions they overlap somewhat. For example, create a New Folder on your desktop and open the Security tab of its properties sheet. Click Add and type Users to add the Users group to the folder’s ACL, and note that by default the following permissions are allowed:

• Read & Execute

• List Folder Contents

• Read

Now try to clear only the Read & Execute check box, and note that the Read check box automatically clears also—as it must, because Read & Execute includes Read. Then select Allow Under Full Control, and note that all of the check boxes are automatically allowed. Here are some additional important things to note about NTFS permissions:

• NTFS permissions are only available on NTFS volumes. You should always keep your web or FTP site content stored on NTFS volumes, never on FAT or FAT32 volumes!

• NTFS permissions apply only to the security principal (user or group) they are granted to and only for the specific file system object (volume, folder, or file) they are applied to (unless they are inherited from above). For example, permissions assigned to the Administrators group for \wwwroot affect only members of that group and only for the \wwwroot folder.

• NTFS permissions secure files and folders for websites, FTP sites, local console access, and network access using UNC paths. In other words, NTFS permissions are a feature of the operating system and secure file system objects against any form of access, and not just for browsers accessing IIS websites.

• List Folder Contents applies to folders only, not files. In other words, there are six NTFS standard permissions you can use for folders and five for files.

• If you want more granular control over how users access your files and folders, you can configure NTFS special permissions by clicking the Advanced button in Figure 10-1. Note that NTFS special permissions can get quite complicated, however, and using them properly requires a good understanding of how NTFS works in Windows Server 2003 and is beyond the scope of this book.

• NTFS permissions can be either allowed or denied. For example, the Deny Write permission configured on the Internet Guest Account is a security measure that prevents anonymous users from being able to write to websites using WebDAV or some other method. Normally, however, Deny permissions are not recommended and configuring appropriate Allow permissions should suffice.

• If you create a web page within \wwwroot, the new page inherits the NTFS permissions of its parent directory \wwwroot.

• If you copy web content to \wwwroot from a folder on the same NTFS volume, the content inherits the NTFS permissions of \wwwroot. The same goes if you copy the content from a folder on a different NTFS volume.

• If you move web content to \wwwroot from a folder on the same NTFS volume, the content retains the NTFS permissions of its original folder. But if you move the content from a folder on a different NTFS volume, the content inherits the NTFS permissions of \wwwroot.

The last two items in the preceding list are import to remember if you are going to be moving content around on your web server using xcopy or some other method.

Security Principals

I mentioned security principals in the previous section, and what this term means is a Windows Server 2003 object that has a security identifier (SID) associated with it.

Typically, this means user accounts and groups, but it can also mean computer accounts if you are using Active Directory. In an intranet scenario, for example, you could configure NTFS permissions for individual computer accounts (or global groups containing computer accounts) in order to control access to IIS content based on which workstation a user is using.

In any case, let’s look at the various security principals that have NTFS permissions configured for \wwwroot:

• Administrators A local group in a workgroup scenario (or domain local group in an Active Directory scenario) for system administrators. Note that users of this group have full control over \wwwroot, and this is generally good practice and should not be changed, as it allows administrators to fix things should anything go wrong with the directory’s permissions or content.

• IIS_WPG This local (or domain local) group is new to IIS 6 and grants the necessary privileges required by user accounts used as process identities for worker processes servicing application pools. I’ll discuss this in more detail later in the section “Configuring Application Pool Identities.”

• Internet Guest Account This local (or domain) user account has the name IUSR_ computername where computername is the name of the local IIS machine. This account impersonates anonymous users to allow them access to web content on IIS when anonymous access is configured for the site (see the section “Anonymous Access” for more on this topic). The IUSR_ computername account has a randomly generated password associated with it; and, generally, you should not try to change the password for this account because it might cause the metabase to get out of sync with Active Directory, resulting in content access problems that are difficult to troubleshoot. You can, however, create additional Internet Guest Accounts, and you can assign each site on your IIS machine a different such account, but this is not common practice.

• SYSTEM This is a special identity or built-in group created by Windows Server 2003 and should always have full control of your web content directory.

• Users This local (or domain local) group contains ordinary network users. By default, this group is assigned Read and Read & Execute permissions so that when ordinary users are properly authenticated using Integrated Windows Authentication (or some other method), they can view static content or execute scripts to generate dynamic content on the IIS machine.

  Note 

  In IIS 6, the IUSR_computername account no longer requires the Log On Locally right, which makes this account more secure than in previous versions of IIS.

NTFS Permissions in IIS 5

For administrators familiar with IIS 5 on Windows 2000, you’ll have noticed by now that the NTFS permissions on \wwwroot have significantly changed in this version. On IIS 5 the permissions on \wwwroot were as follows:

• Administrators: Full Control

• Everyone: Read & Execute

• SYSTEM: Full Control

Note the security improvements in IIS 6 over this old scheme:

• The Everyone special identity has been removed from the ACL for \wwwroot

• The Internet Guest Account has Write permission explicitly denied for \wwwroot.

Effective Permissions

Permissions problems can be tricky to troubleshoot, but fortunately Windows Server 2003 includes a new feature that lets you easily view the effective permissions assigned to a security principle for a file system object. Try this out: on the Security tab for \wwwroot properties, click Advanced and select the Effective Permissions tab (Figure 10-2).

Figure 10-2: Determining effective permissions for an account

Now click Select to open the Select User Or Group dialog box. Click Advanced, then Find Now, and scroll to select the IUSR_ computername account. Click OK twice to return to the Effective Permissions tab and view the effective permissions for the Internet Guest Account. These permissions are

• Traverse Folder/Execute File

• List Folder/Read Data

• Read Attributes

• Read Extended Attributes

• Read Permissions

A little exploration will show that these are the same permissions assigned for \wwwroot to the Users group: Read & Execute permissions.

NTFS Permissions for New Websites

We’ve looked at NTFS permissions for the Default Web Site, but what about for new websites you create on your IIS machine? Try this: using IIS Manager, right-click the Web Sites node and select New | Web Site, and follow the prompts accepting the defaults. Be sure to assign the site an IP address; leaving it as All Unassigned will conflict with the Default Web Site, and the new site won’t start. When asked where the home directory should be located, click Browse, select C: drive, click Make Folder, and create a folder named \stuff for the new site’s home directory. Finish the wizard, and open the properties sheet for C:\stuff and view the Security tab. Here’s what you find:

• Administrators have Full Control.

• Creator Owner has Special Permissions.

• System has Full Control.

• Users have Read & Execute.

Click Advanced to view the permissions in more detail, and you will see that most of them are inherited from the root directory of the C: drive. A few things to note:

• The Internet Guest Account does not have permissions explicitly assigned to it, but this is not really necessary because the account only impersonates anonymous users.

• The NTFS permissions on \stuff are the same regardless of what settings you select or deselect when running the Web Site Creation Wizard. For example, if you deselect the Allow Anonymous Access To This Site check box, the final NTFS permissions are the same, and only the web permissions change for the site. (We’ll look at web permissions in the next section of this chapter.)

You might be wondering how anonymous users will be able to access content on your new website, as IUSR_ computername is not listed on the Security tab as it was for the Default Web Site. The answer is that IUSR_ computername is considered by Windows Server 2003 as belonging to the Authenticated Users built-in group. Authenticated Users is one of many special groups (or special identities) whose membership is controlled by the operating system and cannot be changed by administrators. And since Authenticated Users rolls up into the Users group, the permissions for Users are inherited by IUSR_ computername, which gives anonymous users access to anything members of the Users group can access on your site.

If, on the other hand, you want only anonymous users to be able to access your site, you can remove the permissions allowed to Users and add IUSR_ computername to your ACL. Then assign IUSR_ computername suitable permissions such as Read or Read & Execute, depending on the type of content your site contains. By explicitly granting permissions to IUSR_ computername, you grant anonymous users access to your site.

Note 

If you create a new virtual directory within the Default Web Site, the NTFS permissions assigned to it by the Virtual Directory Wizard are the same as for a new website as just described.

Web Permissions

Another kind of permissions you need to be familiar with when securing content on IIS sites is web permissions (sometimes referred to as “IIS access permission” or “IIS permissions”). To configure web permissions for the Default Web Site, open the properties sheet for this site in IIS Manager and select the Home Directory tab (Figure 10-3).

Figure 10-3: Configuring web permissions for the Default Web Site

There’s nothing on this Home Directory tab that says “web permissions,” but they’re right there in the middle of the screen:

• Read Lets users view or download files in the directory. You will almost always want to leave this checked so people can visit your site! An exception might be when you are making modifications to your site directly on a production server.

• Write Lets users upload or modify files in the directory. This is needed, for example, when a user wants to upload files to the server using WebDAV, something we’ll discuss in Chapter 16, “Publishing with IIS.”

• Directory Browsing Allows a directory listing to be returned to users when they browse a site that has no home page (no default document defined or present). Most of the time you will leave this cleared to prevent users from nosing around.

• Script Source Access Selecting this in conjunction with Read lets users view the source code of ASP pages; in conjunction with Write, it enables them to modify ASP pages on your server. Not a good idea! Select this option only on development servers on isolated testbed networks when debugging ASP apps you are developing.

  Note 

  If both the Read and Write check boxes are cleared, the Script Source Access check box will be unavailable.

There are two other settings here that are sometimes also considered web permissions because of their proximity on this properties sheet to the preceding settings:

• Log Visits Turns on logging for the site, provided logging is actually enabled on the Web Site tab. While logging visits to your site can indeed be a security issue because you can use web logs to discover malicious traffic patterns, it’s not really a permissions issue, so I’ll defer a discussion of this feature until Chapter 12, “Performance Tuning and Monitoring.”

• Index This Resource Causes the Content Indexing Service to create a full-text index of the site’s content. You typically use this if you plan to include a search engine on your site; it has nothing to do with security or permissions.

Finally, note the Execute Permissions list box near the bottom of the Home Directory tab. This list relates to application permissions, which I’ll talk about in the “Configuring Execute Permissions” section.

Note 

“Web permissions” is somewhat of a misnomer, since Read and Write permissions, as well as Log Visits, are also available on the Home Directory tab of FTP site properties sheets.

Working with Web Permissions

Web permissions can be assigned at four levels. Remember, as stated in Chapter 7, you can configure IIS properties sheets at multiple levels. Web permissions can be configured for:

• All websites using the Home Directory tab on the properties sheet for the Web Sites node The default web permissions at this level have none of the check boxes selected. Changes made here are inherited by all websites on the machine.

• A particular website using the Home Directory tab on the properties sheet for that site The default web permissions for a site depend on the settings you select when running the Web Site Creation Wizard. For example, if you clear the default option of allowing Read permission when running the wizard, the check box for Read permission will be cleared on the Home Directory tab. Changes made at this level are inherited by all files and virtual directories in the site.

• A particular directory (or virtual directory) using the Directory (or Virtual Directory) tab on the properties sheet for that directory (or virtual directory) The default web permissions for a virtual directory also depend on the choices you make when running the Virtual Directory Creating Wizard, while those for a directory inherit the settings of the parent (home) directory. Changes made at the directory (or virtual directory) level are inherited by all files within the directory (or virtual directory).

• A particular file within a virtual directory using the File tab on the properties sheet for that file

  Note 

  The first three levels of web permissions can also be configured for FTP sites.

How Web and NTFS Permissions Differ

Why are there two sets of permissions for securing websites? And what’s the difference between the NTFS Read permission and the Read permission on the Home Directory tab for a site? All the difference in the world! Here’s how they work under the hood:

• NTFS permissions When a user tries to access a web page located on an NTFS volume, an access token is first created using the user’s SID. The token is then passed to the server, which compares the SID in the token to the SIDs in the ACL for the page. If a match is found, the user is granted the level of access specified in the ACL; and if no match is found, the user is denied access to the page.

• Web permissions When a user tries to access a web page on an IIS site, the user’s browser issues an HTTP request with headers containing an HTTP verb that specifies the type of request being made. For example, an HTTP GET request is a request to read the page. For IIS to respond to such a request, it must have the Read web permission assigned to the page (that is, to the directory in which the page resides). Likewise, WebDAV uses HTTP LOCK and HTTP PROPFIND requests to publish content to your web server, and for this to work you must have Read, Write, and Directory Browsing web permissions enabled.

In conclusion, NTFS permissions are a characteristic of the Windows file system and are enforced by the operating system, while web permissions are a characteristic of HTTP and are enforced by IIS. There are other differences as well, the most important being that NTFS permissions apply only to the specific users and groups for which they are configured. For example, Users has Read & Execute permission, while Administrators has Full Control. If you want different groups of users to have different levels of access to your site’s content, use NTFS permissions to achieve this. By contrast, web permissions apply equally to all users and groups for the site on which they are configured.

Combining NTFS and Web Permissions

What happens if your site’s home directory has Read web permission but lacks Read NTFS permission for users needing to access it? Or what happens if the reverse is the case, and the directory has Read NTFS permission but lacks Read web permission? In both cases, users will not be able to access the site. Try this as an exercise: create a local user called Test with password “password” on your stand-alone server running IIS. Now open the properties sheet for the Default Web Site, switch to the Directory Security tab, click Edit under Authentication And Access Control, and clear the check box to disable anonymous access. (I’ll talk about IIS authentication methods in the upcoming section “Authentication.”) Go to another machine on your network and type the URL for the Default Web Site on your IIS machine (usually http:// iismachinename will do, where iismachinename is the NetBIOS or DNS name or IP address of your IIS machine). You should get an authentication dialog box, so enter the username and password for user Test to view the iisstart.htm “under construction” page.

Now remove the Read web permission for the site on the Home Directory tab of its properties sheet. Refresh the page on your client machine’s browser, and you should see the message “HTTP Error 403.2—Forbidden: Read access is denied.” Re-enable the Read web permission on the server, right-click the Default Web Site, and select Permissions to access the ACL for \wwwroot. Click Add, type Test, click Check Names, and click OK to add Test to the ACL for \wwwroot. Note that, by default, Test has Read & Execute permissions assigned (since Test belongs to the Users group which has these permissions). Override this by clicking the check box to Deny Read permission, and save the changes.

Now go back to your client machine and refresh your browser. This time the logon box will ask you three times for Test’s credentials before finally returning the message “HTTP Error 401.3—Unauthorized: Access is denied due to an ACL set on the requested resource.” Go back and remove Test from the ACL for the \wwwroot, and re-enable anonymous access for the Default Web Site.

What do you think happens if NTFS permissions for a site’s home directory are Read and Write while its web permission is only Read? Or what if both Read and Write web permissions are enabled while NTFS is only Read? In both cases, users will only be able to read content on the site, not write to it. The general rule is if web and NTFS permissions differ, the more restrictive of the two applies. This is not to say web permissions replace NTFS permissions, they augment them by adding an additional layer of security on top of NTFS—modifying one has no effect on the other. The more important of the two types of permissions, however, is NTFS, which has much greater flexibility and granularity for securing file system resources including IIS content.

Note 

When a client tries to access a site, IIS first checks to see if web permissions will allow the requested level of access. If the answer is yes, IIS checks to see if NTFS permissions will allow access. I’ll talk more about the order in which IIS processes security requests in the upcoming section “Putting It All Together.”

Shared Folder Permissions

As if things weren’t confusing enough, there’s one more type of permission you may sometimes have to deal with in IIS: shared folder permissions. The only time these become important is when your website content is located on a different server from your IIS machine, such as on a network file server. In this case, as you saw previously in Chapter 7, you need to specify the UNC path on the Home Directory tab of your site’s properties sheet so it points to the shared folder where the site’s content resides.

This consideration also applies to FTP sites, as discussed previously in Chapter 9, “Creating and Configuring FTP Sites.”

Fortunately, shared folder permissions are simpler than NTFS permissions, as they have only three possible settings:

• Read

• Change

• Full Control

In most cases, Read will suffice; but if Change or Full Control is required for applications to work, make sure your NTFS permissions are configured properly to prevent unauthorized access.

Security Alert! 

Never use an administrator account as credentials for accessing content stored on remote network shares. This goes for websites, FTP sites, and virtual directories. The usual setting is to use the default, that is, the authenticated user’s credentials are used for accessing the site. Alternatively, specify some non-administrator account if required for accessing the share.