Exploring Windows 2003 Security: IIS 6.0

Wednesday Dec 31st 2003 by Marcin Policht
Share:

We conclude our Windows Server 2003 overview with a discussion of IIS 6.0 and its role in keeping the operating system safe and secure.

There is probably no other component of Windows Server 2003 that better reflects Microsoft's dedication to its Secure Computing initiative than Internet Information Services 6.0. The latest version of the Web server constitutes significant architectural change from its predecessors, offering enhanced stability, security, and functionality.

This article provides an overview of the new architecture and its implications on security and stability.

New Architecture

At the core of IIS 6.0 is the kernel mode driver HTTP.SYS. Its primary function is listening for, queuing, and managing incoming HTTP requests; however, it is also responsible for a number of other tasks, such as bandwidth throttling, logging, and caching. This not only speeds up the handling of all these features (since switching between user and kernel modes is no longer necessary, as it was in the previous versions of IIS), but also increases resilience and security. Since the core Web server functionality resides in the kernel component, which is part of the operating system code (and hence controlled strictly by Microsoft), it is not affected by Web applications running in user mode. This is different from older implementations of IIS, where the core Web server process, INETINFO.EXE, was running in user mode, along with Web application code and ISAPI filters.

Also new in this version of the Web server is the ability to configure applications to run in the dedicated application mode. This means one or more Web applications can be grouped together into so-called pools and run in isolation from others, assigned to other Web application pools. Prior to IIS 6.0, it was possible to run applications in either one shared process space or individually, which made applications more vulnerable to the impact of others (in shared configuration) or resulted in inefficient use of resources (when running each application individually).

Each application pool has a separate queue in which HTTP requests are placed (depending on their destination). These requests are subsequently handled by worker processes dedicated to each pool. The number of worker processes is configurable on a per-pool level (running a Web application with multiple worker threads is known as Web garden). One benefit of this is that it runs in the security context of a non-privileged account (Network Service by default). Hence, it is less likely to affect other Web applications or HTTP.SYS itself (especially since each application pool has its own worker process or processes). In addition, they can be easily managed in terms of recycling, performance, health, and identity (all of these characteristics are controlled by corresponding tabs on the Web Application Pool Properties dialog box), without affecting other application pools. This way, users have better control over performance, stability, or security problems resulting from badly designed Web applications.

With this better understanding of how IIS 6.0 has been designed, let's take a closer look at the resulting security-related changes:

  • Secure by default
  • New administration features
  • New authentication methods
  • Secure Sockets Layer 3.0
  • Ability to choose a cryptographic service provider
  • ASP.NET as the primary development platform
  • URL authorization

Secure by Default

This is one of new slogans describing Microsoft's design strategy applied to Windows Server 2003 and IIS 6.0 in particular. Unlike previous versions of operating systems, which favored ease of use and out-of-the-box functionality over security, the new version of the Web server requires the admin to do some extra work to get all the features needed.

To begin with, the IIS 6.0 component is not installed by default (with the obvious exception of Windows 2003 Web Server Edition). However, adding it is as easy as in the past, with the Add/Remove Programs Control Panel applet (IIS is listed as subcategory under Application Server item). Upgrade behavior has also been modified. World Wide Web Publishing service is disabled after upgrade from Windows 2000, as long as the IIS is configured with default settings (which indicates typically that installation was unintentional).

The default installation allows only static Web pages to be served. If the goal is to provide other functionality, you must install and enable it manually. This includes features related to serving dynamic Web content, such as Active Server Pages (both ASP and ASP.NET) and Server Side Includes, as well as these simplifying development and Web server management, such as FrontPage Server extensions and Web Distributed Authoring and Versioning (WebDAV). In addition, by default, all unknown ISAPI and CGI extensions are prohibited. To modify this setting, use the Web Services Extensions node in the IIS Managers MMC snap-in.

New Administration Features

Like the previous version, IIS 6.0 offers two graphical interfaces for managing Web servers -- via Internet Information Services Manager MMC snap-in and via IIS Administration Web site. The first one is available as soon as the World Wide Web Service component is installed; the second one requires the installation of the Remote Administration (HTML) item listed as one of the subcomponents of World Wide Web Service in the Windows Components Wizard (which is invoked by running the Add or Remove Programs Control Panel applet). Once the installation is completed, you can administer the Web server remotely by connecting from a Web browser to https://servername:8098.

In version 6.0 the connection uses the HTTPS protocol, which is secured with pre-configured, automatically generated certificates. Unfortunately, several vulnerabilities were discovered in recent months, so in general this utility should be avoided.

More significant from, an administrative point of view, is the ability to control the installation of the IIS component with Windows 2003 Group policies. The relevant setting is located in the Computer Configuration -> Administrative Templates -> Windows Components -> Internet Information Services container.

New Authentication Methods

In addition to the authentication methods available in the previous versions (anonymous, basic, integrated, certificate based -- using client certificate mapping, and digest), IIS 6.0 offers two new types:

  • .NET passport authentication uses the Microsoft-managed .NET Passport Web service. Although acceptance of this technology has been rather lukewarm in corporate environments, the ability to use it for Web authentication has been implemented in IIS 6.0. .NET Passport authentication improves user experience, since it limits the number of user names and passwords to be remembered and makes Web site administration more challenging.

    First, you must register your Web server with .NET Passport servers (this procedure includes signing formal agreements that result in obtaining a site ID) and ensure both sides are communicating properly. Testing procedures (performed with designated by Microsoft .NET Passport preproduction servers) are described in the "Setting Up .NET Passport in the IIS topic of the online Help included with Windows Server 2003 . The task is even more challenging if you must set permissions on the Web site, since .NET passport provides only the authentication mechanism, but it is not used for authorization (i.e., controlling what a user can or cannot access). To accomplish this, map .NET Passport users to Active Directory accounts. This process is called provisioning, and it is also described in the same On-Line Help topic.

  • Advanced Digest authentication is similar in many respects to digest authentication, which became available with IIS 5.0. It uses Windows domain accounts, and can be used across firewalls and proxies (unlike integrated authentication). However, while digest authentication requires user passwords be stored on domain controllers using reversible encryption, which has obvious security implications, with advanced method, passwords are stored in the form of one-way MD5 hash. At the beginning of authenticated connection, a Web server informs the client's browser to prompt user for user name, domain name, and password. The browser applies MD5 hash algorithm to user credentials and submits them to Web server as part of HTTP 1.1 request. The Web server then forwards the hash to the Windows 2003 domain controller for verification. Once this is successful, the user is allowed to connect.

    Note that use of Advanced Digest Authentication places additional requirements on both the server and client sides:

    1. Users' computers must have HTTP-1.1-compliant browser installed (IE 5.0 or later)
    2. Web server must be running IIS 6.0 (this requires Windows Server 2003)
    3. Users' accounts must reside in the same domain as the Web server or a domain trusted by the domain where Web server resides

    In addition, you must also enable Advanced Digest Authentication on the Windows Server 2003 running IIS 6.0 component. This requires performing the following two steps:

    1. Modify the setting on the Directory or File security tab (depending on the level on which authentication will be applied) of a Web site, directory, or file Properties dialog box in the IIS Manager MMC snap-in. Click the Edit button in the Authentication and access control section, and select the Digest authentication for Windows domain servers checkbox. This will enable the Realm text box, in which you can type (or select after clicking on Browse button) the domain where users accounts reside.

    2. The previous step enables digest authentication. To switch to the advanced version, you must also set the UseDigestSSP metabase key to TRUE (leaving this key empty or setting it to FALSE defaults to legacy setting). You can configure this setting on the top W3SVC level, which will be automatically inherited by lower-level keys. For the new setting to take effect, restart the IIS service, unless the Enable Direct Metabase Edit setting on the Computer Properties dialog box in IIS Manager MMC snap-in is selected.

    On a side note, IIS Metabase is no longer stored in the binary format, but instead consists of two XML files (Metabase.xml and MBSchema.XML), which simplifies edits, backups, and restores.

Secure Sockets Layer 3.0

Secure Sockets Layer is commonly used to secure the exchange of information between Web clients and Web servers over the HTTP protocol. The mechanism employed in this exchange is based on certificates, which not only provide encryption, but also ensure message integrity and allow mutual identification of both parties involved in communication (thus preventing eavesdropping and message tampering). Typically, certificates are installed on the server; however, you can authenticate clients based on their certificates as well. With IIS 6.0, Microsoft supports SSL version 3.0, which includes fixes for some well publicized security holes present in the SSL 2.0.

Customizable Selection of Cryptographic Service Provider

IIS 6.0 offers the choice between Microsoft and third-party CryptoAPI providers when requesting certificates for securing Web communication with Secure Sockets Layer. This is set when running Web Server Certificate Wizard, which is launched from the Directory Security tab of the Web site to be secured. On the Name and Security Setting page of the Wizard, you can specify whether to select a cryptographic service provider for the certificate requested. Once this option is selected, you will be presented with a list of providers installed on the Web server. This is important because calculations performed by SSL encryption algorithms place a significant load on the Web server processors. To alleviate this problem, install specialized devices that can offload processing from the server, with their own set of keys and CryptoAPI providers. The providers must be installed as part of the encryption mechanism. Web Server Certificate Wizard makes this option easy to implement.

ASP.NET as the Primary Development Platform

Introduction of ASP.NET as a new Web development platform brought significant changes to the way applications are written. Even though ASP.NET is not limited to Windows Server 2003 platform (since it is the feature provided by .NET framework, available for every 32-bit versions of Windows), it works best when combined with the new version of the Internet Information Server. For example, ASP.NET applications operate by default in the worker process isolation mode (described earlier in this article) when installed on a Windows 2003 server and can be easily configured to take advantage of Web Gardens on multiprocessor computers (which increases scalability by allowing a single application pool to spread processing across several worker processes).

ASP.NET, like other .NET-framework-based development platform, has built-in support for a number of features that make Web applications more stable and secure. Automatic garbage collection, code access security, and role-based administration are just a few described in previous articles of this series. In addition, ASP.NET offers the ability to maintain state across the farm without the need for cookie support on the client side, which also simplifies maintaining the proper security level.

URL Authorization

One of the features made available by combining functionality included in ASP.NET, IIS 6.0, and Windows Server 2003 is URL Authorization. Just as you can control access to applications by configuring role-based security with Authorization Manager (as described in our previous article), you can also control access to specific URLs on a Web server. This mechanism, referred to as URL Authorization, takes effect when when a Web client requests access to a URL configured with Authorization Manager. User identity is matched against a set of defined roles (LDAP queries and Authorization Manager scripts known as BizRules can also be used), which, in turn, determines a user's access rights to the resources available via requested URL.

URL Authorization is implemented in the form of ISAPI interceptor, which monitors all incoming authenticated HTTP request and communicates with Authorization Manager to determine whether access to a particular URL should be granted. Conditions are evaluated dynamically and can be matched against current conditions, such as time of day. If the response is positive, the interceptor forwards the client's request for further processing.

Share:
Home
Mobile Site | Full Site
Copyright 2017 © QuinStreet Inc. All Rights Reserved