IIS Basics

IIS is an application providing many network services, including World Wide Web (WWW) publishing, File Transfer Protocol (FTP), Network News Transfer Protocol (NNTP), Web Authoring Distributing and Versioning (WebDAV), Simple Mail Transfer Protocol (SMTP) virtual service, a web services platform, and many other applications and functionality. It natively supports many languages and protocols, including HTTP, HTTPS, HTML, VBScript, JScript, ASP, and ASP.NET protocols and languages. Its default functionality can be extended using Web Service Extensions (see below), which allows additional executables (e.g., ISAPI filters, CGI scripting, etc.) to be added to IIS.

IIS was originally only installed on Microsoft's file server products, but starting with Windows 2000, it was also available for workstation clients. Windows 2000 runs IIS version 5.0, and XP runs version 5.1. Starting with Windows Server 2003, IIS is available to be installed, but is not installed or activated by default. When installed and activated, IIS 6 installs with a bare minimum of services.

Note 

IIS is not available on XP Home Edition.

Table 12-1 shows the popular IIS versions and their default operating systems.

Table 12-1

IIS Version	Default OS
4.0	Windows NT 4.0 Server (NT 4.0 Workstation ran the Personal Web Server application)
5.0	Windows 2000 Server or Workstation
5.1	Windows XP Professional
6.0	Windows Server 2003 and XP Pro 64-bit version
7.0	Windows Vista/Longhorn[*]
[*]As of this publication, Microsoft has no plans to allow IIS 7.0 to run on previous platforms.

Windows Server 2003 introduced Web Server Edition, which is Windows Server 2003 without a lot of the enterprise features needed in a domain. The Web Server Edition of IIS 6 can support any number of remote users, but requires client access licenses for any users authenticating to a Windows authentication database or SQL server. Additional restrictions include the following:

• Cannot run Certificate Services

• Only a single RRAS VPN connection is allowed

• Cannot be a domain controller, but can be a domain member and participate in domain authentication

• No Volume Shadow Copying

• Cannot do the following: clustering, Terminal Server Application server mode, Internet Authentication Service (IAS), network bridging, Internet Connection Sharing (ICS), Internet Connection Firewall, removable storage management, RIS, Fax Services, Windows Media Services, or Services for Macintosh.

Note 

All Windows Server 2003 versions support Network Load Balancing (NLB).

Starting with Windows Server 2003, IIS is not installed by default on any Windows product. It must be installed by selecting Add/Remove Programs ð Windows Components ð Application Server. Under Application Server there are over two dozen components and subcomponents to choose from (see Figure 12-1). When installed, IIS 6 is installed in a locked-down state. Only static web pages can be delivered. All active scripting is disabled by default.

Figure 12-1

IIS can support multiple web and FTP sites at once (except workstation versions, which can only have one active web site at a time), each with varying degrees of functionality. IIS application files are located in a folder called %windir%\system32\inetsrv. The default IIS 6 install only supports static content, and installs only one web site, the Default Web Site. Files for the default web site are stored in \Inetpub\wwwroot by default and contain only a single static web page, indicating that the web site is under construction.

By default, three related services are installed: World Wide Web Publishing, IIS Admin Service, and HTTP SSL. All three run in the Local System context and will be started automatically, although the HTTP SSL service is set to manual and called by the World Wide Web Publishing service. When IIS is active, the web server will listen only on port 80 until otherwise configured. IIS runs using a multitude of files and processes. The main IIS process of Inetinfo.exe, running in the Local System context, is always present, but several other processes assist. It's important to note that in IIS 6 and later, no user code runs in these highly privileged processes.

Http.sys

When IIS 6 is installed and active, the Http.sys kernel mode driver installs as an HTTP protocol stack listener and intercepts and caches incoming HTTP requests. It also provides caching, logging, quality of service, and bandwidth throttling for the web server. Every active web site registers itself with the HTTP protocol stack. The Http.sys driver is the only default IIS 6 component to run in kernel mode, directly interacting with the operating system. Microsoft tested the security of Http.sys, making sure it was not susceptible to buffer overflows and other common security mistakes. All web site code and processes run in user mode, meaning that an exploited web site cannot normally modify the operating system.

IIS 7.0 will include four default protocol listeners: Http.sys, Net.tcp, Net.pipe, and Net.msmq. The Http.sys driver will include built-in support for HTTPS, SSL, and TLS, instead of requiring a separate service (i.e., HTTP SSL). The three other new protocol listeners will support Microsoft's new Windows Communication Foundation web services.

Worker Processes, Application Pools, and Identities

Http.sys forwards client requests to the associated web site's worker process. The worker process is usermode-based code that does the actual handling, delivery, and response for the incoming HTTP request for a particular web site. For example, a worker process may retrieve additional HTTP content and send it to the requesting client, call an ISAPI filter to handle a particular type of request, or run a scripting engine.

Each web site runs in an application pool, which is a named worker process and logical memory allocation where one or more web sites or applications reside. When IIS 6 is installed, only a single application pool, called the DefaultAppPool, is created. Additional application pools can easily be created, and each web site and directory can belong to one or more application pools. Placing different web sites in different application pools isolates what corruption or damage can be done by one site to another. A web server administrator can run high-risk applications in their own application pool, separate from the web site. If a malicious action happens to a web site in one application pool, the vulnerability does not immediately compromise web sites in other application pools.

Note 

When referring to how IIS 6.0 works, application pools are the same as worker processes.

In IIS 6's default worker process isolation mode, there is a separate worker process for each application pool. Each runs in the W3wp.exe process (see Figure 12-2). In previous IIS versions (or an IIS 6 web site running in IIS 5 isolation mode), Dllhost.exe is the default single instance worker process for all web sites. Applications and web sites running in Low Application Protection mode (e.g., ASP) use the Inetinfo.exe worker process. This means that in previous versions of IIS, a single compromise could allow easy access to all web sites on the server.

Figure 12-2

Note 

The W3wp.exe process will not launch until a web site on the web server is first accessed.

Each worker process and associated application pool run in the security context of an application pool identity (see Figure 12-3). The identity is a user or service account used to run the worker process and application pool (i.e., the security context in which the worker process and application pool runs). The default application pool identity is Network Service.

Figure 12-3

Introduced in XP Pro, the Network Service account has permissions similar to the Authenticated Users group, but accesses network resources using the web server's computer account. The Network Service account has the following privileges:

• Replace a process-level token

• Adjust memory quotas for a process

• Generate security audits

• Bypass traverse checking

• Access this computer from the network

• Logon as a batch job

• Logon as a service

• Impersonate a client after authentication

If you create a custom identity account (see below) with permissions similar to the Network Service account, make sure the custom account has the privileges listed above as a minimum requirement.

If a web site doesn't need access to other network resources (i.e., besides the normal remote requesting clients), the web site administrator can change the worker process identity to Local Service. The Local Service account, also introduced in XP Pro, has permissions similar to the Authenticated Users group, but accesses any network resources using an anonymous null session. In XP Pro and later, network resources cannot be accessed using the null session account, except to domain controllers. The Local Service account has the following privileges:

• Replace a process-level token

• Adjust memory quotas for a process

• Generate security audits

• Bypass traverse checking

• Access this computer from the network

• Logon as a batch job

The Local Service account does not have the Impersonate a client after authentication privilege. If you create a custom identity account (see below) with permissions similar to the Local Service account, make sure the custom account has the privileges listed above as a minimum requirement. Bypass traverse checking and Access this computer from the network privileges are given to any user or service account by default (by belonging to the Everyone group) and normally don't have to be individually assigned. Logon as a batch job and Impersonate a client after authentication privileges can be given by adding the custom account to the IIS_WPG built-in group. The remaining privileges must be individually given to any custom identity account.

IIS_WPG Group

The IIS Worker Process Group, IIS_WPG, was new in IIS 6.0. The default application pool identity, Network Service, belongs to this group by default (along with the IWAM, Local System, and Local Service accounts). Any custom application pool identity account must belong to this group as well. By default, IIS_WPG and its members have Read permissions to the default web server directory, \Inetpub\wwwroot.

The IIS_WPG group also has permissions to various other IIS directories, including IIS Temporary Compressed Files folder (if compression is turned on), %windir\System32\Inetsrv\ASP (for ASP), and the %windir%\system32\Microsoft.NET\Framework\v1.14322\Temporary ASP.NET Files folder (if ASP.NET is installed).

Although you can modify the membership of the IIS_WPG group, you should be careful about changing the default permissions given to the group. First, if you accidentally remove a necessary permission, all of your web sites can stop working until you figure out what you did. With that said, you can remove the IIS_WPG group's right to high-risk files, folders, and registry keys (as detailed in Chapters 5 and 6). Be sure you don't deny write access to IIS_WPG to the default locations if you are running ASP.NET, as these permissions are required for .Net to write content to the server used for background processing. ASP.NET performs these operations as the process identity for the worker process, rather than the logged on user.

Creating a Custom Worker Process Identity

Application pool identities should have the bare minimum NTFS permissions and system privileges necessary to support the related web site. If the default three service accounts don't allow a least privilege security context to be used, a custom worker process identity account can be created and used. Here are the steps:

1. Create an identity account as you normally would in Local Users and Groups or the Active Directory Users and Computers console.

2. Make the account a member of the IIS_WPG group.

3. Assign the necessary additional explicit privileges to the new identity account: Replace a process-level token, adjust memory quotas for a process, and generate security audits. Identities wishing to access remote network resources need the Logon as a service privilege as well.

4. Assign the necessary NTFS permissions (e.g., Read, Write, etc.) of the necessary web site content and folders to the new identity account.

5. Test the web site from a client machine and look in the log for any IIS-related issues.

6. If the web site has problems from the custom identity, assign the application pool the normal Network Service identity and use Sysinternal's Filemon utility to troubleshoot what file permissions are needed in order for the web site to display successfully.

Web sites running on domain controllers using the Network Service account identity may need additional permissions set on the Network Service account and IIS_WPG group, because those permissions are taken away by the action of making a server computer a domain controller. See http://support.microsoft.com/default.aspx?scid=kb;en-us;842493 for further information.

IUSR and IWAM

When a user connects to an IIS web site, the files are accessed in the context of an impersonated user. Whatever permissions and privileges the impersonated user has, so too does the connecting web site user. This is an extremely important point to remember when configuring IIS security. IIS allows authenticated and anonymous connections. Authenticated connections must use a valid SAM or Active Directory security principal account.

When IIS is installed, two default user accounts are created: IUSR_<computername> and IWAM_<computername>. The IUSR account is used by IIS for web sites supporting anonymous connections. Connecting users can access any web resource that the IUSR account is allowed to access. The IUSR account belongs to the Guests group, and has Read & Execute NTFS permissions to the Default Web Site's folder (i.e., \Inetpub\wwwroot) by default. Starting in IIS 6, the anonymous account has explicit Deny-Write and Deny-Delete permissions to the same folder to prevent anonymous users from uploading or modifying web content.

To recap, IIS 6.0 runs using a combination of one or more worker processes (W3wp.exe or Inetinfo.exe), the Http.sys protocol listener, applications pools, identities, and the web site's content. Figure 12-4 shows a theoretical example of IIS running three web sites within two application pools. Users accessing a particular web site run files in the context of an impersonated user, either by specifically authenticating or by indirectly using the IIS web site's anonymous user account (not to be confused with the completely unrelated anonymous null session built-in account).

Figure 12-4

The IWAM account is used for out-of-process (e.g., COM+ application) connections and can usually be disabled in IIS 6. In previous versions of IIS, an application could run inside the web site (i.e., in-process) or external to the web site (i.e., out-of-process). When running out-of-process, IIS uses the process Dllhost.exe. You will see this process starting in IIS 6 when out-of-process communications (i.e., IIS 5 mode) is needed.

User names and passwords for these two accounts are stored in both the IIS metabase (see below) and the appropriate SAM or Active Directory database. Normally, IIS synchronizes the names and passwords of these accounts between IIS and the appropriate account database when IIS is first installed, but it needs to be manually maintained in both locations if the IIS default account names or passwords are changed. The initial passwords of these accounts are long and complex. When setting passwords manually, make sure the passwords are long and complex (i.e., 15 characters or longer).

You can view and set the IUSR account password manually in IIS using the IIS Admin console or using the Adsutil.vbs script located in \Inetpub\Adminscripts. See http://support.microsoft.com/default.aspx?scid=kb;en-us;297989 for details on how to view or set passwords using Adsutil.vbs. The IWAM account password cannot be changed in the IIS Admin console. It can be changed programmatically or by editing IIS's metabase.

Note 

In IIS 7, the IUSR account will be a built-in account with a well-known SID. This will enable permissions assigned to it to be easily copied to other web sites.

IIS Administration

IIS can be administrated locally or remotely. In IIS versions 4 to 6, IIS is locally managed using the IIS Admin MMC console (see Figure 12-5). To use the tool in IIS 6 or previous versions, the user must be a local Administrator on the web server. The IIS Admin tool allows nearly every facet of IIS and its web sites to be configured, including authentication, IIS permissions, SSL, application pools, and what web extensions are allowed.

Figure 12-5

Remote administration can be accomplished using an internal IIS admin web site or an external remote admin tool, such as Remote Desktop. Although not installed by default, administrators can install a remote management web site called the Administration web site. To install, the administrator should select the Remote Administration (HTML) option under IIS components while installing IIS. It can be added after the initial install. This creates the new Admin web site, which runs on a randomly chosen TCP port (for example, 8098). To use the remote admin tool, simply surf to the normal supported web address, but begin the web site URL with https:// and end the URL with : and the random TCP port number. For example:

 https://www.example.com:8098 

The default admin port is protected by SSL. If you forget to put the https: in the URL, an error message will be returned. There is another non-SSL admin port that is created as a listener, too, but it simply reports that you must connect on the HTTPS port. When you connect successfully, you must provide administrator-level credentials, and you may have to add the admin site to the Trusted sites security zone of your browser. Once authenticated, the Admin web site has nearly a full range of functionality, as compared with the MMC console tool. Figure 12-6 shows one of the management screens located in the remote management web site.

Figure 12-6

Metabase

IIS configuration information is stored to a file called the metabase, which only the local Administrator and system account have access to by default. The metabase is stored in a plaintext XML file called Metabase.xml located under \System32\Inetsrv. It can be edited manually, created and modified in the IIS Admin GUI, or modified programmatically. It can also be extended to add new schema objects in IIS. The schema structure is stored in MBSchema.dll. You can also back up and restore the metabase using several different tools, and IIS frequently makes its own backups and stores them in the \System32\ inetsrv\History folder. The metabase can be imported and copied to other IIS servers.

IIS 7 uses a new administrative tool called the Web Manager. Non-admin users can be delegated the capability to manage one or more web sites without having to be an administrator. Web Manager is a non-MMC console, completely redesigned for IIS 7. It separates the various aspects of web server administration into different categories (e.g., IIS, ASP.NET, Web Server Management, Server Components, Security, Performance, Health, etc.). The author has seen a beta copy of this tool and found it to be an improved interface over the IIS Admin console, once the administrator gets used to the new interface. In IIS 7, configuration settings are stored in two new XML files. The Application.Host.config file stores IIS server settings and each web site has its own Web.config file for site-specific settings.

IIS administrators can also use Remote Desktop or another other third-party remote control tool (e.g., pcAnywhere, VNC, etc.). Remote Desktop uses Terminal Services and Remote Desktop Protocol (RDP) over TCP port 3389 to provide a fairly reliable and encrypted communications session. Many administrators use IPSec tied to specific client and server addresses in conjunction with RDP to ensure authentication and encryption. Any of the remote admin tools allow complete control of the web server, and not just IIS, of course. Whatever remote admin tool is used, the administrator should take great pains to ensure that the admin port and connection are secure.

IIS Authentication

When a client machine connects to an IIS server, it will always connect as either the default anonymous user (i.e., IUSR_<computername>) or with an authenticated user account stored in Active Directory or the local SAM. IIS allows six different kinds of default authentication:

• Anonymous

• Integrated Windows Authentication

• Digest Authentication

• Basic Authentication

• Passport Authentication

• SSL Client-Side Mapping

Authentication methods can be configured in the IIS Admin tool by choosing the Directory Security tab and the Edit button under the Authentication and access control section (see Figure 12-7). One or more authentication methods can be selected per web site, per folder, or per file. For example, an administrator can allow anonymous connections to most of their web site content but require authenticated access to a particular folder or file. If anonymous and authenticated methods are allowed at the same time, most browsers will try the anonymous connection first.

Figure 12-7

Anonymous authentication is the default impersonated user for most web sites. The IUSR_<computername> account is a member of the Users and Authenticated Users groups. This membership gives the IUSR account Read and Execute permissions to most default Windows files. Luckily, these overly broad security permissions are offset by the less broad permissions of IIS. Any web site only requiring Anonymous authentication will not prompt the user for logon credentials.

Integrated Windows Authentication (IWA) allows a client to connect using one of the normal Windows logon authentication methods (i.e., LM, NTLM, NTLMv2, or Kerberos). This authentication method requires that the client and IIS server reside in the same domain, and for that reason IWA does not normally work over the Internet. NTLM and NTLMv2 can get past a firewall, but are generally stopped by proxies because NTLM is connection-based, and proxies do not necessarily keep connections established.

It is intended for internal intranet sites, where users should not be bothered by being asked to re-authenticate when they connect to the intranet server. Any web site in the user's Intranet sites zone using IWA will not prompt the user for logon credentials unless the logon credentials are valid. The default option of whether to always be prompted or not is set under each security zone's settings in Internet Explorer (covered in the last chapter). The remaining authentication methods will always prompt the user for logon credentials and pass them to the web server.

Digest Authentication allows remote clients to use Active Directory user accounts to authenticate if the web server is a member of an Active Directory domain. The server must use Windows 2000 and IIS 5 or later and the client must be IE 5.0 or later. The user's account must also have the Store passwords using reversible encryption option selected. If enabled, clients can authenticate using their normal user account, and the authentication transaction does not transmit the users in plaintext (unlike Basic Authentication). If Digest Authentication is used on a Windows Server 2003 web server running in a Windows 2003 domain, Digest Authentication can become Advanced Digest Authentication (using more secure MD5 hashes).

Basic Authentication is an older but widely supported HTTP standard allowing users to log on using a SAM or Active Directory account. Users are prompted to input their logon name and password, and the browser encodes the information using base 64 encoding and transmits it to the server. Although base 64 encoding is not plaintext, it is near enough, and extremely easy to decode back to its plaintext original. Basic Authentication should not be used except in cases where backward compatibility is needed. You can enable Basic Authentication for compatibility reasons and use SSL (or another protective tunnel-like IPSec) to strongly protect the authentication stream.

Passport Authentication is a proprietary Microsoft protocol that is losing support. Microsoft created it so that users could authenticate to participating web sites without sending their login name and password over the Internet. With Microsoft Passport, and other authentication schemes like it, the user establishes an identity and password at a centralized identity management location. In this case, it would be with one of the Microsoft Passport servers. Whenever the user visited a participating web site that supported Microsoft Password authentication, the user would authenticate to the Microsoft Passport site securely. Then the Microsoft Passport servers would give the client a token or cookie that would validate their authentication to the original web site. It is also possible to write an ASP.NET application that uses local Passport credentials so you don't have to use Microsoft's Internet databases, but this has not been widely adopted.

The user's identity and financial information (e.g., credit card information) would reside once at the centralized Microsoft Passport site, and not have to be stored on every web site from which the user wished to purchase goods. Unfortunately, the Microsoft Passport mechanism suffered from early security weaknesses and a lack of trust and use by end users. Microsoft is starting to discontinue its Microsoft Passport service for third parties, although Passport credentials are still used, and often required, for many Microsoft web sites and services.

SSL Client-Side Mapping is another potential default IIS authentication method. If SSL is enabled on a web site, the web site can also require that the client provide an authenticated SSL certificate as well. The client's SSL certificate can be stored in Active Directory (i.e., mapped), so that when the web site requests it, it can be retrieved from the user's Active Directory user object and handed to the server for validation.

This is a very secure form of authentication but requires heavy initial and ongoing administrative use of a PKI infrastructure.

Note 

The certificate can also be installed in the IIS metabase for backward compatibility with IIS 4.

IIS 7 has a new logon feature that can be installed on a web page by including the Login.aspx code. It presents the user with a logon name and password prompt screen that will then pass the credentials on — to IIS using one of the previously mentioned authentication types, to a SQL server database, or to any installed security provider.

Note 

You can do this with ASP.NET applications today. "Forms authentication" is available and in use by many web sites. However, in IIS 6, it only works for ASP.NET content. In IS 7, it will work for all content.

In IIS 6 and previous versions, each of the authentication methods came as one default package. If IIS was installed, then each of these methods could be used. Only the anonymous user was enabled by default on the Default Web Site, but any authentication method could be turned on with a simple mouse click. In IIS 7, each individual authentication method can be enabled or disabled on a per-module basis. For example, if the web site doesn't use Basic Authentication, the administrator can remove the Basic Authentication module, and the code will not be available in IIS for use or exploitation.

Table 12-2 summarizes the basics of each IIS authentication method.

Table 12-2

Method	Security Level	How Passwords Are Sent	Crosses Proxy Servers and Firewalls	Client Requirements
Anonymous Authentication	None	N/A	Yes	Any browser
Basic Authentication	Low	Base 64 encoded clear text	Yes, but sending passwords across a proxy server or firewall in clear text is a security risk because base-64-encoded clear text is not encrypted.	Most browsers
Digest Authentication	Medium	Hashed	Yes	Internet Explorer 5 or later
Integrated Windows Authentication	High	Hashed when LM or NTLM is used; Kerberos ticket when Kerberos is used.	No, unless used over a PPTP connection	Internet Explorer 2.0 or later for NTLM; Windows 2000 or later with Internet Explorer 5 or later for Kerberos
Certificate Authentication	High	N/A	Yes, using an SSL connection	Internet Explorer and Netscape
Passport Authentication	High	Encrypted	Yes, using an SSL connection	Internet Explorer or Netscape

Table 12-3 discusses the various advantages and disadvantages of the authentication protocols requiring logon credentials.

Table 12-3

Authentication Method	Advantages	Disadvantages
Digest	Supports authentication through firewalls and proxies. Encrypts user credentials. Requires Active Directory running on Microsoft Windows 2000 Server or later. Provides medium security.	Requires IE 5.0 or later. Requires that user password be stored unencrypted in Active Directory. Cannot be used to authenticate local accounts. Requires the associated application pool identity to be configured as Local System.
Basic Authentication	Doesn't require IE or Active Directory. Supports authentication through firewalls and proxies. Can be used to authenticate local accounts. Stores hash of the user credentials in Active Directory.	Plaintext transmission of credentials. Low security. Consider using adjunct security tunnel, such as SSL or IPSec, if Basic Authentication is desired.
Integrated Windows	Encrypts user credentials. Provides high security. Requires IE 2.0 or later (5.0 and later for NTLMv2 and Kerberos authentication).	Requires Microsoft clients. Will not work across a proxy server. May use low-level encryption for LM depending on the specifics.
Client Certificates	For server authentication (certificates stored on the server), your organization obtains certificates from a trusted certification authority. For client authentication, map certificates to user accounts stored in Active Directory running on Windows 2000 Server or later. Provides high security.	For client authentication (certificates stored on the clients), your organization has, or is willing to deploy, a public key infrastructure (PKI). For client authentication, you have a method of securely distributing the certificates to the clients.
Passport	Supports authentication through firewalls and proxies. Encrypts user credentials. Requires IE 4.0 or later and Netscape Navigator 4.0 or later.	Requires Active Directory when account mapping is used. Requires your organization to license the .NET Passport authentication service, which is being discontinued.

Also, web administrators can implement third-party authentication schemes, whereby the user is prompted for logon credentials and the web site validates the attempt without involving the normal IIS authentication mechanisms. This is often done by using a front-end logon page that is back-ended to a SQL server, which functions as an authentication database. If this method is used, administrators must code their own logon method as securely as they can (no easy feat).

Note 

It's also important to remember that most of the IIS logon authentication methods are more concerned about transmitting authentication credentials between the remote client and the server and are not as concerned with integrity and confidentiality issues. To ensure those latter points, use an adjunction protection tunnel such as SSL or IPSec.