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.