Worker Processes, Application Pools, and Identities


IIS uses a combination of mechanisms to pull off what appears to be simple web hosting. It is essential that computer security workers understand the various parts behind the scenes of IIS in order to secure it.

Worker Processes

IIS protocol listeners forward client requests to the associated Web site's worker process. In IIS 7.0, Windows Activation Service (WAS) manages application pool configuration and worker processes instead of WWW Service. The worker process is user mode-based code that does the actual handling, delivery, and response to the incoming request for a particular Web site. For example, a worker process may retrieve 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.

Application Pools

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. Application pools can be shared by Web sites and applications or used to isolate sites and applications from each other (more on this in the "Defending IIS" section later in this chapter).

When IIS 7 is installed, two application pools, called the DefaultAppPool and Classic .NET AppPool, are created (see Figure 9-5). IIS 6 did not have the latter application pool, but Classic .NET AppPool behaves in the same way as IIS 6's DefaultAppPool. Application pools can be configured to run with or without (i.e., no managed code) .NET Framework (see Figure 9-6). The Managed pipeline mode refers to whether the developer wants ASP.NET and non-ASP.NET requests to be processed together (i.e., Integrated), which is a new IIS 7 feature, or separately (i.e., Classic) using Aspnet_isapi.dll for the ASP.NET requests.

image from book
Figure 9-5: Default IIS application pools

image from book
Figure 9-6: Choosing between managed and unmanaged environments

Additional application pools can easily be created, and each Web site and directory can belong to one or more application pools. Additional application pools can be created in IIS Manager by clicking the Add Application Pools option under Application Pools leaf object. Additional application pools can also be created using the command line as well. Here is the command and syntax:

      appcmd add apppool /name:string /managedRuntimeVersion:.string image from book      /managedPipelineMode: Integrated | Classic 

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 main 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 discussing how IIS works, application pools are often discussed as if they are the same as worker processes, even though they are not one and the same.

In IIS 7's default mode (called worker process isolation) there is a separate worker process for each application pool. Each runs in the W3wp.exe process, which runs in the Network Service security context by default. In previous IIS versions (or a 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 (for example, ASP) use the Inetinfo.exe worker process, which as stated previously, runs in the Local System security context. This means that in previous versions of IIS, a single compromise could allow easy access to all Web sites on the server.

Note 

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

Note 

In Vista, just as in previous Windows versions, Dllhost.exe can also be used by other applications, many of which are unaffiliated with IIS, so don't be surprised if you see it as an active process in memory.

Application Pool Identities

Each worker process and associated application pool runs in the security context of an application pool identity. The identity is a user or service account used to run the worker process and application pool (i.e., the security context that the worker process and application pool run in). The default identity for both default application pools is Network Service.

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

You can choose the more secure Local Service account if your application pool does not need to access other network services or computers. 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 because it does not have the "Impersonate a client after authentication" privilege. In XP Pro and above, network resources cannot be accessed using a null session, 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

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.

image from book
WHY DO APPLICATION POOL IDENTITIES RUN AS NETWORK SERVICE?

Many IIS security experts wonder why Microsoft, in the spirit of stronger security, did not default IIS application pool identities to the lower privileged Local Service account instead of Network Service. Although Microsoft has never officially answered this question, most observers feel the decision must have been made so that common legitimate applications were not broken when run on IIS 7. If IIS 7 broke a large percentage of the applications that were run on it because the default security settings were too secure, web developers might go to easier, less secure, competing products.

image from book

You can create or use a custom user or service account (i.e., Specific User) for the application pool identity (see Figure 9-7). The pool will then have access only to the resources and permissions of the custom identity account. If you create a custom identity account, add it to the IIS_IUSRS group, which assigns the necessary permissions and privileges to allow the account to function as an IIS application pool identity. You then need to add the other NTFS file and folder permissions to the resources used by the web application.

image from book
Figure 9-7: Setting a custom application pool identity

You can also choose the LocalSystem account for the identity if the application pool needs Administrator-level privileges and permissions. This is not recommended unless absolutely needed. If a hacker is successful in compromising a web application running in an application pool with the LocalSystem identity, he or she has far more potential to be damaging than if the application pool ran under Local Service or Network Service.

Note 

In IIS 6, any application pool identity had to be added to a group called IIS_WPG to get the correct permissions. This group and requirement has been replaced by IIS IUSRS, although the previous group may still appear.

If the Web site using a custom application pool identity is also involved in delegation to another back-end server (for example, IIS front end authenticating users for an MS-SQL back-end database), a Service Principal Name (SPN) must be created for the custom identity. Specifically, the administrator can use Microsoft's SetSPN.exe utility (http://www.technet2.microsoft.com/WindowsServer/en/library/1033.mspx) to create the new SPN. The syntax would be similar to this for a Web site located at http://www.example.com using a custom user identity called custom in a domain called Contoso:

      setspn.exe -A HTTP/www.example.com contoso\custom 



Windows Vista Security. Securing Vista Against Malicious Attacks
Windows Vista Security. Securing Vista Against Malicious Attacks
ISBN: 470101555
EAN: N/A
Year: 2004
Pages: 163

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net