NTFS Permissions for IIS Web Servers

In January 26, 2000—nearly a month before the official release of Windows 2000—Microsoft released Security Bulletin MS00-006 (Patch Available for "Malformed Hit-Highlighting Argument" Vulnerability), which announced a Microsoft IIS vulnerability that could let an intruder view the source code of server-side documents, including Active Server Pages (ASP) scripts. This vulnerability is a risk because ASP code often contains sensitive information such as passwords or SQL statements that could be useful to intruders. Security experts advise that you set proper NTFS file permissions on your Web server hard disks. Since Win2K's release, Microsoft has released other similar advisories and has repeated the advice to set proper NTFS file permissions.

But which permissions should you set? Many administrators have had the experience of trying to tighten file permissions on a Web server only to discover that they've broken some feature of a Web application. Administrators are therefore wary of changing file permissions on servers that already function properly. But understanding how Web servers and their users interact with the file system will give you the knowledge and confidence to properly set permissions that greatly improve your Web server's security.

User Context
A typical Win2K system runs many processes at any given time. If you open Task Manager and select the Processes tab, you'll see a list of currently running processes. Open View, Select Columns, and you can select additional information about each process. Select the User Name check box and click OK to view a list similar to Figure 1, page 76, that shows which users own each process.

When a user launches a process, the process is launched in that user's context. If that process launches another process, the child process remains in the same user context as its parent. When a process accesses an NTFS volume, that file will always be accessed in that process's user context.

Some services, such as IIS, run under the System context but, for security reasons, will impersonate accounts with lesser privileges—called impersonation—by launching a new process under a different user context. As a result, the new process will make file requests under a different user context. Before you begin to lock down the system, you must first understand how each of these user roles comes into play.

The System Account
The System account, sometimes referred to as LocalSystem, is an internal account the OS uses primarily to launch Windows services. The System account doesn't show up in Local Users and Groups, and you can't remove it from the system. It's a member of the Administrators group, but you can't add it to any other groups. You can set NTFS permissions for the System account, but you can't assign it any user rights.

The System account is powerful. You can't deny the System account the right to change permissions. In other words, if you limit permissions for the System account, it can change those permissions back to the default settings. Microsoft designed this capability to ensure that the OS functions properly. On a default Win2K installation, the System account has full access to every file on an NTFS volume. If intruders can exploit a Windows service running under the System account, they can launch other processes or access files under the System context. Such access makes the System account an attractive target for intruders.

Microsoft recommends that you typically not remove the System account permissions from a file, but in some cases doing so will limit exposure to Win2K vulnerabilities that let intruders launch processes under the System context. One such vulnerability was the .Printer buffer overflow that Microsoft Security Bulletin MS01-023 (Unchecked Buffer in ISAPI Extension Could Enable Compromise of IIS 5.0 Server) mentions. Therefore, limiting which files the System account can access can sometimes be important.

The Administrator
The built-in Administrator account is another privileged account that you must guard closely. Because you don't want to put too many file restrictions on this account, avoid running services as Administrator and limit access to Web browsing and email when logged on with this account. The Administrator account is a member of the built-in Everyone, Administrators, Authenticated Users, and Users groups. And when you log on to the Administrator account from the console, the account is also a member of the built-in Interactive group.

IWAM and IUSR Accounts
The IWAM and IUSR accounts are special-purpose accounts that handle requests from anonymous Web users. The IUSR account handles anonymous requests for Web resources; therefore, the NTFS permissions determine who can access what. For example, if you deny the IUSR account read access to index.html, anonymous Web users won't be able to access that file. Any COM components or processes that ASP code shells will also run under this user context. The IWAM account hosts Web instances that use medium or high application protection. It also runs out-of-process applications such as COM+ applications.

The IWAM and IUSR accounts are low-privilege accounts. Although they're supposed to be Guest accounts, they're also members of the built-in Users and Authenticated Users groups. The IIS Lockdown tool creates a Web Anonymous Users group that contains the IWAM and IUSR accounts, so when you set file permissions, use this group rather than the specific user accounts. Following this procedure makes it much easier to specifically block anonymous Web users from accessing certain files. Because this practice is highly recommended, this article will refer to the Web Anonymous Users group rather that the individual IWAM and IUSR accounts.

Other Accounts
Depending on your system configuration, you probably have other user accounts and roles. For example, you might have multiple Web site authors and administrators. You might also have users who log on to your Web site but who should otherwise have limited access to the system. Furthermore, some applications might install additional service accounts. Understanding the role particular users play and determining exactly which files they need to access are therefore important considerations.

Protecting the Webroot
Files in the webroot directory can be the most sensitive files on a Web server. These files are exposed to the public and often contain sensitive code that intruders can use to gather information and possibly compromise the Web server. For example, your server-side code might contain database-connection information, including passwords, that an intruder could use to compromise your server. Your code might also contain references to files and directories that an intruder might find useful. If someone gains access to this source code through a file-viewing vulnerability, your server is at great risk.

You can use the Internet Services Manager (ISM) to set read, write, and directory-browsing permissions for Web applications, but those permissions aren't the same as NTFS permissions. The Web application permissions control how IIS handles Web user requests; NTFS permissions provide a higher level of control and regulate what IIS can access. If ISM discovers a vulnerability that causes IIS to reveal server-side code, the NTFS permissions will take precedence and block access to the file. Although this article discusses NTFS permissions, you should also carefully select the permissions assigned in the ISM.

To secure the Web root, first remove the inherited permissions. Right-click the webroot directory, select properties, then select the Security tab. Clear the Allow inheritable permissions from parent to propagate to this object option. When the system prompts you for instructions for handling the existing permissions, click Remove. This important step ensures that the Web directories don't inadvertently inherit unwanted permissions from parent directories.

Next, limit the Web Anonymous Users group's permissions; don't let this group Write to any Web directories. For the most part, you don't want Web Anonymous Users to write to the file system. If you have an application that requires Write permissions, add that permission to only those directories that require it. This rule is also true for Execute permissions; remove execute permissions from all Web directories unless absolutely necessary for a Web application. If you have directories that contain DLL or executable files, the applications will run correctly only if anonymous users have Execute permissions. Script files, such as ASP code, don't need NTFS Execute permissions.

Most people advise that you put writable and executable files in their own directories, separated from other types of content. For example, you should place all executable files in a directory named CGI or BIN. You can give the directory Execute permissions, but when a directory has Execute permissions, any programs that you add to that directory will also be executable. So, instead of giving the directory Execute permissions, consider giving Execute permissions to only the particular files your Web application needs. That way, any new files you put into the directory won't automatically inherit Execute permissions.

Many Web-based attacks involve uploading some program to the Web that lets the attacker gain additional access to the system. For example, the CodeRed worm uploaded the file root.exe to the Scripts directory of a victim's Web site. By giving execute permissions on the file level alone, you prevent any new files from becoming executable just by being placed in the right directory. This technique alone could have greatly limited the effects of the CodeRed worm and its variants.

You should also restrict the System account's access to the Web directories. IIS has been vulnerable to several types of buffer overflow attacks that let intruders gain System-level access, and similar vulnerabilities will probably be exposed in the future. Limiting what the System account can do to the webroot will greatly reduce exposure to such attacks. Although the System account can change NTFS permissions set on any file, doing so requires a more complex approach, thus limiting exposure to only the more sophisticated attacks. Keep in mind, however, that if you're using the Indexing Service, the System account needs to be able to read the webroot to create an index.

When you publish files to your Web directories, you must understand how permissions change when you copy or move files. When you copy files, they always inherit the target directory's permissions. But when you move a file to a new location within the same NTFS volume, the permissions remain the same. When you move a file to a different NTFS volume, the file inherits the destination folder's permissions. So, double-check file permissions after you publish Web content.

Setting Web content files as read-only is a technique that isn't directly related to file permissions but is worth mentioning. Anyone can change these attributes, but doing so will complicate an attack. For example, if intruders can write files but can't execute programs, they can't change the read-only attributes to overwrite or modify existing files.

Because the webroot is such a sensitive area, fully auditing changes to those files and directories is a vital step. Audit all failed access and successful actions except reads. Doing so might lead to larger event logs, but the detailed activity record can be an advantage. I recently gathered evidence for a client after an intruder penetrated the client's internal database and gained access to sensitive customer information. I found evidence that the intruder had placed certain files in the client's Web directories and had later deleted the files. If the client had audited the Web directories, I could have determined exactly when the intruder created and deleted the files and the filenames and user account the intruder used.

The System Root
By default, everyone has full control of the root directory of the system partition, partially because the Windows swap file is created in that directory. If a user logs on and doesn't have full access to the directory, virtual memory operations won't work properly. Because members of the Web Anonymous Users group never actually log on locally to the Web server console, they don't need such liberal permissions to this directory. Give this group read-only permissions on the root directory.

System Executables
Because researching the effects of limited permissions on the thousands of files under the winnt directory is a huge task, let's look at denying access to specific files that we know can cause problems. Many system executables that are typically used for legitimate purposes can also be used to facilitate attacks on a Web server. Programs such as cmd.exe, tftp.exe, and telnet.exe pose a significant risk if an outsider gains access to these commands. For example, some attacks involve using cmd.exe to run commands on the server, whereas other attacks use tftp.exe to upload files to the Web server. By default, the system has few restrictions on who can execute these programs.

To secure these files, remove all permissions and add only those users who will specifically use the files. For example, you might give only the Administrator account full control of the files and completely deny all other users access. Remember to specifically list the Administrator user, not the Administrators group; the System account is a member of the Administrators group and would therefore inherit that group's permissions.

Program Files
Most applications in the Program Files directory are intended for only local users and administrators and should be appropriately secured. Server applications, such as mail and database servers, and administrative applications, such as backup software, are of special concern. By default, the Users group has Read and Execute access to all Program Files directories. Deny the Web Anonymous Users group access to all these application directories except the Common Files directory, which contains system components that your Web application might need to use and Web applications that use COM components (such as an SMTP mailer).

Log Files
If intruders can modify log files, they can erase any traces of illegal activity. If intruders compromise a system and have permissions to modify log files, proving that the logs are valid evidence of an intrusion is difficult. Even if intruders don't modify the logs, these files can contain information that could lead to the compromise of additional systems. So, take extra precautions to protect log files.

Securing log files can be tricky. You want the System account—the user context of IIS—to be able to create Web logs, append data to them, and create new log directories when you add Web sites. The System account is the only account that should have Write access to these directories, and only the Administrator or the user who's responsible for managing log files or running Web statistics programs should be able to read Web logs.

The System account should be able to create files and directories but not modify existing files. To accomplish this, set two ACL settings for the LogFiles directory—one for subdirectories (containers) and one for files (objects).

First, right-click the log files directory, select Properties, then select the Security tab. Clear the Allow inheritable permissions from parent to propagate to this object option, then click Remove to give yourself a clean slate to work with. Click Advanced, click Add, then select the System account from the list. A dialog box will prompt you to set permissions. From the Apply onto drop-down list, select Files Only, then select the check box for the following permissions, as Figure 2 shows: Read Attributes, Create Folders /Append Data, Write Attributes, and Read Permissions.

Click OK, then click Add. Select the System account again and click OK. When the permissions dialog box appears, select This folder and subfolders from the Apply onto drop-down list. Select the following permissions: List Folder, Read Attribute, Create Files/Write Data, Create Folders/Append Data, Write Attributes, and Read Permissions.

Click OK, click Add again. Select the Administrator account (not the Administrators group). Select This folder, subfolders and files and select the following permissions: Traverse Folder/Execute File, List Folder/Read Data, Read Attributes, Read Extended Attributes, Delete Subfolders and Files, Delete, and Read Permissions.

If other users will be managing log files, repeat the previous steps for each user. When you're finished, select the Reset permissions on all child objects and enable propagation of inheritable permissions check box.

By configuring these permissions, you essentially let the System account create log files and directories but not modify existing data. You also let only the administrator or designated users read and move log files, but you don't let those accounts modify logs.

Because both the System and Administrators accounts can modify permissions, carefully audit the access to the directory. If you're building a case against an intruder, you must be able to prove that the intruder didn't modify the files or change the permissions. Right-click the directory, select Properties, then select the Security tab. Click Advanced, then select the Auditing tab. Add an audit policy for the Everyone group. Audit successful use of the following permissions: Create Files/Write Data, Delete Subfolders and Files, Delete, Change Permissions, and Take Ownership.

To further monitor access to these files, you might also want to audit failed use of the following permissions: Create Files/Write Data, Create Folders/Append Data, Delete Subfolders and Files, Delete, and Change Permissions. With these permissions and audit settings in place, you can be confident that your log files haven't been modified, and you'll have a full audit record.

As you learn more about user roles and how they interact with the file system, you'll be able to protect your Web server without causing disruption to user applications. This process clearly takes effort and careful planning, but the creative use of permissions can build a Web server that's resilient to attack.