When you host a Web server, you put a part of your organization on display and open it up to the poking and prodding of the anonymous masses. Remotely exploitable flaws in the Web server platform can be disastrous. Case in point: Microsoft Internet Information Services (IIS) 5.0 left a trail of lost productivity and revenue.
However, Microsoft redesigned IIS with security as a top priority. The result was IIS 6.0, which is widely held as the most secure commercial Web server on the market (as indicated by the low number of Secunia advisories about it—three—see secunia.com/product/1438).
IIS 7.0 builds on the secure design of IIS 6.0 and has been modularized so that individual features can be removed entirely, thus reducing the overall attack surface of your Web server. Application pools, introduced in IIS 6.0 as a way to isolate applications from each other (and from the Web server process), are now more effectively sandboxed. New delegation features let site owners manage their sites without elevated privileges. Request filtering (aka URLscan) is now built into the server. And administrators can define rules right in IIS 7.0 that control which users have access to which URLs.
These features are among the security-related enhancements in IIS 7.0. They’re worth a closer look, and they might even change the way you think about managing and configuring Web sites.
Application Sandboxing
Consider a market research company hosting surveys or other low volume sites for competing companies on the same box. Or consider a server that hosts a payroll application used by a small number of users and a homegrown portal used companywide. In both cases it’s crucial that these applications running on the same servers be isolated from each other.
Web applications run in worker processes. Application pools map Web applications to worker processes. A specific worker process is used only to run applications that are part of the same application pool. In IIS 6.0 and IIS 7.0, the worker process is w3wp.exe.
In IIS 6.0, new Web sites and applications are put into the same application pool. This default application pool runs under the NetworkService account. As an administrator, you can create new application pools manually and assign Web apps to those pools. By default, those application pools will also run under the NetworkService account, which can lead to an undesirable runtime scenario as all Web applications run with the same permissions. An application in app pool A can read the configuration of app pool B and even access the content files of applications assigned to app pool B. Although it’s easy enough to create new app pools and to configure custom accounts for each, managing those accounts over time is cumbersome.
With IIS 7.0, a new application pool is created automatically for each Web site. By default, that application pool is configured to run as the NetworkService account. But when the worker process is created, IIS 7.0 injects a special SID unique to the app pool into the NetworkService security token. IIS 7.0 also creates a configuration file for the worker process and sets the file’s ACL to allow access only to the unique SID for the app pool. The result is that an application pool’s configuration can’t be read by other application pools.
As an additional precaution, you can change the ACLs on content files to provide access to the unique app pool SID instead of NetworkService. This will prevent an application in app pool A from reading the content files of an application in app pool B.
IUSR and IIS_IUSRS
Tangentially related to process identity is the question of which identity the server uses for anonymous requests. Previous versions of IIS relied on a local account, IUSR_ servername, as the identity for anonymous users. IIS 7.0 uses a new built-in account called IUSR. You can’t log in locally with the IUSR account, so it doesn’t have a password (which means there are no risks due to attackers guessing the password). The IUSR account always has the same SID so ACLs are transferrable between Windows Server 2008 machines (as well as Windows Vista machines). And if the IUSR account isn’t appropriate for your scenario (e.g., if anonymous requests require authenticated network access), you can turn off the anonymous user account and IIS 7.0 will use the worker process identity for anonymous requests.
Also new is the built-in IIS_IUSRS group. This group replaces the IIS_WPG group. In IIS 6.0, the IIS_WPG group provides the minimum rights needed to run a worker process, and you must manually add an account to this group to provide a custom identity for a worker process. The IIS_IUSRS group provides a similar role for IIS 7.0, but you don’t explicitly add accounts to this group. Instead, IIS 7.0 automatically enrolls accounts in IIS_IUSRS when they’re assigned as the identity for an application pool. And as with the IUSR account, the IIS_IUSRS group is built-in, so it always has the same name and SID on all Server 2008 installations, making ACLs and other configurations completely portable between Server 2008 machines (and Vista machines).
Feature Delegation
Not every Web server setting really needs to be protected by admin rights. Some settings are simple application-level decisions that can be made by developers or product managers. For example, in IIS 6.0 you need admin rights to change the default document for a Web application. But normally is there really any reason that the ability to change default.aspx to profile.aspx should require administrator rights?
In IIS 7.0, configuration decisions can now be delegated to site or application owners. IIS 7.0 uses a new XML-based configuration system inspired by ASP.NET. At the site and application level, both IIS 7.0 and ASP. NET configuration settings are found in the same web.config files.
Delegated settings such as the default document can be changed at the Web site level or application level by editing the web.config file directly or using the IIS Manager GUI, as Figure 1 shows, which updates the web.config for you. In the web .config file, the system.webServer section contains the IIS 7.0 configuration settings, which Figure 2 shows.
The sections that are valid within are defined in a special configuration file called applicationHost. config. In applicationHost.config, each section has a default delegation mode. In the example in Figure 3, the default document and directory browsing settings can be overridden but not the asp, caching, or cgi sections.
But what if there is a good reason to prevent a Web site owner from changing the default document? No problem: IIS 7.0 lets you lock configuration elements so they can’t be set or overridden in web.config files. In the case of the default document, you can globally change the default override mode to Deny or you can explicitly set the override mode to Deny for specific locations (using location tags). The IIS team recommends asserting these kinds of changes in location tags, as Listing 1 shows. Feature delegation can be a great boon to a busy administrator because it safely empowers Web site and application owners to configure aspects of the Web server that affect only their sites and applications.
Continued on page 2