How they can help you get control over your Web server and reduce your attack surface
| Downloads |
|---|
| 98393.zip |
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
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
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.