IIS 6 Administration

In Chapter 8, “Creating and Configuring Applications,” you learned how to create applications on IIS, define application starting points, create application pools, and move applications to different pools. But if you plan to use IIS for hosting dynamic web applications, there are additional steps you need to take to allow your applications to run securely. These steps include:

• Enabling Web Service Extensions (WSE) to allow different types of applications to run in general.

• Configuring execute permissions to allow applications in specific sites and virtual directories to run with the proper permissions level.

• Configuring application pool identities to manage how worker processes that host applications will run.

Configuring Web Service Extensions (WSE)

A great improvement in IIS 6 over earlier versions is that IIS installs in a locked-down mode where only static content can be served to clients. To use IIS for running dynamic web applications, the first thing you have to do is unlock IIS to allow it to serve clients the types of applications you plan to run. To accomplish this, you use the Web Service Extensions (WSE) feature in the IIS Manager console tree. Figure 10-15 shows WSE in Standard view, which displays which Web Service Extensions are allowed and which are prohibited—note that by default all of them are prohibited from running, so any dynamic content currently on the server will not run unless the appropriate extension is allowed.

If ASP or ASP.NET are not visible in the details pane when the WSE node is selected, these components of IIS have not been installed on the machine. Use Add Or Remove Programs to install the missing Application Server components and then allow the extensions you need to run your applications.

Figure 10-15: Web Service Extensions (WSE) node in IIS Manager

Allowing a Web Service Extension

Let’s say you’ve copied an ASP application to the root directory of your website and you want users to be able to use it. All you have to do is enable the extension for ASP by right-clicking it and selecting Allow. If you change your mind later and no longer want to run ASP applications on your server, just right-click ASP again and select Prohibit. Then if a user tries to run your ASP page, an “HTTP Error 404—File Not Found” message will be returned.

Allowing ISAPI and CGI Extensions

The standard view of WSE gives you two options for allowing ISAPI or CGI applications to run on IIS:

• Allow Unknown ISAPI Extensions Lets all ISAPI extensions run on the server.

• Allow Unknown CGI Extensions Lets all CGI extensions run on the server.

Obviously, this can be overkill if you only have a few specific ISAPI or CGI applications you want to run on the server, and it can constitute a security risk if someone uploads a risky ISAPI or CGI application to your server. As a result, IIS lets you create your own Web Service Extensions and specify which applications are allowed to call them. To do this, you must switch from Standard to Extended view using the tabs at the bottom of the details pane when WSE is selected (Figure 10-16).

Adding a New Web Service Extension

You can add a new Web Service Extension using the first hyperlink in Extended view. This has the effect of registering the appropriate HTTP request handler to the list of Web Service Extensions on the server. Click the hyperlink to open the New Web Service Extension dialog box, type a friendly name for your extension to identify it in IIS Manager, and select the EXEs (for CGI) or DLLs (for ISAPI) required for the new extension to work. Table 10-3 shows the DLLs for the request handlers of common application types.

Figure 10-16: WSE Extended view

Allowing All Web Service Extensions Necessary for an Application

You can also allow all necessary Web Service Extensions for a specific application to run by selecting the second hyperlink when Extended view is selected for WSE. Just click the link, select the application from the drop-down box, and click OK. This is useful if you have copied a complex application to IIS that uses many dynamic features such as ASP, ISAPI, CGI, and so on. In one step, you can allow all the extensions necessary for the application to run.

Disable All Web Service Extensions

Extended view also allows you to disable all dynamic content on IIS in one easy step by clicking the third hyperlink in the details pane.

Configuring Execute Permissions

Once you’ve enabled the proper Web Service Extensions to allow your application to run on IIS, you still need to configure permissions for it to run properly. These application permissions are different from the NTFS or web permissions discussed earlier in this chapter, though those still apply for the files (ASP, DLL, EXE, and so on) that constitute your application. Application permissions are commonly called execute permissions and are configured on the Home Directory (or Virtual Directory) tab where the root of your application is located (depending on whether the application root is the site’s home directory or a subdirectory). Using the Execute Permissions drop-down box on this tab, you can set the execute permissions for your application to three possible settings (Figure 10-17):

• None Dynamic applications won’t run and IIS will only serve static HTML to clients.

  Figure 10-17: Configuring execute permissions for the Default Application

• Scripts Only Only scripts (such as VBS or PERL) can run in this application, while executables (EXE files) won’t be allowed to run.

• Scripts and Executables Both scripts and executables can run.

Configuring Application Pool Identities

You may recall from our earlier discussion in Chapter 2, “IIS 6 Architecture,” that application pooling is a new feature of IIS 6 that allows you to group together (or isolate) applications into separate pools that can each be serviced by one or more worker processes. All applications within a pool share the same worker process, and by configuring Web Gardens you can have multiple worker processes servicing the same application pool. Each worker process is an instance of w3wp.exe and runs in the context of a special user account called an application pool identity. The worker process servicing the pool uses this account as its process identity, and this account can be assigned to either an existing account or a custom account you create.

IIS creates new worker processes when they’re needed; and when a new worker process is created by the Web Administration Service (WAS), the built-in service account Network Service is assigned by default as its application pool identity (it’s called a service account because it’s used only by the operating system as a process identity for running network services). This doesn’t mean, however, that an application within the pool runs with that identity. When the application receives a client request to process, the thread that processes the requests impersonates the identity of the process token associated with the client for its process identity. For example, if an application receives and accepts a request from an anonymous user, the client’s process token is associated with the IUSR_ computername account and it is this account, not Network Service, that is matched against the ACL of files the application needs to access.

What’s the point of having application pool identities then? The reason is that the application must still run within a security context even when no user requests are received.

Selecting an Application Pool Identity

The guiding principle in choosing an application pool identity is to select one with just enough privileges to allow your application to run properly. If you assign an account to your worker process that has too high a level of privileges, the application may be able to do things it wasn’t designed to do. Also, if your application has faulty code and is compromised by an intruder, the intruder may be able to use your application pool identity to elevate his or her privileges and compromise your network.

When choosing an application pool identity, you can select from several built-in service accounts used by Windows Server 2003:

• Network Service An account that has very few privileges. It can act as any computer on the network, has no password, and goes by the internal name of NT AUTHORITY\NetworkService. The account is a member of the Everyone and Authenticated Users built-in groups, so if ACLs grant access for these groups to any object, Local Service has the same level of access.

• Local Service The same privileges as Network Service, but this only presents anonymous credentials over a network connection—in other words, it can only access resources on the local computer, not on remote ones. The account has no password and goes by the internal name of NT AUTHORITY\LocalService. This account also is a member of the Everyone and Authenticated Users built-in groups; so if ACLs grant access for these groups to any object, then Local Service has the same level of access.

• Local System Very powerful with a lot of privileges. It can act as any computer on the network, has no password, and goes by the internal name of \LocalSystem. Any process that runs in the context of this account has the same level of privileges as the Service Control Manager (SCM), the portion of the operating system than manages network services running on the machine.

Of these three accounts, the one with the lowest level of privileges and greatest flexibility is Network Service, and this is usually the best choice and the account IIS uses by default. When this account is used and an intruder gains control of your application, the level of privileges gained is so low that the intruder can hardly do anything on your server (they can’t even list directories or read files). The worst of these to select is Local System, as this account has considerable privileges on the machine. An attacker elevating their privileges to this level would be able to do almost anything. For example, if you have an application pool configured to use the Local System account as its process identity and your application opens a command prompt window to run a batch file for some reason, an attacker could press CTRL+C on the machine, terminate the batch file, and have access to a command prompt window running with Local System privileges, which basically lets him or her do anything. Interestingly enough, in IIS 5, applications ran by default using the Local System process identity!

Remember that application pools and worker processes apply only when IIS 6 is running in worker process isolation mode. If your server is running in IIS 5 isolation mode, applications running in common memory with inetinfo.exe using low isolation mode will execute using the Local System process identity, just as they did in IIS 5! Likewise, applications running in medium or high isolation mode will execute using IWAM_ computername as their process identity, also as they did in IIS 5. When you’re migrating IIS 5 applications to IIS 6, make sure to recode your applications as necessary to enable them to run in worker process isolation mode using a safe identity like Network Service.

Configuring a Custom Application Pool Identity

If you don’t want to use one of the built-in service accounts, you can create your own user account and assign it as the application pool identity for the worker process servicing your pool. For this to work, however, your account must be granted certain privileges. This is easily done by making your account a member of the built-in IIS_WPG group. This is a local group when IIS is running in a workgroup environment, and a domain local group when Active Directory is being used. The three service accounts discussed in the preceding section (Network Service, Local System, and Local Service) are by default all members of this group, as is the built-in IWAM_ computername account used to launch applications out-of-process on IIS. If you create a custom account and configure it as the process identity for your pool but don’t make your account a member of IIS_WPG, the worker processes associated with your pool won’t be able to start and your application will fail.

Why would you want to create custom process identities for your different application pools? For enhanced security! Creating separate pools for applications increases reliability because if one application fails it won’t bring down the others. Likewise, creating a custom application pool identity for each pool increases security because if one application is compromised it won’t compromise others on the same server. In both cases, the effect is to better isolate applications from each other, which is a big concern for service providers hosting websites for multiple companies on a single machine. On the other hand, it’s still important to code your applications properly: a poorly written ISAPI application is still a Win32 DLL that can consume excessive CPU resources, fill up your hard disk with useless files, and do lots of other harmful things that can affect the performance of all web applications running on your IIS machine.

Configuring a custom process identity for an application pool is simple: First, create a local user account (for a stand-alone IIS machine) or domain user account (if Active Directory is involved) that will be specifically used for this purpose. Be sure to assign the account a complex password. Then add the account you created to the IIS_WPG built-in group to grant it the necessary privileges to be able to instantiate worker processes. Now right-click an application pool (such as the Default Application Pool) in IIS Manager and select Properties to open the properties sheet for the pool, and switch to the Identity tab (Figure 10-18).

By default, the Predefined option is selected. Use the drop-down menu to select any of the three predefined service accounts just described. To configure a different account as the process identity for worker processes servicing this pool, choose the Configurable option instead. By default, IIS suggests using the IWAM_ computername account as a process identity. This is because if you’ve migrated legacy IIS 5 applications to your IIS 6 machine those applications may need this account as their process identity if they originally ran on IIS 5 using medium or high application isolation. However, you can also click Browse and select the user account you specially created for this purpose, or choose any local or domain user account as your process identity (provided it belongs to the IIS_WPG group).

If you create a user account for a custom application pool identity, there should be no spaces in the name of this account.

Figure 10-18: Configuring the process identity for an application pool

Verifying Application Pool Identity

Here’s a simple way to check that your application is really running under its configured process identity. Create a simple ASP application or use the one you created earlier in Chapter 8, and copy it to the \wwwroot directory, the home directory of the Default Web Site. Make sure ASP is enabled using the WES node, and check the Default Application Pool to verify that the process identity is NETWORK SERVICE. Now right-click the Default Web Site in IIS Manager, and select Browse to run the application. Open Task Manager by right-clicking the taskbar at the bottom of your screen, select the Process tab, and find w3wp.exe in the Image Name column. This executable represents the executable for the worker process servicing your application pool. In the User Name column beside it, you should see NETWORK SERVICE (Figure 10-19). Try creating a custom user account and assigning it as the process identity for your pool, and repeat the experiment to verify that the process is actually running under this identity.

Figure 10-19: Verifying the process identity of a running worker process

Other Application Security Issues

There are two more security issues relating to applications running on IIS 6: parent paths and ASP security.

Parent Paths

Parent paths is an ASP feature that allows you to use path statements such as “..\” for upward file access relative to the current directory. Parent paths were enabled by default for ASP on IIS 5, but this constituted a security hazard because server-side includes that used the “..” notation could enable an intruder to gain access past the root of the application to the root of the Windows file system to wreak havoc. This is especially hazardous if you give the parent directory execute permission because, if an intruder can gain access to a script in that directory, they can execute any program in that directory.

As a result of these issues, parent paths are not enabled by default in IIS 6 as they were in IIS 5. Because this may affect existing ASP applications you try to port from the old platform, the option of enabling parent paths in IIS 6 is there to ensure that you can make your old apps run properly once you migrate them to the new system. To avoid a security hazard, however, a better approach is to recode your old apps so they don’t need that feature anymore. If you need to enable parent paths to get your old app working on IIS 6, here’s how to do it:

1. Find the root node of your application in IIS Manager and right-click it to open its properties sheet.

2. Select the Home Directory (or Virtual Directory) tab, and click the Configuration button to open the Application Configuration box.

3. Switch to the Options tab and select the Enable Parent Paths check box (Figure 10-20).

   Figure 10-20: Enabling parent paths for an application

ASP Security

It’s obvious but sometimes forgotten that applications running on IIS are secure only if both IIS and the application code itself are secure! Writing secure code for ASP or ASP.NET applications is beyond the scope of this book, but here are a few tips you can pass on to your developer:

• Don’t hard code administrator account names and passwords in ASP pages or scripts.

• Don’t store sensitive information in hidden input fields on your web pages or in cookies.

• Don’t code decision branches into your application based on input from HTTP request headers, as these headers can be forged.

• Always validate form input before letting your application process it.

• Watch out for buffer overflows produced by bad coding practices.

• Use SSL to encrypt session cookies to prevent your applications from being hijacked.

• Port your ASP application to ASP.NET if you want to use URL authorization to secure your URL space.