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
Previous
Register
