Author's note: This article is about IIS 5.0 permissions. Although much of the theory will carry over into an IIS 4.0 environment, minor differences will remain.
New administrators trying to set up their first IIS-based Web server or FTP server from scratch find life pretty easy. During Windows 2000 OS installation, you simply tell the wizard that you want WWW and FTP services. After rebooting, you're the proud owner of a shiny new Web or FTP server. But those anonymous servers don't cover every requirement of WWW and FTP services. Some sites require more security, such as usernames and passwords.
You can offer WWW and FTP services anonymously, or the services can require users to provide credentials before they grant access. You can use Secure Sockets Layer (SSL) to make sure users aren't sending those credentials in cleartext. Using one type of authentication in IIS 5.0, you can even require users to have a certificate to access your Web site. (Unfortunately, FTP doesn't have the ability to require a certificate.) In IIS 5.0 and IIS 4.0, the default user account that IIS uses is usually called IUSR_computername. IIS uses this account for anonymous connections to both the Web service and the FTP service. (In Win2K, Microsoft recommends that you use separate accounts for the FTP and WWW services.)
Two distinct types of permissions exist for the WWW and FTP services: IIS and NTFS. People frequently confuse these permissions, although each has unique characteristics. You use NTFS permissions to restrict group and individual user access to files. You use IIS permissions to limit access to the Web server. I compare IIS and NTFS permissions and show you how these permissions work together.
Grant or Deny: Deciding Who Has Access
IIS goes through a complete security-check process before it returns content to the requesting client. As the server receives requests from the client, the server considers these questions in sequential order:
- Is the IP address permitted? (IP restrictions)
- Does the request pass the appropriate authentication? (User authentication)
- Does the Web server allow this type of access? (IIS permissions)
- Do the NTFS permissions allow access to this file? (NTFS permissions)
Only if the answer to all these questions is yes does the Web server grant access to the resource the Web client is requesting. The server evaluates the IP address against the Web server's list of IP addresses that have been granted or denied access to that resource. You grant or deny access on the IP Address and Domain Name Restrictions dialog box, which Figure 1 shows.
If you've granted access, then the Web server passes an authentication request to the OS. (For more information about IIS 5.0 authentication types, see Brett Hill, "IIS 101: The Basics of IIS Authentication," http://www.iisadministrator.com, InstantDoc ID 15843.) If the authentication request passes, the OS considers the IIS permissions followed by the NTFS permissions.
Setting the Appropriate IIS Permissions
Administrators often overassign IIS permissions to directories that contain scripts and executable files. In the properties for any directory or virtual directory, you must choose one of three levels of Execute permissions, which affect application security. The three choices that appear in the Execute Permissions drop-down list, which Figure 2 shows, are
- None—This directory has no executable files; therefore, the server won't run scripts or executable files in this directory.
- Scripts only—If you set this directory to execute only scripts, only scripts such as .asp files can run on the server. The server can execute only those script types you define in the Web server's Application Mappings list, which you access by clicking Configuration on the Home Directory tab of the Web site's Properties dialog box.
- Scripts and Executables—Other types of executable files can run on the server. Application types aren't limited to the Application Mappings list as they are in the Scripts only permission.
When you've assigned the appropriate IIS permissions for your Web server, you can move on to NTFS permissions and focus on limiting your users to the lowest necessary number of resources.
Limiting Web Server Permissions
Now that you've decided on authentication and IIS permissions, you can focus exclusively on NTFS permissions. If you're installing a new Web server for the first time, you can easily take away all the NTFS permissions to directories and selectively allow access. Going back after the fact and removing permissions from an existing production Web server is far more difficult. Be sure to test any potential changes in a test environment before applying the changes to a production Web server.
You have several choices of groups with which to assign NTFS permissions, and each group has unique characteristics. Let's briefly look at four choices—three built-in groups and one anonymous user account.
- Everyone—The Everyone group represents everyone known to the Web server. This group includes anyone who presents credentials to the Web server or who could successfully log on to the Web server anonymously. Many new IIS servers use the Everyone group because it's the default group you use to assign permissions when you create the server.
- IUSR_computername—If you're using Anonymous authentication, use the IUSR_computername account to assign permissions.
- Interactive—If you're using Basic authentication, the Interactive built-in group represents any and all users who use Basic authentication or the IUSR_computername account to log on (only if you disable the Allow IIS to control password feature).
- Network User—If you're using Digest or Integrated Windows authentication, the Network user built-in group represents any users who use those authentication methods to log on. This group also controls the Anonymous account (if you enable the Allow IIS to control password feature).
If you use Microsoft FrontPage to manage your Web site, you can use an entirely different set of groups. Those groups are
- FP Web Name\Admins
- FP Web Name\Authors
- FP Web Name\Browsers
Assign administrative permissions to the Admins group, sufficient permissions to update the Web site to the Authors group, and equivalent permissions to the Browsers group. The interesting part of using local groups to assign these permissions is that you can assign global groups to these local groups to ensure consistency in your administration. For example, you might add a global group called San Diego Web Administrators to each FrontPage Admins group in each server in San Diego to ensure that those administrators can administer all their Web sites and servers.
Setting the Appropriate IIS Permissions
Although much of the access control for IIS comes from NTFS-based ACLs, additional internal options exist within IIS that you can control. Figure 2 shows additional controls within IIS to limit access. The system considers these permissions in addition to the NTFS ACLs. These special IIS permissions are
- Script source access—Users can access the source code to files such as Active Server Pages (ASP) files.
- Read (default)—Users can read the contents of static files (e.g., .htm, .txt) and send the GET command in the HTTP request. Note that this setting doesn't affect a user's ability to run scripts or executable files.
- Write—Users can write to files and send the PUT command in the HTTP request. Note that this setting doesn't affect scripts or executable files that write to the Web site.
- Directory browsing—Users can list contents of directories.
The important thing to note here is that you shouldn't consider IIS permissions in the same light as NTFS ACLs. You apply IIS permissions first, but NTFS ACLs perform the real security work in IIS. NTFS permissions limit access file by file, on a per-user basis. IIS permissions qualify only what types of requests are permitted; therefore, they apply to all users of the resource rather than to specified users or groups. IIS permissions can't discriminate among users like NTFS ACLs do.
Determining NTFS ACLs Based on Functions
Assigning only enough permissions to accomplish the assigned function always makes good security sense. Administrators tend to overassign permissions. They use the Full Control and other administrator-type permissions far too much. These permissions can get you out of a jam for the short term, but they make pulling back later more difficult.
So, which NTFS permissions are really necessary for an IIS 5.0 Web server? You set basic permissions on the Security tab of the Web server's Properties dialog box, which Figure 3 shows. Select a group name, and click Advanced to set advanced permissions, which Figure 4 shows. Essential basic and advanced NTFS permissions are
- Modify—This permission includes the Read and Write permissions. This combination most often applies to users who need to update content on a site. Be certain you grant this permission only to users who need that capability and never to the Anonymous account.
- List Folder Contents—This permission is necessary for viewing files and subdirectories in a particular directory. Virtual directories are never visible.
- Read—Read permission is best used with static content, such as HTML pages and images. If you're setting permissions on a database, select both Read and Write permission.
- Execute—This permission is necessary for executable files, such as .dll or .exe files.
Apply sufficient permissions to give your users or groups the lowest number of permissions. If you're using Anonymous authentication, assign permissions to the IUSR_computername account. If you're using any other authentication type, assign the NTFS permissions as appropriate to an account or preferably to a local group on the Web server that contains the appropriate account.
IIS supports the FTP protocol as well as the HTTP protocol. Authentication for FTP is similar to Web server authentication, but it's significantly more limited.
Using anonymous FTP is simple. An FTP server that allows anonymous connections still challenges users for their username and password, but users only need to supply the username Anonymous and their email address as a password (although many FTP servers accept any password in the form of an email address). However, anonymous FTP isn't appropriate for every situation.
An FTP server that requires user credentials provides only marginal additional security over anonymous FTP. The biggest drawback of the FTP protocol is that the FTP username and password is always transmitted in cleartext, which introduces a credible threat that a malicious user on the network can compromise the username and password. Using your everyday account name and password to authenticate to an FTP server exacerbates this risk.
To remedy this problem, consider using a group username and password that has access to the FTP site and no other resources. This option limits risk to only the data that username and password protects. Be sure to follow your company policy regarding group accounts: Some companies prohibit or restrict the use of group accounts.
Creating an FTP Virtual Directory
You can create a directory or site that requires credentials before it grants access (e.g., to a specific directory). I suggest that you create a test user or group for this purpose, one to which you've granted no extra permissions or rights. To create an FTP virtual directory, follow these steps:
- Open the Microsoft Management Console (MMC) Internet Services Manager snap-in.
- Expand the appropriate FTP server to display the Default FTP Site.
- Right-click Default FTP Site, then select New, Virtual Directory to start the Virtual Directory Creation Wizard. Click Next.
- For the virtual directory alias, enter the name of the group or user you created previously. Click Next.
- Click Browse, then select the appropriate directory. (Be careful about what you select as the root of your virtual directory.)
- Choose whether you want to allow Read or Write permission to this directory. Click Next.
- Click Finish.
Creating a new FTP site is similar to creating a virtual directory; you can even change the default FTP port, which lets you set up more than one FTP server on the same computer. If you change the port, your end users need to know the new port number before they can connect.
Assign the Proper Permissions
Setting up Web server and FTP server permissions doesn't have to be complicated. You can establish a Web site or FTP site and use anonymous accounts, group accounts, or user accounts to restrict access. I've covered just a few of the possible new security precautions that relate to these decisions. I recommend that you avoid transmitting your user account names and passwords in cleartext whenever possible. Assign the lowest number of permissions possible, and avoid overassigning permissions as a quick fix to a problem.