Securing NTFS Permissions for IIS Servers

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 files\msadc. 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.

   Previous  [1]  2  Next