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.
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 SandboxingConsider 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 transferable 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 DelegationNot 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.
Administration Delegation
Many admins find it expedient to just give out admin access to whoever needs to apply a change to a site or application. This, of course, is a tremendous security risk. Unfortunately, the choice has been difficult: either liberally assign admin rights or impede updates by becoming the single point of administration. With IIS 7.0, server admins can grant administration rights for a specific Web site or application to one or more users without elevating user privileges.
In IIS Manager, which Figure 4 shows, users can connect to an IIS 7.0 server using Windows credentials or credentials specific to IIS Manager. The beauty of credentials specific to IIS Manager is that you provide a very specific and limited set of rights to a user: IIS Web site administration rights. The credentials are useless outside of IIS Manager.
For remote use, a standalone version of IIS Manager is available for Windows Vista, 2003, and XP. Before you can connect remotely with IIS Manager, remote management must be explicitly enabled on the Web Server by doing the following:
1. Install the Web Management Service (WMSVC)
2. Enable remote management via IIS Manager on the Web server (or via the registry)
3. Start the Web Management Service
Firewall rules or remote access policies can make it difficult to use remote management tools. For this reason, IIS Manager works over HTTPS, so it’s both secure and firewall-friendly. By default, the Web Management Service uses a self-signed certificate and listens on port 8172.
Microsoft offers IIS 7.0 Manager for remote management at www.iis.net/go/1524. For additional resources (including detailed configuration instructions), search for IIS 7.0 remote administration at iis.net. You can also find more information about the new IIS features at this Microsoft site.
Built-In Request Filtering
If you’ve administered IIS servers, you’re probably already familiar with UrlScan, a downloadable tool for IIS 4.0 and higher that restricts the types of requests that IIS will service. The intent behind request filtering is to protect your Web server from potentially malicious requests.
In IIS 7.0, UrlScan has been enhanced and bundled with the Web server in the Request Filtering Module. The Request Filtering Module rejects requests based on configurable criteria. For example, the module can reject double-encoded requests or requests of unusual size (such as large POST payloads or URLs that are too long). The Request Filtering Module can also reject requests for file types, paths, or HTTP verbs that your site doesn’t support.
With IIS 7.0, request filtering configuration can be delegated, allowing site admins to define their own request filtering rules in web.config files, which wasn’t possible with UrlScan and IIS 6.0. For more information about request filtering in IIS 7.0, see the Security ProVIP article “Unleash the Power of IIS 7.0’s Security Features,” InstantDoc ID 96999.
URL Authorization
Web applications often have restricted areas to which only certain users have access. Only a manager, for example, is allowed to access performance reviews in an HR system. These restricted pages are commonly grouped together into directories with names like Administration, Reporting, or Moderation. Properly securing these sections to prevent unauthorized access has been cumbersome at best with previous versions of IIS. Even with the URL authorization feature built into ASP.NET, you still have to deal with non-ASP .NET content such as PDF or Excel files that need to be protected. And ASP.NET URL authorization rules are managed by editing XML, which can be tedious.
In IIS 7.0, ASP.NET URL authorization is still available, but in addition, a URL authorization feature is provided by the Web server itself. Now access to all content types (e.g., static, PHP, ASP) can be controlled based on user, group, and URL. For example, you can easily restrict access to anything under the Reporting path to only those users belonging to the Managers group—without touching the file ACLs. Figure 5 shows URL authorization rules configuration in IIS Manager.
URL authorization rules are persisted in the system.webServer section of web.config files with a slightly different syntax than ASP .NET authorization rules, as Listing 2 shows.
Since the authorization rules are contained entirely in your configuration files (local web.config), they are easily transferred between applications and servers. And the URL authorization in IIS 7.0 works with Windows users and groups as well as ASP.NET users and roles.
Building on IIS
IIS 7.0 builds on the solid security legacy of IIS 6.0, and it retains the core architecture of IIS 6.0 with the app pool / worker process isolation model that has proven to be very effective. Although the new modular architecture changes receive a lot of the attention when discussing IIS 7.0 security, automatic application sandboxing, feature delegation, and URL authorization make it easier than ever to secure your Web server.
*.* Source of Information : April 2008 Windows IT Pro
