Securing NTFS Permissions for IIS Servers

Going beyond the defaults

Editor's Note: This article focuses exclusively on IIS 4.0 running on Windows NT. If you're securing IIS 5.0 on Windows 2000, take a look at the recently released Win2K/IIS 5.0 checklist (http://www.microsoft.com/technet/security/iis5chk.asp).

A key step in securing an IIS Web server is properly using NTFS permissions (also known as ACLs) to limit access to the server without sacrificing that server's functionality. Merely accepting the default permissions assigned during IIS installation results in a working Web server; however, left unchecked, the defaults can lead to trouble. Default installation permissions aren't secure and can benefit a malicious user exploiting other vulnerabilities in IIS, such as the Remote Data Factory exploit I mention later.

Before I get into the meat of ACLs, let me start with a disclaimer. These recommendations are intended for new IIS 4.0 installations. You can apply these settings to a production Web server, but please be forewarned that applications, drivers, and services that you installed afterward might not work correctly. Similarly, implementing these permissions changes on a new Web server installation can prevent you from installing software down the road. I often loosen the permissions just long enough to install what I need, then tighten them after the installation is complete.

I want to help you make your systems secure by keeping IIS permissions reduced to only what is necessary for properly serving content to your clients. In other words, reduce the permissions to the bare minimum necessary for making IIS work properly, which means changing several settings from their defaults. When you're finished, you'll be better able to thwart opportunistic users and derail malicious users from exploiting IIS to execute unauthorized commands.

Why You Need to Change Permissions
In the Microsoft article "Re-release: Unauthorized Access to IIS Servers Through ODBC Data Access with RDS" (http://www.microsoft.com/technet/iis/iissadsi.asp), the company warns that users could exploit a particular DLL using Remote Data Factory, an object included with Microsoft Data Access Components (MDAC) and installed by default in many installations of Microsoft Windows NT 4.0 Option Pack. Malicious users could exploit this DLL through IIS 4.0 and run DOS shell commands with administrative privileges. This problem was exacerbated because the DLL had Everyone/Full Control permission. This vulnerability was widely published across the industry, including the mainstream media.

The vulnerability still exists in many Web servers. Developers use Remote Data Factory when they want to write pages that make ODBC connections to internal ODBC-compliant databases—a common practice today. Microsoft's recommendation to administrators who need this functionality is to upgrade MDAC and tighten permissions on a subdirectory rarely associated with IIS, program filescommon filesmsadc. Other administrators can merely delete the directory and disable the function within the Registry. Additional tightening of NTFS permissions beyond Microsoft's recommendation alleviates much of the Remote Data Factory concern and other similar but as-yet-undiscovered attacks.

The Log on Locally Account Right and the IUSR_server User Account
Part of the function of any Web server is the capability to let an Anonymous user retrieve content from the server. NT requires credentials for any user attempting to access resources on an NT server. For IIS to safely serve Web pages to an Anonymous user, IIS must impersonate a valid account on the local Web server. For that impersonation to work properly, the impersonated account must have the Log on Locally account right.

Anonymous Web requests often impersonate valid accounts by using an account called IUSR_server, where server represents your server's formal computer name. The IIS 4.0 installation process creates this account, adds it to the local Guests group, and gives it the Log on Locally account right. Any account that uses IIS Anonymous authentication to access content needs this right. Many security administrators have minor strokes when they learn that an Anonymous user has a right that they typically take away from more privileged users. Thus, most IIS servers fail the traditional audit process.

Recommendation: Limit the use of the Log on Locally right to the account using Anonymous authentication to access the Web server and log on to the local machine. Don't forget to leave at least one administrative group or account with this right.

I have a big problem with the IUSR_server account IIS 4.0 uses. I don't like using an account name that you can easily guess. When I install an IIS server that will be in a high-profile or risky situation, I rename that Anonymous user account. Good security administrators tend to set user accounts to lock out after a certain number of bad password attempts. Because the IUSR account is just like any other user account, a malicious user could easily lock up your account by looking for content that would otherwise require credentials. If the IUSR_server account is locked, your Web server comes to a screeching halt.

Recommendation: Change the IUSR account name to something that is harder to guess. Don't use underscores in usernames that Microsoft SQL Server will use. After you rename the account, update your IIS 4.0 server properties with the new name. (The name doesn't change automatically.) Afterward, make sure you can still use your Web site.

Users and Groups
Common theory regarding the proper way to set NT permissions says that you must use groups when you assign permissions. While this theory should also hold true for IIS, in fact the default installation uses the single Anonymous Web User account to assign permissions.

I often create two local groups on a Web server—an Authenticated Web Administrators group and an Anonymous Web Users group. This method is similar to the one the Microsoft FrontPage Server Extensions configuration uses—create three local groups per Web (Administrators, Authors, and Browsers), each prefixed by its Web name. (I use two groups because I've never known content developers who would be happy not being administrators of their own sites.)

In our model, the Anonymous Web Users group likely has only one member—the Anonymous account that you renamed in the previous section. The Authenticated Web Administrators group has the additional file permissions, such as Write and Delete, in the Web server directories. This Authenticated Web Administrators group lets you add users who need the ability to directly update content in the directories without giving them administrative privileges.

I place the Anonymous IIS account (IUSR_server) in the Anonymous Web Users group as I change the file permissions on my Web server. As I browse my content directories, this group never receives any permissions other than Read and Execute. For any developers or content administrators who need access, I assign their usernames (or global group) to the Authenticated Web Administrators local group. This group usually receives Write and Delete permissions in addition to the Read and Execute permissions I give to the Anonymous users.

Recommendation: Use local groups rather than users to assign security rights and permissions.

Setting ACLs in NTFS Directories
Now, for the meat and potatoes of the permissions, start by enabling Traverse Directory Checking. Traverse Directory Checking requires the OS to check not only the ACL of your requested file but also the ACL of each subsequent parent directory of that file up to the root directory of the logical drive. If you don't have sufficient permissions, the OS denies you access. This style of permissions is probably different from what you're used to, but it helps cover the unknown.

If you're asking why you should bother with such a complicated model, the answer is that this permission prevents someone from browsing your directory structure and connecting to a share merely to bypass any other directory permissions you've set. To disable directory checking in NT 4.0, start User Manager. From the Policies menu, choose User Rights. On the User Rights dialog box, select the Show Advanced User Rights check box. Now, from the drop-down list box, select Bypass Traverse Directory Checking. Figure 1 shows the local security settings for a directory with Bypass Traverse Checking enabled.

When you enable Bypass Traverse Checking, the minimum rights a user needs to examine the contents of a directory is List. Therefore, the group that contains the Anonymous account used for IIS (I used the Anonymous Web Users group earlier) should at least have the List permission for any directories that group has to traverse. So, if you expect the Anonymous Web Users account to run scripts or read other files, that group must have List permission for those directories as well.

Recommendation: Remove everyone from the Bypass Traverse Directory Checking pane before you set ACLs.

Open Windows Explorer, and nagivate to the root of your boot partition, where your winnt directory is located (usually the C drive). Change the permissions of the root of the drive, including all subdirectories and files, to the settings you see in Figure 2. This process can take a few minutes, during which time any user can see anything, so you need to disable access to the OS. Beneath the winnt directory, change the permissions for each subdirectory to the settings you see in Figure 3 to add protection to the backup copy of the SAM.

Now, make these additional permissions changes:

Many installation programs need additional permissions for the temp directories. You might want to loosen the permissions if you're having problems installing a particular program.

The ACL guidelines that Figure 8 shows apply to IIS-based content. Microsoft recommends these ACLs for specific types of Web content. Plan your directory structure around the recommended ACLs.

If you have multiple disks on your machine, you might also need to spend time ensuring that users and administrators alike can see what they're supposed to see. At a minimum, each additional disk must have

Administrators: Full ControlSystem: Full Control

If you need to grant access to users, remember that they need the List permission at the root level and for every subdirectory to which you want to grant them access. This permission grants them access to traverse that directory. They can't read a file until they receive Read permission. In new installations, setting such permissions on ACLs is easy. Existing installations are a bit tougher, and you'll have to experiment with the permissions necessary for each directory and application.

Recommendation: Set ACLs for each file, directory, and drive to the minimum permissions necessary for accomplishing the assigned tasks.

Logs
Malicious users like to tamper with logs to cover their tracks, and they know the OSs better than you do. I recommend changing the default location of the IIS logs (C:winntsystem32logfilesw3svcx, where x represents the number of a Web site running on a particular IIS server). Move these logs to another location or even to another disk.

Rather than erase the existing log directory, you might be able to fool some of the less-experienced intruders if you leave the old default log directories empty. You might fool someone into thinking that you're not logging at all. Masking the name of the new log directory doesn't hurt, either. Place the logs somewhere obscure with a directory name that doesn't have anything to do with logs. This masquerading won't deter determined intruders, but you don't want to make it easy for those intruders to cover their tracks by deleting log files that might announce their presence.

Make Security an Ongoing Process
I listed only a few changes that you can make to the ACLs of an NTFS-based IIS Web server. As you experiment with the ACL changes, you'll find yourself thinking more in terms of how to ensure that your Web server and content directories are secure. I strongly encourage you to continue looking into securing your Web server. Security is something that you must keep up with. You can't just set it and forget it. Don't forget that Microsoft keeps a ready-made IIS checklist to make sure you covered all your security bases. You can find this checklist at http://www.microsoft.com/technet/security/iischk.asp. Keeping up-to-date with your Web sites' security and performing the occasional audit are great ways to ensure that your Web sites and content stay safe.